EHRシステム機能モデル
リリース２の概要

2019年 3月

保健医療福祉情報システム工業会
EHRS-FMタスクフォース

1

序文
EHR システム機能モデルは 2007 年にリリース 1、2014 年にリリース 2 が米国
ANSI 規格として認定され、国際標準規格としては、リリース 2 が 2015 年 8 月に ISO/HL7 の標準規格として発行されました。
ISO/HL7 10781:2015 Health Informatics -- HL7 Electronic Health RecordsSystem Functional Model, Release 2 (EHR FM）
国際標準化委員会 EHRS-FM タスクフォースでは、この ISO/HL7 10781:2015の概要を整理し、この中から必須項目（SHALL または SHALL NOT）を抽出して翻訳しました。
本書は下記構成となっています。
資料 1
資料 2
資料 3
資料 4

EHR システム機能モデルの概要
機能概要と必須項目
用語集
タスクフォースメンバ一覧

本翻訳が、今後皆様のシステム開発の一助となれば幸いです。
EHRS-FM タスクフォース

リーダ

岡田

真一

健康で豊かな国民生活を保健医療福祉情報システムが支えます

資料1

EHRシステム機能モデルの概要ⓒ JAHIS 2018

HL7 EHRシステム機能モデル• 2014年： HL7 EHR-S FM リリース2– 米国ANSI規格として認定• 2015年8月：ISO/HL7 EHR-S FM リリース2– ISO/HL7 10781:2015 Health Informatics -- HL7 Electronic Health
Records-System Functional Model, Release 2 (EHR FM)

https://www.iso.org/standard/57757.html?browse=tcⓒ JAHIS 2018

2

1

EHRシステム機能モデルとは• EHRシステム機能モデルは、EHRシステムの保有する機能の参照リストを、ユーザーに理解できる表現で提供する– Functions（機能）とConformance Criteria（適合基準）• 特定のケアや分野の機能プロファイルを通じて、その領域に求められる機能の標準的な表現や共通理解を可能にする•

Scope: The HL7 EHR System Functional Model provides a reference list offunctions that may be present in an Electronic Health Record System (EHRS). The function list is described from a user perspective with the intent toenable consistent expression of system functionality. This EHR-S Functional
Model, through the creation of Functional Profiles for care settings andrealms, enables a standardized description and common understanding offunctions sought or available in a given setting (e.g., intensive care,
cardiology, office practice in one country or primary care in anothercountry).
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=269

3ⓒ JAHIS 2018

機能プロファイル
• EHRシステムは直接機能モデルに適合するのではなく、１つあ
るいは２つ以上の機能プロファイルへ適合• 機能プロファイルは機能モデルあるいは他の機能プロファイ
ルに適合
Conforms to

EHR-S

Conforms to

Derived
DomainProfileConforms to

DomainProfileHospital

EHR-S

DomainProfileClinic

EHR-S

Functions
Conformance
Criteria
Rules for
Functional
ProfilesDomainProfilePharmacy

EHR-S

EHRシステム実装ⓒ JAHIS 2018

Companion
ProfileCancer Research

機能プロファイルEHRS機能モデル

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=269

42

EHRシステム機能モデルの構成
リリース１（2007)

Direct Care (DC) 直接ケア
Supportive (S) 支援
Information Infrastructure (IN) 情報インフラ
３カテゴリー約140機能

リリース2

Overarching (O) 全般
Care Provision (CP) ケア提供
Care Provision
Support (CPS)
ケア提供支援Population HealthSupport (POP)

Administrative
Support (AS)
管理支援

ポピュレーションヘルス支援

Record Infrastructure (RI) 記録インフラ
Trust Infrastructure (TI) 信頼インフラ
７カテゴリー約320機能
5ⓒ JAHIS 2018

リリース2開発におけるインプット….

HITSP Use Cases….

Pharmacy
EHR Lifecycle Model
Vital Reports

EHR
インターオペラビリティ
モデル

Records Mgmt
Behavioral
Long-Term

SOA

Provider Based

PHR-S
FM &
プロファイル

EHR-S
プロファイル

R1, R1.1
拡張や調整

EHR-S FM
Release 2

他の業界Initiative
Privacy,
Security,
Confidentiality

国際標準

Certification(CCHIT,
Q-Rec)

HealthInfo
Exchange

Data Use• Fraud Mgt• Quality• Rev Cycle(ISO TC215,
ISO 21089, 20514,
18308, 13606,
Others)その他

https://www.hl7.org/documentcenter/public_temp_AB474FDF-1C23-BA17-0C5D59524AF4EEC7/calendarofevents/himss/2016/HL7%20Functional%20Model%20Overview%20and%20Use%20-%20EHR,%20PHR%20and%20Profiles.pdfⓒ JAHIS 201863

カテゴリーの例：Care Provision 患者へのケアの提供に必要な機能の参考リスト

https://www.hl7.org/documentcenter/public_temp_AB474FDF-1C23-BA17-0C5D59524AF4EEC7/calendarofevents/himss/2016/HL7%20Functional%20Model%20Overview%20and%20Use%20-%20EHR,%20PHR%20and%20Profiles.pdf

7ⓒ JAHIS 2018

Care Provision CP.1.３抜粋
Function
機能：投薬リストの管理Statement（Normative）
要求事項： 各患者の投薬リストの作成と保持

Conformance Criteria (Normative)
適合基準（動作、アクション、性能等の機能が達成すべき要求項目）

システムは、患者特有の投薬リストを保存する機能を提供しなければならない。
SHALL

Description（Reference)
機能説明
SHALL：必ず要求される
SHALL NOT：禁止する
SHOULD：推奨される
MAY：許される

 Normative：要求項目としてHL7の投票を経て認定されたもの
 Reference：参考情報ⓒ JAHIS 201884

カテゴリーの例：Care Provision Support
 患者へのケアの提供を支援するのに必要な機能の参考リスト
 Care Provisionの各チャプターに対応している

https://www.hl7.org/documentcenter/public_temp_AB474FDF-1C23-BA17-0C5D59524AF4EEC7/calendarofevents/himss/2016/HL7%20Functional%20Model%20Overview%20and%20Use%20-%20EHR,%20PHR%20and%20Profiles.pdf

9ⓒ JAHIS 2018カテゴリーの例：Population Health Support
 疾病予防・管理、医学研究、ケアの質向上、公衆衛生推進を支援する機能

https://www.hl7.org/documentcenter/public_temp_AB474FDF-1C23-BA17-0C5D59524AF4EEC7/calendarofevents/himss/2016/HL7%20Functional%20Model%20Overview%20and%20Use%20-%20EHR,%20PHR%20and%20Profiles.pdfⓒ JAHIS 201810

5

カテゴリーの例：Administration Support• 経営および財務管理を含む管理支援

https://www.hl7.org/documentcenter/public_temp_AB474FDF-1C23-BA17-0C5D59524AF4EEC7/calendarofevents/himss/2016/HL7%20Functional%20Model%20Overview%20and%20Use%20-%20EHR,%20PHR%20and%20Profiles.pdf

11ⓒ JAHIS 2018カテゴリーの例：Record Infrastructure• 記録、記録の実体、記録管理関連• リリース1.1のIN.2（記録管理、Auditを除く）、IN.8（記録アーカ
イブ/リストア）、IN.10（記録ライフサイクル）を含む

https://www.hl7.org/documentcenter/public_temp_AB474FDF-1C23-BA17-0C5D59524AF4EEC7/calendarofevents/himss/2016/HL7%20Functional%20Model%20Overview%20and%20Use%20-%20EHR,%20PHR%20and%20Profiles.pdf

https://www.hl7.org/documentcenter/public_temp_AB474FDF-1C23-BA17-0C5D59524AF4EEC7/calendarofevents/himss/2016/HL7%20Functional%20Model%20Overview%20and%20Use%20-%20EHR,%20PHR%20and%20Profiles.pdfⓒ JAHIS 201812

6

カテゴリーの例：Trust Infrastructure• リリース1.1の前ページ以外＋Auditを含む

https://www.hl7.org/documentcenter/public_temp_AB474FDF-1C23-BA17-0C5D59524AF4EEC7/calendarofevents/himss/2016/HL7%20Functional%20Model%20Overview%20and%20Use%20-%20EHR,%20PHR%20and%20Profiles.pdf

13ⓒ JAHIS 2018

機能プロファイル
• Functional Profile：機能プロファイル– EHRシステム機能モデルを地域、用途（特定の領域、サービス、専門等）に適合するよう規定したサブセット– Stakeholderが設計しHL7の承認を受
ける
機能モデル
機能
プロファイル

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=269ⓒ JAHIS 201814

7

1. Overarching Section
Section/id#：
Type:
Name:

資料 2
Conformance Criteria

OV.1

Row#
1

Function
Overarching Criteria
包括的基準Statement: Overarching criteria are those that apply to all EHR Systems.
機能概要：全ての EHR システムに適用される包括的な基準。
Description: The Overarching Section contains Conformance Criteria that apply to all EHR
Systems and consequently must be included in all EHR-S FM compliant profiles. These criteria
are grouped under a single Function.
機能説明：本セクションは全ての EHR システムに適用される適合基準を記述しており、従ってこれらは全ての EHR システム FM 準拠のプロファイルに含まれなければならない。これらの基準は 1 つの Function としてグループ化されている。
1. The system SHALL conform to function CP.9.1 (Produce a 2
Summary Record of Care).
1. システムは CP.9.1(ケアのサマリ記録の作成)機能を満たさなけ
ればならない。
2. The system SHALL conform to function CPS.9.3 (Health 3
Record Output).
2. システムは CPS.9.3(健康記録の出力)機能を満たさなければならない。
3. The system SHALL conform to function CPS.9.4 (Standard 4
Report Generation).
3. システムは CPS.9.4(標準的なレポートの作成)機能を満たさなけ
ればならない。
4. The system SHALL conform to function RI.1.1 (Record 5
Lifecycle) and all child functions.
4. システムは RI.1.1(記録のライフサイクル)機能とその全ての子機能を満たさなければならない。
5. The system SHALL conform to function RI.1.2 (Record 6
Lifespan) and all child functions.
5. システムは RI.1.2(記録のライフスパン)機能とその全ての子機能を満たさなければならない。
6. The system SHALL conform to function RI.2 (Record 7
Synchronization).
6. システムは RI.2(記録の同期)機能を満たさなければならない。
7. The system SHALL conform to function RI.3 (Record Archive 8
and Restore).
7. システムは RI.3(記録の保存と復元)機能を満たさなければならない。
8. The system SHALL conform to function TI.1.1 (Entity 9
Authentication).
8. システムは TI.1.1(エンティティ認証)機能を満たさなければならない。
9. The system SHALL conform to function TI.1.2 (Entity 10
Authorization) .おかおか２１
9. システムは TI.1.2(エンティティ許可)機能を満たさなければならない。
10. The system SHALL conform to function TI.1.3 (Entity Access 11
Control).

Section/id#：
Type:
Name:

Conformance Criteria
10. システムは TI.1.3(エンティティアクセスコントロール)機能を満たさなければならない。
11. The system SHALL conform to function TI.1.4 (Patient Access
Management).
11. システムは TI.1.4(患者アクセス管理)機能を満たさなければならない。
12. The system SHALL conform to function TI.1.5 (NonRepudiation).
12. システムは TI.1.5(否認不可)機能を満たさなければならない。
13. IF the system transmits data to or receives data from a systemoutside of a secure network, THEN the system SHALL
conform to function TI.1.6 (Secure Data Exchange), to ensurethat the data are protected.
13. システムがセキュアなネットワーク外とデータの送信や受信を行う場合、システムはデータ保護を保証するために TI.1.6(セキュアなデータ交換)機能を満たさなければならない。
14. IF the system transmits data to or receives data from a systemoutside of a secure network, THEN the system SHALL
conform to function TI.1.7 (Secure Data Routing), to ensurethat the exchange occurs only among authorized senders andreceivers.
14. システムがセキュアなネットワーク外とデータの送信や受信を行う場合、システムは認証された送信者と受信者の間でのみデータ交換が行われることを保証するために TI.1.7(セキュアなデータルーティング)機能を満たさなければならない。
15. The system SHALL conform to function TI.1.8 (Patient
Privacy and Confidentiality).
15. システムは TI.1.8(患者のプライバシと秘密保持)機能を満たさなければならない。
16. The system SHALL conform to function TI.2 (Audit) and all
child functions.
16. システムは TI.2(監査)機能とその全ての子機能を満たさなければならない。
18. The system SHALL conform to function TI.4 (Standard
Terminology and Terminology Services).
18. システムは TI.4(標準用語と用語サービス)機能を満たさなければならない。
19. IF the system manages data for which standard terminologies
have been established, THEN the system SHALL conform tofunction TI.4.1 (Standard Terminologies and Terminology
Models) to support semantic interoperability.
19. システムが標準的な用語が確立されているデータを管理する場
合、システムは RI.1.1(ライフサイクルの記録)機能を満たさなけ
ればならない。
20. IF the system manages data for which standard terminologies
have been established, THEN the system SHALL conform tofunction TI.4.2 (Maintenance and Versioning of Standard
Terminologies) to preserve the semantics of coded data overtime.
20. システムが標準的な用語が確立されているデータを管理する場
合、システムは常にコード化されたデータの意味を維持するた
めに TI.4.1(標準用語の保守とバージョン管理)機能を満たさなければならない。
21. IF terminology mapping is implemented within the system,
THEN the system SHALL conform to function TI.4.3(Terminology Mapping).
21. システム内に用語マッピング機能が実装されている場合、シス

Row#

12

13
14

15

16

17

19

20

21

22

Section/id#：
Type:
Name:

Conformance Criteria
テムは TI.4.3(用語マッピング)機能を満たさなければならない。
22. IF the system receives or transmits data for which
jurisdictionally established interchange standards exist,
THEN the system SHALL conform to function TI.5.1(Application
andStructured-Document
InterchangeStandards) and all child functions to support interoperability.
22. システムが管轄区域内でデータ交換標準が制定されているデー
タの送受信を行う場合、システムは相互運用性をサポートする
ために TI.5.1(アプリケーションおよび構造化ドキュメント交換標準)機能とその全ての子機能を満たさなければならない。
23. IF the system receives and transmits data for which generally
accepted interchange standards have been established, THEN
the system SHALL conform to function TI.5.2 (InterchangeStandards Versioning and Maintenance), to accommodate theinevitable evolution of interchange standards.
23. システムが一般的に受け入れられたデータ交換標準が確立されているデータの送受信を行う場合、システムはデータ交換標準の避けられない改変に適応するために TI.5.2(データ交換標準のバージョン管理と保守)機能を満たさなければならない。
25. IF the system receives and transmits data with other systems
outside itself, THEN the system SHALL conform to function
TI.5.4 (Interchange Agreements), to define how the senderand receiver will exchange data.
25. システムが自身以外の他システムとデータの送受信を行う場
合、システムは送信者と受信者がどのようにデータ交換を行うかを定義するために TI.5.4(データ交換の合意)機能を満たさなければならない。
28. The system SHALL conform to function TI.8 (Database
Backup and Recovery).
28. システムは TI.8(データベースのバックアップと復旧)機能を満たさなければならない。
29. The system SHALL conform to function CPS.10 (Manage User
Help).
29. システムは CPS.10(ユーザヘルプの管理)機能を満たさなければならない。
30. The system SHALL conform to function TI.9 (System
Management Operations and Performance).
30. システムは TI.9(システムの管理、運用および性能)機能を満たさなければならない。

Row#

23

24

26

29

31

30

2. Care Provision Section
Section/id#：
Type:
Name:
CP.1
HeaderManage Clinical History
病歴管理

Conformance Criteria

Row#
32

Statement: Manage the patient's clinical history lists used to present summary or detailed
information on patient health history.
機能概要：患者の病歴に関するサマリーあるいは詳細情報を示すために用いる、病歴リストを管理する。

Section/id#：
Type:
Name:

Conformance Criteria

Row#

Description: Patient Clinical History lists are used to present succinct "snapshots" of critical
health information including patient history; allergy, intolerance and adverse reactions;medications; problems; strengths; immunizations; medical equipment/devices; and patient andfamily preferences.
機能説明：患者の病歴リストは、病歴の簡潔なスナップショットであり、既往歴、アレルギー、薬物
不耐性・副作用、薬歴、処方、プロブレム、強み・弱み、予防接種、医療用具/装置、患者や家族の意
向などを含む。
CP.1.133
FunctionManage Patient History
患者の既往歴の管理
Statement: Manage medical, procedural/surgical, mental health, substance use, social and family
history. This includes pertinent positive and negative histories, patient-reported or externallyavailable patient clinical history.
機能概要：患者の(身体的)疾病、処置・手術、精神的病歴、社会歴・家族歴を管理する。陽性所見、陰性所見、患者本人による、あるいは、他から入手した病歴を含む。
Description: The history of the current illness and patient historical data related to previous
medical diagnoses, surgeries and other procedures performed on the patient, clinicians involvedin procedures or in past consultations, and relevant health conditions of family members is
captured through such methods as patient reporting (e.g., interview, medical alert band) orelectronic or non-electronic historical data. This data may take the form of a pertinent positive
such as "The patient/family member has had..." or a pertinent negative such as "The patient/family
member has not had...". When first seen by a health care provider, patients typically bring withthem clinical information from past encounters. This and similar information may supplement
locally captured documentation and notes wherever appropriate. Information regarding thepatient's living situations may be an important means for a provider to uniquely identify a patientor to identify illnesses that may occur within a given proximity. Information regarding past or
present living situations or environmental factors related to the patient or the fetal death may
include a description of the father's type of occupation and occupational demographic information(such as the name and location of the employment). For example, it may be important for theclinician to know that the patient works in an occupation where lead exposure is common. It may
also be important for the clinician to know that the patient lives in a household where asbestos
routinely appears on clothing.
機能説明：患者から得られる情報(面接、医療アラートバンド)あるいは、電子または紙媒体による既往データから得られた現病歴、前回の診断・手術・その他の処置に関する既往データ、処置やコンサ
ルテーションを担当した医師、関連する家族の健康状態など。陽性所見としては、例えば「患者あるいは家族に・・・がみられた」等をいい、陰性所見としては「患者/家族に・・・は見られなかった」
等をいう。医療者が初めて患者を診るとき、患者は過去の受診で得られた診療情報を持参していることが多い。こうした情報や類似の情報は、適切な場合は、診察の場で得られる記録やノートを補足する。患者の生活状態に関する情報は、医療者にとって患者を特定し、あるいは近隣で発生し得る疾病を特定する上で、重要な手段となり得る。患者自身の、あるいは胎児の死亡に関わる過去または現在の住環境、あるいは環境因子としては、父親の職種、職業の属性(雇用先の名称や場所)などが含まれる。例えば、患者が鉛への暴露のある仕事についているか否かを知ることは、医師にとって重要である。またアスベストが衣服に付着するような住環境にあるかどうかも重要である。
1. The system SHALL provide the ability to manage current 34
patient history including pertinent positive and negative
elements (e.g., diagnosis or ruled out diagnosis), andinformation on clinicians involved.
1. システムは患者の (例えば診断を支持する)陽性の要素、あるいは(診断を除外する)陰性の情報を含む現病歴、および担当医に関する情報を管理する機能を提供しなければならない。
2. The system SHALL provide the ability to manage the identity 35
of clinicians involved in patient history elements according toSection/id#：
Type:
Name:

Conformance Criteria

Row#

scope of practice, organizational policy, and/or jurisdictionallaw.
2. システムは、臨床の実践の範囲、組織的方針、あるいは関連法規に準じて、患者の病歴に関わる要素に関与した臨床医の識別子を管理する機能を提供しなければならない。
5. The system SHALL provide the ability to capture family 38
history.
5. システムは、家族歴を把握する機能を提供しなければならない。
6. The system SHALL provide the ability to capture social history. 39
6. システムは、社会歴を把握する機能を提供しなければならない。
7. The system SHALL provide the ability to capture as part of the 40
patient history the patient's relationships (e.g., genealogic,
living situation, other).
7. システムは、患者の病歴の一部として、患者の関係(例えば、家系、住環境、他)を把握する機能を提供しなければならない。
8. The system SHALL provide the ability to capture structured 41
data in the patient history (e.g., administrative, social, mental
health, geographic location, and/or financial statuses, poverty,
orphan, disability, incarceration, incompetence, or remote
geographic location).
8. システムは、患者病歴における構造化データ(例えば、管理的、
社会的、精神的健康状態、地理的場所、さらに/または、経済的状況、貧困、孤児、障害、収監、判断能力を失った状態、遠隔の地理的場所)を把握する機能を提供しなければならない。
9. The system SHALL maintain and render documentation made 42
in a non-linear as well as linear temporal and non-temporalsequence.
9. システムは、線型的な時系列(および非時系列)の順序だけでなく非線型的な順序でも、文書を維持し、表示する機能を提供しなけ
ればならない。
CP.1.2FunctionManageAllergy,
Intolerance and Adverse
Reaction List
アレルギー、不耐性、副作
用リストの管理Statement: Manage patient-specific allergy, intolerance and adverse reaction lists.
機能概要：患者のアレルギー、不耐性および副作用のリストを管理する。
Description: Allergens to substances, (including immunizations), are identified and the list ofallergies is captured and maintained over time. Information regarding allergies may be coded or
free text; coded information is preferred (where possible). In this function the term "allergy" isused to refer to allergies, intolerances, adverse reactions and sensitivities. All pertinent dates,
including patient-reported events, are stored and the description of the patient allergy andadverse reaction is modifiable over time. The entire allergy history, including reaction, for any
allergen is viewable. The list(s) includes all reactions including those that are classifiable as a trueallergy, intolerance, side effect or other adverse reaction to drug, food or environmental triggers.
Notations indicating whether item is patient reported, and/or provider verified are maintained.
The term 'true allergy' is defined by the US National Library of Medicine as: an allergy that iscaused by a series of chemical steps in the body that produce the allergic reaction. The allergy
information that should be captured may vary according to scope of practice, organizational policy,
and/or jurisdictional law. For example, the documentation requirements regarding an allergic
reaction to a substance that is reportable may require a higher level of data capture.
機能説明：物質に対するアレルゲン(免疫を含む)を特定し、アレルギーのリストを把握し、時間経過Section/id#：
Type:
Conformance Criteria
Row#
Name:
にともに維持すること。アレルギーに関する情報は、コード化されている場合とフリーテキストの場合がある。可能な場合には、コードされた情報が望ましい。ここでは「アレルギー」という用語は、アレルギー、不耐性、副作用、過敏症を含めて用いる。すべての関連する日付(患者の報告日を含む)を保存する。患者のアレルギー、副作用は時間をおって更新されることがある。リストには次をすべて含む: 真のアレルギー、不耐性、副作用、あるいは薬剤のその他の有害反応、食物や環境的なトリガー。患者の申告によるものか、あるいは検証し維持されているかの記載を含む。
「真のアレルギー」
は米国国立図書館の次の定義による:アレルギー反応を生成する、生体内における一連の化学的段階
により引き起こされるアレルギー。取得すべきアレルギー情報は、診療提供の範囲、組織的方針、あるいは法規制により異なる場合がある。例えば、報告可能な、ある成分に対するアレルギー反応についての文書化の要求事項は、より高次のデータ取得を必要とする場合がある。
1. The system SHALL provide the ability to manage allergy, 48
intolerance, and adverse reaction to drug, food, medical
products (e.g., vaccines, biologics, devices, chemicals) or
environmental triggers as unique, discrete entries.
1. システムは、アレルギー、不耐性、薬剤への副作用、食物、薬品等(例えば、ワクチン、生物製剤、装置、化学物質)、あるいは環境的トリガーを、ユニーク、個別の値として管理する機能を提供しなければならない。
3. The system SHALL provide the ability to manage the reaction 50
type as discrete data.
3. システムは、反応の型を、離散的データとして管理する機能を提供しなければならない。
5. The system SHALL provide the ability to manage the severity 52
of an allergic or adverse reaction as discrete data.
5. システムは、アレルギー反応または副作用反応の重症度を、離散的データとして管理する機能を提供しなければならない。
6. The system SHALL provide the ability to manage a report of 53
No Known Allergies (NKA) for the patient.
6. システムは、患者に関する「薬物アレルギー無し(No Known
Allergies :NKA)」の報告を管理する機能を提供しなければならない。
7. The system SHALL provide the ability to manage a report of 54
No Known Food Allergies (NKFA) for the patient.
7. システムは、患者に関する「食物アレルギー無し(No Known
Food Allergies :NKFA)」の報告を管理する機能を提供しなければならない。
9. The system SHALL provide the ability to tag as deactivated an 56
allergy, intolerance or adverse reaction.
9. システムは、アレルギー、不耐性、あるいは副作用反応について、「不活性化した」とタグ付け機能を提供しなければならない。
10. The system SHALL provide the ability to capture as discrete 57
data the reason for deactivation of an allergy, intolerance oradverse reaction.
10. システムは、アレルギー、不耐性、あるいは副作用反応について「不活性化した」とする理由を、離散的なデータとして把握する機能を提供しなければならない。
11. The system SHALL provide the ability to render an allergy, 58
intolerance, and adverse reaction that has been deactivated.
11. システムは、「不活性化された」アレルギー、不耐性、あるいは副作用反応を表示する機能を提供しなければならない。
14. The system SHALL provide the ability to tag that the list of 61
allergies, intolerances and adverse reactions has beenreviewed.
14. システムは、アレルギー、不耐性、あるいは副作用反応のリストは監査したことをタグ付けする機能を提供しなければならない。
15. They system SHALL provide the ability to capture and render 62Section/id#：
Type:
Name:

Conformance Criteria

Row#

the date on which allergy information was entered.
15. システムは、アレルギー情報が入力された日付を取得し表示する機能を提供しなければならない。
CP.1.3FunctionManage Medication List
投与歴リストの管理

75

Statement: Create and maintain patient-specific medication lists.
機能概要：患者の投与歴を作成し維持する。
Description: Medication lists are managed over time, whether over the course of a visit or stay, or
the lifetime of a patient. The entire medication history for any medication including, over-thecounter products, alternative supplements and herbal medications, is viewable. Medication lists
are not limited to provider orders/prescriptions but may also include, for example, pharmacy
dispensed medications without prescription, over the counter medications and patient-reported
medications, etc. All pertinent dates, including medication start, modification, and end dates are
stored. Medication Lists may also include additional information such as age-specific dosage.
機能説明：患者の外来受診、入院あるいは生涯にわたり、投薬歴リストを時間をおって維持する。OTC、代替サプルメント、植物薬を含むすべてに関する投与歴が閲覧できること。投薬歴は、医療職によるオーダや処方によるものに限らず、処方無しの調剤薬、OTC あるいは患者報告によるものなども含む。開始日、変更日、終了日をはじめ、すべての関連する日付を保存する。
1. The system SHALL provide the ability to manage a patient- 76
specific medication list based on current medication orders orprescriptions.
1. システムは、現行の投薬オーダあるいは処方に基づいて患者の投薬歴リストを管理する機能を提供しなければならない。
2. The system SHALL provide the ability to manage as discrete 77
data the details of the medication information including nameof the medication ordered, medication identifier (e.g.,
RxNORM), prescriber, ordering date, SIG (e.g., dose amountand quantity, timing, duration and route, and/or site ofadministration), quantity, formulation and ancillary
instructions according to scope of practice, organizational
policy, and/or jurisdictional law.
2. システムは、投薬オーダ名、医薬品の識別子(例えば、RxNORM)、
処方者、オーダの日付、SIG(例えば投与量、タイミング、持続時
間、経路、投与部位)、量、剤型、補助的指示など投薬情報の詳細を離散的データとして、業務範囲、組織の方針、法規制に準じて管理する機能を提供しなければならない。
3. The system SHALL provide the ability to manage as discrete 78
data the Study Treatment Name for any captured
Investigational Product Exposures according to scope ofpractice, organizational policy, and/or jurisdictional law.
3. システムは、治験薬投与と把握された場合は、離散的データとして治験の名称(the Study Treatment Name)を、業務範囲、組織
ポリシー、管轄区域の法律に準じて管理する機能を提供しなけ
ればならない。
5. The system SHALL provide the ability to capture and maintain 80
current and historical patient-specific medications in the
Medication List.
5. システムは、投薬リストに含まれる患者の現在およびこれまでの投薬履歴を、把握し維持する機能を提供しなければならない。
6. The system SHALL provide the ability to capture non- 81
prescription medications including over the counter andcomplementary medications such as vitamins, herbs andSection/id#：
Type:
Name:

Conformance Criteria
supplements.
6. システムは、OTC や補助的な処方外の薬(ビタミン剤、薬草、サ
プルメント等)を把握する機能を提供しなければならない。
7. The system SHALL provide the ability to render the
medication history associated with a patient.
7. システムは、患者の薬歴を表示する機能を提供しなければならない。
8. The system SHALL provide the ability to tag a medication as"erroneously captured".
8. システムは、「誤記録」と投薬にタグ付けする機能を提供しなけ
ればならない。
9. The system SHALL provide the ability to render a Medication
List excluding medications that have been tagged as"erroneously captured".
9. システムは、「誤記録」とタグ付けされたものを除いて、投薬リストを表示する機能を提供しなければならない。
10. The system SHALL render an indicator that a medication istagged as "erroneously captured" when that medication isrendered in a Medication List.
10. システムは、投薬リストに、「誤記録」とタグ付けされている医薬品が表示されるならば、その投与は「誤記録」とタグ付けされていることを示す機能を提供しなければならない。
11. The system SHALL provide the ability to render a current
medication list for patient use.
11. システムは、現在の投薬リストを患者用に表示する機能を提供しなければならない。
17. The system SHALL provide the ability to capture a
description of the medication and a reason for the medication
when the medication name is unknown (e.g., if patient hasreceived medication from external source and does not havethe name, and/or the name is not in the system formulary).
17. システムは、薬剤の名称が不明のとき、その薬に関する説明と理由を取得する機能を提供しなければならない。(例えば患者が外部から薬を入手し、その名前がわからず、かつ/あるいは、名前がシステムの処方集にはない、など)
18. The system SHALL provide the ability to tag and render, on
the active medication list, active medications that the patientbrings from home to take while hospitalized, which thePharmacy may not dispense, according to scope of practice,
and/or organizational policy.
18. システムは、アクティブな投薬リスト及び患者が入院中に服用する目的で持参した薬(薬局では調剤しないかもしれない)をタ
グ付けし、表示する機能を提供しなければならない。
22. The system SHALL conform to function CPS.4.2.1 (Support
for Medication Interaction and Allergy Checking) to renderany potential interactions when capturing or maintaining
medications.
22. システムは、CPS.4.2.1 (薬の相互作用及びアレルギーチェック)の機能に準じて投薬の取得あるいは維持における、いかなる潜在的な相互作用も表示できければならない。
23. The system SHALL provide the ability to capture free text
medications and render them in a manner that distinguishes
them from coded medication entries.
23. システムはフリーテキストの投薬を取得し、コード化された投薬情報と区別し得る方法で表示する機能を提供しなければならない。
24. The system SHALL render an indicator that interaction

Row#

82

83

84

85

86

92

93

97

98

99

Section/id#：
Type:
Name:

Conformance Criteria
checking will not occur against free text medications at thetime of their capture.
24. システムは、フリーテキストの投薬に対しては、その情報を取得した時点で、相互作用チェックは行われないことを指し示す
表示をしなければならない。
27. The system SHALL provide the ability to capture and renderthat the patient takes no medications.
27. システムは、患者がいかなる薬の服用もしていないという情報を取得し表示する機能を提供しなければならない。
28. The system SHALL provide the ability to render active
medications as defined by user requirements and according toscope of practice, organizational policy, and/or jurisdictionallaw (e.g., including medications that may still have aphysiologic effect long after last administration).
28. システムは、ユーザの要求により定義され、かつ業務範囲、組織ポリシー、管轄区域の法律に準じて、有効な投薬情報を表示する機能を提供しなければならない(例えば、前回の投与後以降、長期的な生理機能への作用を有する可能性のある投薬等)。
31. The system SHALL capture, maintain and present preadmission medications according to scope of practice, and/ororganizational policy.
31. システムは、業務範囲、組織ポリシーに準じて、入院前の薬の服用を取得、維持、提示しなければならない。
32. The system SHALL present pre-admission medications at thetime of discharge according to scope of practice, and/ororganizational policy.
32. システムは、退院時に、業務範囲、組織ポリシーに準じて、入院前の薬の服用を提示しなければならない。

CP.1.4
FunctionManage Problem List
プロブレムリストの管理

Row#

102

103

106

107

108

Statement: Create and maintain patient-specific problem lists.
機能概要：患者のプロブレムリストを作成し維持する。
Description: A problem list may include, but is not limited to chronic conditions, diagnoses, or
symptoms, injury/poisoning (both intentional and unintentional), adverse effects of medical care(e.g., drugs, surgical), functional limitations, visit or stay-specific conditions, diagnoses, or
symptoms. Problem lists are managed over time, whether over the course of a visit or stay or thelife of a patient, allowing documentation of historical information and tracking the changing
character of problem(s) and their priority. The source (e.g., the provider, the system id, or thepatient) of the updates should be documented. All pertinent dates are stored, including date notedor diagnosed, dates of any changes in problem specification or prioritization, and date ofresolution. This might include time stamps, where useful and appropriate. The entire problem
history for any problem in the list is viewable.
機能説明：プロブレムリストには、慢性的状態、診断、症候、傷害/毒物中毒(意図的か否かを問わず)、
医療行為の有害事象(例えば、薬剤、外科的処置等)、機能的制約、外来受診あるいは入院時固有の状態や診断・症候等を含む。プロブレムリストは、外来診療、入院、生涯を問わず時間をおって管理される。これにより、プロブレムの経過や変化の追跡等の文書化が可能となる。更新に関わる情報ソース(提供者、システム ID、患者等)も記録する。すべての関連する日付(記録日、診断日、プロブレムの特徴や優先度の変化が認められた日、緩解が認められた日など)を記録する。タイムスタンプを用いる
場合もある。すべてのプロブレム歴、リスト中のいかなるプロブレムも閲覧できること。
1. The system SHALL provide the ability to manage, as discrete 109
data, all active problems associated with a patient.
1. システムはすべてのアクティブな患者のプロブレムを、離散的なSection/id#：
Type:
Name:

Conformance Criteria

Row#

データとして管理する機能を提供しなければならない。
2. The system SHALL capture, maintain and render a history of 110
all problems associated with a patient.
2. システムはすべての患者のプロブレムの履歴を、取得・維持し、表示しなければならない。
3. The system SHALL provide the ability to manage the status of 111
each problem (e.g., active, inactive, resolved).
3. システムは、個々のプロブレムのステータス(アクティブ、イナ
クティブ、緩解、等)を管理する機能を提供しなければならない。
4. The system SHALL provide the ability to manage relevant 112
dates including the onset date and date(s) of problem statuschange (e.g., inactivation or resolution date).
4. システムは、発現日やプロブレムの状態が変化した日(イナクティブになった日、緩解した日等)をはじめ関連する日付を管理する機能を提供しなければならない。
5. The system SHALL provide the ability to manage information 113
about the chronicity duration (e.g., chronic, acute/selflimiting) of a problem.
5. システムは、プロブレムの持続期間(慢性、急性/治療をしなくても改善していく(self-limiting)等)に関する情報を管理する機能を提供しなければならない。
7. The system SHALL conform to function RI.1.1.17 115(Deprecate/Retract Record Entries) to enable the inactivation
or deprecation of a problem.
7. システムはプロブレムのイナクティブ化あるいは否認を可能とするため機能 RI.1.1.17(記録入力の否認/撤回)に準じなければならない。
10. The system SHALL provide the ability to render only active 117
problems.
10. システムは、アクティブなプロブレムだけを表示す機能を提供しなければならない。
17. The system SHALL provide the ability to link orders, medical 124
equipment, prosthetic/orthotic devices, and medications to
one or more codified problems.
17. システムは、オーダ、医療用具、義手・義足、投薬を一つある
いは複数のコード化されたプロブレムに紐づけする機能を提供しなければならない。
18. The system SHALL provide the ability to capture free text 125
problems and render them in a manner that distinguishes
them from coded problem entries.
18. システムはフリーテキストで記載されたプロブレムを取得し、コード化されたプロブレムと区別できるように表示する機能を提供しなければならない。
19. The system SHALL tag and render an indicator that 126
interaction checking will not occur against free text problems.
19. システムは、フリーテキストのプロブレムに対しては相互作用チェックが行われないことを、インディケータにタグ付けし表示する機能を提供しなければならない。
20. The system SHALL provide the ability to capture a problem 127
into the problem list using standardized coding schemas (e.g.,
ICD or SNOMED).
20. システムは、標準コード(ICD、SNOMED 等)を用いてプロブレ
ムリストにプロブレムを記録する機能を提供しなければならない。
21. The system SHALL provide the ability to manage free text 128
comments associated with the problem.
21. システムは、プロブレムに関連するフリーテキストのコメント

Section/id#：
Type:
Name:

Conformance Criteria

Row#を管理する機能を提供しなければならない。
CP.1.5FunctionManage Health-Related
Factors List
健康に関わる要因リスト
の管理

134

Statement: Manage patient-specific health-related factors.
機能概要：患者の健康に関わる要因を管理する。
Description: A patient's strengths (positive factors) or weaknesses (negative factors) may impact
a patient's care or recovery and may be recorded as part of the EHR to support the developmentof care plans and treatment options. Examples of health factors include family support, financial
support, health insurance levels, overall health, personal health behaviors (e.g., tobacco, physicalactivity, sleep), body mass index, employment status/type, access to care, or education level. Notethat heath factors may be included in the Problem list (CP.1.4) which may include problems orstrengths (e.g., ambulatory status or addictions). An example of an active patient-specific strengthis an elderly parent receiving care from an adult child during the adult child's summer break fromcollege. A patient's care may be affected by certain positive or negative factors. For example,
coverage by insurance (a positive health factor) versus unemployment (a negative health factor).
機能説明：患者の強い点(ポジティブ要因)あるいは弱い点(ネガティブ要因)は、患者ケアや、患者の回復に影響を及ぼす可能性があり、ケア計画や治療オプションの作成を支援するため、EHR の一部として記録され得る。健康に関わる要因としては、家族の支援、経済的支援、保険のレベル、健康状態
全般、個人の行動様式(喫煙、運動、睡眠など)、BMI、雇用状況/種類、ケアへのアクセス、教育レベ
ルなどがある。健康要因はプロブレムリストに記録されることがある。これにはプロブレムや患者の強さ等を含む。強みの例としては、成人した子供が大学休暇中、高齢の親の世話をしている等である。
患者ケアは、何等かのプラスの、あるいはマイナス要因の影響を受ける可能性がある。例えば、保険の適用(プラス要因)や失業(マイナス要因)である。
1. The system SHALL provide the ability to manage, as discrete 135
data, patient-specific Health-Related Factors.
1. システムは、患者固有の健康に関係する要因を、離散的なデータとして管理する機能を提供しなければならない。
2. The system SHALL provide the ability to manage the source of 136
information regarding patient-specific Health-Related
Factors.
2. システムは、患者固有の健康に関する要因についての情報源を管理する機能を提供しなければならない。
3. The system SHALL conform to function RI.1.1.17 137(Deprecate/Retract Record Entries) to enable the inactivation
or deprecation of a patient-specific Health-Related Factors.
3. システムは、患者の健康に関する要因を、イナクティブ化あるいは否認するため、機能 RI.1.1.17(記録入力の否認/取消し)に準じ
なければならない。
CP.1.6FunctionManage Immunization
List
予防接種リストの管理Statement: Create and maintain patient-specific immunization lists.
機能概要：患者の予防接種リストを作成し管理する。
Description: Immunization lists are managed over time, whether over the course of a visit or stay,or the lifetime of a patient. Details of immunizations administered are captured as discrete data
elements including date, type, manufacturer and lot number. The entire immunization history isSection/id#：
Type:
Name:
viewable.

Conformance Criteria

Row#

機能説明: 予防接種リストは、外来、入院時か、また患者の生涯にわたるかを問わず、長期にわたり管理される。予防接種の詳細は、日付、タイプ、工場、ロット番号をはじめとする離散的なデータ要素として把握される。予防接種の履歴は目でみて確認できること。
3. The system SHALL provide the ability to manage, as discrete 148
elements, data associated with an immunization that was not
given to a patient (e.g., due to a contraindication or a patient's
refusal). Data associated with an immunization that was not
given to a patient includes date-and-time, immunization type,
series, exception reason, and immunization-withholding
provider.
3. システムは、(禁忌や患者の拒否等により)患者に投与されなかった予防接種に関連するデータを離散的要素として管理する機能を提供しなければならない。患者に実施されなかった予防接種に関するデータとしては、日付と時間、予防接種の種類、シリー
ズ、例外の理由、予防接種をしなかった医療機関、などである。
4. The system SHALL provide the ability to render (e.g., print or 149
transmit) a report of a patient's immunization history (e.g.,
for appropriate authorities such as schools, day-care centersor public health immunization registries) according to scopeof practice, organizational policy, and/or jurisdictional law.
4. システムは(印刷もしくは伝送等により)患者の予防接種履歴(学校、デイケアセンター、保健所の予防接種登録などの認可機関による)のレポートを表示する機能を提供しなければならない。
5. The system SHALL provide the ability to capture the currently 150
recommended date for a companion immunization (e.g., asubsequent or booster dose) with each immunization (if sucha companion immunization is needed).
5. システムは、予防接種ごとに(もし併用予防接種が必要ならば)併用の予防接種(例えば、その後に接種される、または 2 度目の予防接種) が推奨される日付を把握する機能を提供しなければならない。
6. The system SHALL provide the ability to capture, maintain 151
and render population-based immunization schedules fromrelevant public health immunization authorities (e.g., CDC
for US realm).
6. システムは(米国内では CDC)公的予防接種スケジュールを把握、維持し、表示する機能を提供しなければならない。
CP.1.7152
FunctionManageMedicalEquipment,
Prosthetic/Orthotic,
Device List
義肢・装具のリストの管理Statement: Create and maintain a patient-specific list of medical equipment, medical prosthetic,
orthotic, and/or implantable devices.
機能概要：患者の医療用具、義肢、装具、埋め込み型装置のリストを作成し、維持する。
Description: Details of medical equipment, orthotic/prosthetic, and/or devices are captured as
discrete data elements including information such as device type, date issued, date implanted or
manufactured, device model number, device serial/lot number, manufacturer, supplier, involved
extremity, anatomical location, date of battery change, and other data elements which many berequired to correctly identify and track the equipment/device. The list may link to externalsources, such as the US Food and Drug Administration (FDA), so that the provider may be alertedSection/id#：
Type:
Conformance Criteria
Row#
Name:
if the medical device is recalled. The entire equipment, prosthetic, orthotic, and/or implantabledevice list is able to be rendered.
機能説明: 医療用具、義肢・装具、および(または)埋め込み型装置などの詳細は、個別の離散的なデータ要素として取得される。(例えば装置の型、発行日、装着日、製造日、機器のモデル番号、機器のシ
リアル番号、製造元、サプライヤ、体内の位置、バッテリ交換日、その他、正確に識別し追跡する上で必要な情報。) リコール時に、医療者に警告を出せるように、リストは FDA など外部機関へリンクする場合がある。
1. The system SHALL provide the ability to manage, as discrete 153
data, a patient-specific list of specialized medical equipment,
prosthetic, orthotic, and/or implantable devices.
1. システムは、離散的なデータとして、患者の医療用具、義肢・装具、および(または)埋め込み型装置などを管理する機能を提供しなければならない。
2. The system SHALL provide the ability to capture, maintain 154
and render, as discrete data, the description of each instanceof use of specialized medical equipment, prosthetic, orthotic,
and/or implantable device.
2. システムは、離散的なデータとして、個々の専門的医療機器、義肢、装具、あるいは埋め込み型装置の用途の記載を把握し、維持、表示する機能を提供しなければならない。
4. The system SHALL provide the ability to capture, maintain 156
and render the specific type of specialized medical equipment,
prosthetic, orthotic, and/or implantable device.
4. システムは、特定の型の専門的医療機器、義肢、装具、あるいは埋め込み型装置を把握し維持、表示する機能を提供しなければならない。
5. The system SHALL provide the ability to capture an indication 157
of No Known specialized medical equipment, prosthetic,
orthotic, and/or implantable device for the patient.
5. システムは、専門的医療機器、義肢、装具、あるいは埋め込み型
装置は患者に適用されていないことを、把握する機能を提供しなければならない。
9. The system SHALL provide the ability to render a list of 161
deactivated specialized medical equipment, prosthetic,
orthotic, or implantable devices including the reason fordeactivation.
9. システムは、ディアクティベートされた専門的医療機器、義肢、装具、あるいは埋め込み型装置のリストを、ディアクティベートの理由とともに、表示する機能を提供しなければならない。
CP.1.8164
FunctionManage Patient andFamily Preferences
患者および家族の意向の管理Statement: Capture and maintain patient and family preferences.
機能概要：患者および家族の意向を管理する。
Description: This function is focused on the capture and maintenance of facts on patient/family
preferences. Patient and family preferences regarding issues such as language, religion, spiritual
practices and culture may be important to the delivery of care. It is important to capture these sothat they will be available to the provider at the point of care. Patient/Family preferences differ
from social history and Advance Directives as follows: Social history refers primarily to elementsof a patient's background that may impact on the patient's health (e.g., smoking, drinking,occupation, abuse, etc.). Advance Directives refers to requests regarding care when the patient isSection/id#：
Type:
Conformance Criteria
Row#
Name:
unable to competently make decisions about their own care (e.g., Do Not Resuscitate orders, living
wills).
機能概要：焦点は、患者/家族の意向を把握し、維持することにある。言語、宗教、宗教的習慣、文化等に関わる患者・家族の意向は、ケアの提供上、重要である。ケアを提供する際に医療者が把握できるよう、これらの情報を取得することは重要である。患者/家族の意向は、社会歴や事前指示とは、次のように異なる: 社会歴は、健康に影響する可能性のある患者の背景(喫煙、飲酒、職業、乱用等)に関する基本的事項について言及している。事前指示は自身に対するケアについて、患者本人が完全に決定することができないときに、患者の要求を表す(蘇生処置拒否指示、リビングウィル等)。
1. The system SHALL provide the ability to manage patient 165
preferences (e.g., language(s), religion, spiritual and cultural
practices).
1. システムは、患者の希望(例えば、言語、宗教、精神的・文化的習慣等)を管理する機能を提供しなければならない。
2. The system SHALL provide the ability to manage family 166
preferences (e.g., language(s), religion, spiritual and cultural
practices).
2. システムは、家族の希望(例えば、言語、宗教、精神的・文化的習慣等)を管理する機能を提供しなければならない。
CP.1.9170
FunctionManage Adverse Events
有害事象の管理Statement: Capture and maintain adverse events.
機能概要：有害事象の取得と維持
Description: This function is focused on the capture and maintenance of adverse events that haveoccurred to the patient. The system should capture discrete information about the adverse eventto enable the rendering Serious Adverse Event (SAE) reports according to organizational policy,
and or jurisdictional law. Reporting may conform to the HL7 Individual Case Safety Reporting(ICSR).
機能概要：この機能は、患者に対して生じた有害事象の把握と管理に焦点を当てている。システムは、
有害事象の情報を把握し、重篤な副作用報告を、組織の方針に則って、あるいは法律に則って報告する。報告は、HL7 個別症例安全性報告に準じることがある。
1. The system SHALL provide the ability to manage adverse 171
events associated with a patient.
1. システムは、患者に関連する有害事象を管理する機能を提供しなければならない。
2. The system SHALL capture and maintain as discrete data an 172
adverse event. For example: a) Patient identification b) Event
date/time c) Event description d) Event severity e) Event
category (e.g., medication error, fall) f) Care providers
associated with the event according to scope of practice,organizational policy, and/or jurisdictional law.
2. システムは、業務範囲、組織ポリシー、管轄区域の法律に準じて、有害事象を離散的データとして把握し、管理する機能を提供しなければならない。例えば、a)患者識別子、b)事象の日付/時間、
c) 事象の説明、d) 事象の重症度、e) 事象のカテゴリ(例えば、投与過誤、転倒)、f) 事象に関わるケア提供者、など。
3. The system SHALL provide the ability to capture and render a 173
Serious Adverse Event (SAE) report according toorganizational policy, and/or jurisditional law.
3. システムは、重度の有害事象(Serious Adverse Event: SAE)の報
告を、業務範囲、組織ポリシー、管轄区域の法律に準じて、把握し、表示する機能を提供しなければならない。

CP.2
Function
Renderexternallysourced Information
外部ソース情報提示

175

Statement: Render documentation and data that has been captured from multiple externalsources.
機能概要：複数の外部ソースから取得した文書やデータの提示
Description: Documentation and data relevant to the patient record can be captured from many
external sources and should be rendered appropriately alongside other information in the patient
record. External sources are those outside the EHR system, including clinical, administrative, andfinancial information systems, other EHR systems, Personal Health Record (PHR) systems, anddata received through health information exchange networks.
機能説明：患者記録に関連のある文書やデータは多くの外部ソースから取得可能であり、患者記録の中で他の情報と一緒に適切に提示すべきである。外部ソースとは当該 EHR システム外の、臨床・管理・財務情報システム、他の EHR システム、個人健康記録（PHR)システム、健康情報交換ネトワー
クを通じて得られたデータを含むものである。
CP.2.1176
Function
Renderexternallysourced
ClinicalDocuments
外部ソース診療文書提示
Statement: Render clinical documentation that has been captured from multiple external sources.
機能概要：複数の外部ソースから収集した診療文書の提示
Description: Documentation relevant to the patient record can be captured from many externalsources and should be rendered appropriately alongside other information in the patient record.
機能説明：患者記録に関連した文書は多くの外部ソースから取得可能であり、患者記録の中で他の情報と一緒に適切に提示すべきである。
1. IF the system conforms to CPS.2.1 (Support for externally- 177
sourced Clinical Documents), THEN the system SHALL
provide the ability to render externally-sourced clinicaldocuments.
1. システムが CPS2.1（外部ソースの診療文書の支援）に適合する
場合、システムは外部ソースの診療文書を提示する機能を提供することが要求される。
CP.2.2178
Function
Renderexternallysourced Data
外部ソースデータ提示
Statement: Render data that has been captured from multiple external sources.
機能概要：複数の外部ソースから収集したデータの提示
Description: Data relevant to the patient record can be captured from many external sources andshould be rendered appropriately alongside other information in the patient record (e.g., productlabeling information should be rendered alongside the patient's record).
機能説明：患者記録に関連したデータは多くの外部ソースから取得可能であり、患者記録の中で他の情報と一緒に適切に提示すべきである(例：製品ラベル情報）
1. IF the system conforms to CPS.2.2 (Support for externally- 179
sourced Clinical data), THEN the system SHALL provide theability to render externally-sourced clinical data.

1. システムが CPS2.2（外部ソースの臨床データの支援）に適合す
る場合、システムは外部ソースの臨床データを提示する機能を提供することが要求される。
CP.2.3Function
RenderEmergency
MedicalSystemOriginated Data
救急医療システム発生デ
ータの提示

180

Statement: Render emergency medical data that has been captured from multiple externalsources.
機能概要：複数の外部ソースから収集した救急医療データの提示
Description: Emergency medical data relevant to the patient record can be captured from many
external sources and should be rendered appropriately alongside other information in the patient
record.
機能説明：患者記録に関連した救急医療データは多くの外部ソースから取得可能であり、患者記録の中で他の情報と一緒に適切に提示すべきである。
1. IF the system conforms to CPS.2.3 (Support Emergency 181
Medical System Originated Data), THEN the system SHALL
provide the ability to render Emergency Medical System
Originated Data.
1. システムが CPS2.3（救急医療システムで発生したデータの支援）に適合する場合、システムは外部ソースの救急医療システム
で発生したデータを提示する機能を提供することが要求される。
CP.2.4182
Function
Renderexternallysourced Clinical Images
外部ソース臨床画像提示
Statement: Render clinical images that has been captured from multiple external sources.
機能概要：複数の外部ソースから収集された臨床画像の提示
Description: Clinical Images relevant to the patient record can be captured from many externalsources and should be rendered appropriately alongside other information in the patient record.
機能説明：患者記録に関連した臨床画像は多くの外部ソースから取得可能であり、患者記録の中で他の情報と一緒に適切に提示することが推奨される。
1. IF the system conforms to CPS.2.4 (Support externally-sourced 183
Clinical Images), THEN the system SHALL provide theability to render externally-sourced clinical images.
1. システムが CPS2.4（外部ソースの臨床画像の支援）に適合する
場合、システムは外部ソースの臨床画像を提示する機能を提供することが要求される。
CP.2.5184
FunctionManagePatientOriginated Data
患者由来データ管理
Statement: Capture and explicitly label patient-originated data, link the data source with thedata, and support provider authentication for inclusion in patient health record as well as
subsequent rendering of the information as part of the health record.
機能概要：患者に由来するデータの取得と明示的なラベル付け、データとデータ・ソースをリンク、
そして患者健康記録に含めるための医療提供者の認証し、その後健康記録の一部として情報を提示する。
Description: It is critically important to be able to distinguish clinically authored andauthenticated data from patient-originated data that is either provided by the patient for inclusionin the EHR or entered directly into the EHR by the patient from clinically authenticated data.
Patients may provide data for entry into the health record or be given a mechanism for entering
this data directly. Patient-originated data intended for use by providers will be available for theiruse.
Data about the patient may be appropriately provided by:
1. the patient;
2. a surrogate (parent, spouse, guardian) or
3. an informant (teacher, lawyer, case worker)
4. devices (e.g., blood pressure/sugar monitors).
An electronic health record may provide the ability for direct data entry by any of these. Patientoriginated data may also be captured by devices and transmitted for inclusion into the electronic
health record.
Data entered by any of these must be stored with source information. A provider must
authenticate patient-originated data included in the patient's legal health record. A provider must
be able to indicate they have verified the accuracy of patient-originated data (when appropriate
and when a verification source is available) for inclusion in the patient record. Such verification
does not have to occur at each individual data field and can be at a higher level of the data.
機能説明：臨床的に発生し認証されたデータと、患者由来のデータ（患者によって提供され EHR に含められたものや、臨床的に認証されたデータから患者によって直接 EHR に入力されたもの）を区別できることは非常に重要である。患者は健康記録に入力するためにデータを提供したり、このデー
タを直接入力する方法を提供されたりするかもしれない。医療機関によって利用することを意図されて収集された患者由来のデータは医療機関によって利用される。

患者に関するデータは適宜以下によって提供される：
1.患者;
2.代理人（親、配偶者、後見人）あるいは
3.情報提供者（教師、弁護士、ケースワーカー）
4.デバイス（例 血圧/血糖モニター）

電子健康記録はこれらによる直接データ入力機能を提供できるかもしれない。患者由来データはデバ
イスによって取得され、電子健康記録の中に送信されるかもしれない。

これらいずれかによって入力されたデータはソース情報とともに蓄積されなければならない。医療機
関は患者の法的な健康記録に含まれる患者由来データの認証をしなければならない。医療機関は患者記録に含めるために、患者由来データの正確性を（いつ発生し、いつ検証根拠が得られるか）検証し表明できなければならない。そのような検証は各個人データのフィールドごとに発生すべきではな
く、より上位レベルで行うことができる。
1. The system SHALL provide the ability to capture patient- 185
originated data and tag that data as such.
1. システムは患者由来データを取得し、そのことをデータにタグ付けする機能を提供することが要求される。
2. IF the system provides the ability for the patient to capture 186
data directly, THEN the system SHALL tag the data aspatient captured.
2. システムが患者にデータを直接取得する機能を提供する場合、シ
ステムはそのデータに患者が取得したことをタグ付けすることが要求される。
3. The system SHALL provide the ability to render patientoriginated data.
3. システムは患者由来のデータを表示する機能を提供することが要求される。
6. IF the system conforms to CPS.2.1 (Support for externallysourced Clinical documents), THEN the system SHALL
provide the ability to render externally-sourced clinicaldocuments.
6. システムが CPS2.1（外部ソースの診療文書の支援）に適合する
場合、システムは外部ソースの診療文書を表示する機能を提供することが要求される。

CP.3
HeaderManageClinicalDocumentation
診療文書の管理

187

190

191

Statement: Clinical Documentation must be managed including the capture of the documentation
during an encounter, maintenance and appropriate rendering.
要求事項：診療文書の管理には、受療期間の文書取り込み、その後の維持、および適切な提示といった観点が含まれる。
Description: Clinical documentation includes all documentation that the clinician may capture
during the course of an encounter with the patient or relevant to the patient. This includes
assessments, clinical measurements, clinical documents and notes, patient-specific care andtreatment plans. Management of clinical documentation also includes the acknowledgement andamendments of documentation provided by other providers.
機能説明：診療文書には、臨床家が患者や患者に関連する受療期間の情報に取り込まれるすべての文書が含まれる。これには、アセスメント、臨床指標、診療文書、メモ、患者個別の治療計画が含まれる。診療文書の管理には受信通知、他の医療関係者によって提供されるドキュメントの修正も含まれる。
CP.3.1
192
Function
Conduct Assessments
アセスメントの実施
Statement: Create and maintain assessment information.
要求事項：アセスメント情報の作成と維持
Description: During an encounter with a patient, the provider will conduct an assessment that isgermane to the age, gender, developmental or functional state, medical and behavioral conditionof the patient, such as growth charts, developmental profiles, and disease specific assessments.
Wherever possible, this assessment should follow industry standard protocols although, forexample, an assessment for an infant will have different content than one for an elderly patient.
When a specific assessment template does not exist, a new, locally-defined assessment can becreated, using the format and data elements of similar assessments whenever possible. (NOTE: A
new assessment may not necessarily be unique, since a facility may copy an assessment fromanother facility.)
機能説明：患者の受療期間、医療関係者は年齢、性別、発育、機能状態、患者の病状や振る舞い（例
えば、成長曲線、成長プロフィール、疾患に特異なアセスメント等）に適したアセスメントを実施する。可能な限り、このアセスメントは標準のプロトコルに従うべきである。しかし、例えば、幼児向けのアセスメントは高齢者向けの内容とは異なる。（注釈：一つの施設が他の施設のアセスメントをコピーすることがあるため、新しいアセスメントは必ずしも唯一のものではない）
CP.3.2FunctionManage Patient ClinicalMeasurements
患者の臨床指標の管理

212

Statement: Capture and manage patient clinical measures, such as vital signs, as discrete patient
data.
要求事項：臨床測定情報（バイタルサインや離散的な患者データ等）の取り込みと管理
Description: Within the context of an episode of care, patient measures such as vital signs arecaptured and managed as discrete data to facilitate reporting and provision of care. Other clinicalmeasures (such as expiratory flow rate, size of lesion, etc.) are captured and managed, and may
be discrete data.
機能説明：治療の過程において、報告を容易にし、ケアを提供するため、バイタルサインのような患者の測定情報は取り込まれ、離散データとして管理される。その他の測定情報（呼気流量、病変の大きさ等）は取り込まれ、管理される。これらは離散データになるかもしれない。
1. The system SHALL provide the ability to capture patient vital 213
signs (e.g., blood pressure, temperature, heart rate,
respiratory rate, and pain scale) as discrete elements ofstructured or unstructured data.
システムは、構造化されるかされないに関わらず、離散的な要素としてバイタルサイン（血圧、体温、心拍数、呼吸数、痛みの強さ等）を取り込める機能を提供しなければならない。
5. The system SHALL provide the ability to capture mood, 217
behavior and daily functioning as structured or unstructureddata.
システムは、構造化されるかされないに関わらず、気分、振る舞
い、日々の行動を取り込める機能を提供しなければならない。
9. The system SHALL provide the ability to capture both the time 221
the clinical measurement was taken as well as the time it wasentered into the system, including measurements from anancillary system or external device.
システムは、臨床指標を測定した時刻とシステムに入力された
時刻を両方取り込める機能を提供しなければならない。それには、補助的なシステムや外部デバイスからの情報も含む。
CP.3.3230
FunctionManageClinicalDocuments and Notes
診療文書とメモの管理
Statement: Create, addend, amend, correct, authenticate, maintain, present and close, as needed,transcribed or directly-entered clinical documentation and notes.
要求事項：転写された、もしくは、直接入力された診療文書とメモの作成、追加、修正、訂正、維持、
提示、クローズ
Description: Clinical documents and notes may be unstructured and created in a narrative form,
which may be based on a template, graphic, audio, etc. The documents may also be structured
documents that result from the capture of coded data. Each of these forms of clinicaldocumentation is important and appropriate for different users and situations. To facilitate themanagement and documentation on how providers are responding to incoming data on orders andresults, there may also be some free text or formal record on the providers’ responsibility, and/or
standard choices for disposition, such as Reviewed and Filed, Recall Patient, or Future Follow Up.
The system may also provide support for documenting the clinician’s differential diagnosis

process.
機能説明：診療文書とメモは、テンプレート、画像、音声等をベースとした構造化されない文章で記述されている場合がある。診療文書は、コード化されたデータから取り込まれた構造化されたドキュメントの場合もある。診療文書のこれらの形式それぞれは、異なるユーザやシチュエーションにおいて重要であり、適切である。医療関係者がオーダや結果のデータに対してどのように反応しているかを管理と文書化を支援するため、フリーテキストや、医療関係者の責任および見直しとファイリング、
患者の呼び戻し、将来のフォローアップのような処理の標準的な選択に基づいた、公式の記録もあるかもしれない。システムは、臨床家の異なる診断プロセスのドキュメント化の支援を提供する。
1. The system SHALL provide the ability to capture and render 231
clinical documentation as 'structured', and/or 'unstructured'data.
システムは、構造化された、または構造化されない診療文書を作成でき、提示する機能を提供しなければならない。
7. The system SHALL provide the ability to update 237
documentation prior to finalizing it.
システムは、それをファイナライズするまえに、更新できる機能を提供しなければならない。
8. The system SHALL provide the ability to tag a document or 238
note as final, according to scope of practice, organizational
policy, and/or jurisdictional law.
システムは、経験の範囲や組織ポリシー、管轄区域の法律に従って、診療文書やメモに最終版であることを示すタグをつけられる機能を提供しなければならない。
9. The system SHALL provide the ability to render all author(s) 239
and authenticator(s) of documentation.
システムは、ドキュメントのすべての作成者と認証コードを提示する機能を提供しなければならない。
20. IF the system provides the ability to save partially completed 250
clinical documentation, THEN the system SHALL render thisdocumentation only to the authorized users (e.g., author or
author's supervisors).
もし、システムが作成中の診療文書を保存できるなら、システム
は、そのドキュメントが限定されたユーザ（例えば、作成者とその指導教官）のみが提示しなければならない。
CP.3.4253
FunctionManage Patient-Specific
Care and Treatment
Plans
患者固有の診療と治療計
画Statement: Provide templates and forms for clinicians to use for care plans, guidelines andprotocols during provision of care and care planning.
要求事項：臨床家がケアとケアプランを提供する間に、ケアプランとガイドラインとプロトコルとして使うためのテンプレートとフォームの提供
Description: During the provision of care, the clinician reviews and uses templates and forms toensure consistent quality patient care. Care plans, guidelines or protocols may contain goals or
targets for the patient, specific guidance to the providers, suggested orders, and nursing
interventions, among other items, including alerts. Information such as Order sets for care plans
may arrive from an external institution and need to be approved locally before being inserted into
the care plan. Tracking of implementation or approval dates, modifications and relevancy to
specific domains or context is provided. Transfer of treatment and care plans may be implemented
electronically using, for example, templates, or by printing plans to paper.
機能説明：ケアを提供する間、臨床家は、患者に対するケアが一定品質であることを保証するためにテンプレートとフォームをレビューし使用する。ケアプラン、ガイドラインやプロトコルは、警告を含んだ様々なアイテムやオーダ、看護介入を提供したり、サジェストしたりするために、患者や固有のガイダンスのゴールやターゲットを含むかもしれない。ケアプランのためのオーダセットのような

情報は、外部の団体から手に入れるかもしれない。その場合、ケアプランに入れる前に内部で承認される必要がある。実施や承認日、変更と特異的領域や診断の流れと関係の追跡が提供される。治療とケアプランの伝達は、例えばテンプレートにより電子的に実施されたり、紙に印刷されたりして実施されるかもしれない。
1. The system SHALL provide the ability to manage patient- 254
specific plans of care and treatment.
システムは、患者固有のケアや治療計画を管理できる機能を提供しなければならない。
2. The system SHALL conform to function CP.7.1 (Present 255
Guidelines and Protocols for Planning Care) and provide theability to render locally or non-locally developed templates,
guidelines, and protocols for the creation of patient-specificplans of care and treatment.
システムは、CP.7.1（Present Guidelines and Protocols forPlanning Care）に従い、内部外部を問わず、患者固有のケアや治療の計画を作るためのテンプレート、ガイドライン、プロトコ
ル提示する機能を提供しなければならない。
15. The system SHALL provide the ability to capture, maintain 268
and render, as discrete data, the reason for variation fromrule-based clinical messages (e.g., alerts and reminders).
システムは、離散的なデータやルールに基づいた診療上のメッ
セージ（警告やリマインダー）から変化の理由を取り込み、管理し、提示する機能を提供しなければならない。
17. The system SHALL provide the ability to capture care 270
processes across the continuum of care.
システムは、継続したケアのなかで、ケアの過程を取り込める機
能を提供しなけれはならない。
19. The system SHALL provide the ability to render internal care 272
plans, guidelines, and protocols according to scope of practice.
システムは、経験の範囲に従って、内部のケアプラン、ガイドラ
インやプロトコルを提示する機能を提供しなければならない。
CP.3.5274
Function
Acknowledge/Amend
Other
ProviderDocumentation
その他の医療関係文書の承認と修正Statement: Review and indicate or amend other caregiver notes as permitted.
要求事項：許可されたその他の介護者のメモのレビューと指摘、修正
Description: Scan/review notes from physicians, nurses, technicians and other members of thehealth care team (e.g., Respiratory Therapist, Physical Therapist). Annotate for disparities, makeadditions/amendments and import when desired and permitted.
機能説明：医師、看護師、専門技師やその他のヘルスケアチーム（例えば、呼吸療法士や理学療法士）
からの文書のスキャンとレビュー要求。差異の注釈、追加／修正、求められ許可された時インポート。
3. The system SHALL provide the ability for a user (e.g., 277
supervising clinician) to annotate regarding his/her role inadvising, and/or providing direct care according to scope ofpractice, organizational policy, and/or jurisdictional law.
システムは、経験の範囲や組織ポリシーや管轄区域の法律に従った直接的なケアのアドバイスと提供を行う役割を、利用者（臨床家の管理者）に、提供できなければならない。
CP.4
FunctionManage Orders

280

Statement: Provide the ability to manage clinical orders and results including medication, nonmedication, diagnostic tests, blood products, other biologics and referrals, using order sets asappropriate.
正確にオーダセットを使うことで臨床オーダ、投薬や非投薬、診断試験、血液製剤、生物製剤や紹介などの結果を管理する能力を提供する。
Description: The provision of clinical care includes the need to order from a variety of treatments
using order sets as appropriate as well as reviewing the results of treatment. Orders fortreatments may include medications, non-medication therapies (e.g., physical therapy, special
diet, immunizations, non-allopathic regimens); diagnostic care (e.g., laboratory , radiology); blood
products and other biologics (e.g., blood transfusions, human growth hormones). Patients are often
referred to other health care providers for more specialized diagnostic workup, and/or treatment.
An effective EHR-S must include support and management of these processes and associateddocumentation.
適切なオーダセットの使用だけでなく、治療結果を見直すなど様々な治療法から、臨床ケアを提供する必要がある。治療オーダは投薬や非投薬治療（例：理学療法や特別食、予防接種、対症療法計画など）、診断治療（例：研究、放射線医学など）、血液製剤や生物製剤（例：輸血、成長ホルモンなど）を含むかもしれない。患者はもっと特別な精密検査や治療のために、しばしば他の医療提供者に紹介される。効果的な EHR システムはこれらの過程と関連する証拠書類の管理と支援を行わなければいけない。
1. The system SHALL provide the ability to manage role-based, 281
context-based, and/or user-based order entry.
職種、状況、ユーザに応じて、オーダエントリ方法を管理する機能を提供すること
2. The system SHALL provide the ability to manage the creation, 282
renewal, modification and discontinuation of orders.
オーダの追加、更新、修正、中止する機能を提供すること。
3. The system SHALL provide the ability to render relevant, 283
patient-specific laboratory test results when entering anorder.
オーダ入力時の臨床検査結果とのその関連性を表示する機能を提供すること。
4. The system SHALL provide the ability to manage the status of 284
an order (e.g., open, completed, in process).
オーダのステータス（オープン、完了、作業中）を管理する機能を提供すること。
7. The system SHALL provide the ability to capture and render 287
problem/diagnosis as an element of an order.
オーダの要素として、プロブレム／診断を取り込み、表示する機
能を提供すること。
10. The system SHALL provide the ability to annotate and render 290
comments and instructions with an order.
オーダ時のコメントや説明を表示、付加する機能を提供すること。
14. The system SHALL render patient identifying information 294(e.g., the patient name, identification number, and age or dateof birth) on all order screens, according to scope of practice,organizational policy, and/or jurisdictional law.
管轄法、組織の方針、管轄の範囲に従って、全てのオーダ画面上に、患者の個人情報（患者の氏名、ＩＤ、日齢等）を提示する機能を提供すること。
15. The system SHALL provide the ability to capture, maintain 295
and render an indicator of oral verification ("read-back") of thecomplete order by the person receiving the telephone or verbal
order.
電話によるオーダ又は口頭によるオーダによる口頭確認の指示
者の取込、管理、提示する機能を提供すること。
16. The system SHALL provide the ability to capture and render 296
the urgency status (e.g., As-Soon-As-Possible or STAT)
associated with an order.

CP.4.1
Function
Use Order Sets

オーダの緊急性のステータス（As-Soon-As-Possible or STAT）
等を取込、提示する機能を提供すること。
21. The system SHALL provide the ability to capture, store and 301
render the identity of all providers who signed an order
including their name and credential identifier.
資格証明やオーダの署名等、全ての従事者の一意性を取込、管理、提示する機能を提供すること。
27. The system SHALL provide the ability to determine and 307
capture co-signatures for orders based upon roles (e.g.,
consulting physician) according to scope of practice,organizational policy, and/or jurisdictional law.
管轄法、組織の方針、管轄の範囲に従った職制（コンサルティン
グ、勤務医）による、オーダの共同署名の決定、および取り込む機能を提供すること。
308

Statement: Use Order Set templates to facilitate order entry by rendering the appropriate orders
based on provider request, input or system configuration.
オーダセットテンプレートを利用し、医療提供者の要求や入力あるいはシステム設定に基づいた適切なオーダを提示することで、オーダ登録を容易にする。
Description: Predefined order set templates may include medication and non-medication orders(e.g., diet, activities, nursing care, prescriptions and requests for investigations). They allow a careprovider to choose common orders for a particular circumstance or disease state according tostandards or other criteria such as provider preference. Recommended order set templates may
be presented based on patient data or other contexts. Order Set templates may also allow theprovider to modify (add/remove/change) orders during order entry for a particular patient.
オーダセットテンプレートを利用し、医療提供者の要求や入力あるいはシステム設定に基づいた適切なオーダを表示することで、オーダ登録を容易にする。
1. The system SHALL provide the ability to capture a set of 309
actions, and/or items to be ordered for a patient using apredefined order set template.
ひとまとまりのアクションおよび/またはアイテム、それらは患者に対してあらかじめ決められたオーダセットテンプレートを使ってオーダされたものであるが、それらを保存できる機能を提供すること。
2. The system SHALL provide the ability to maintain a patient's 310
orders as an order set.
患者のオーダをオーダセットとして管理できる機能を提供すること。
5. The system SHALL conform to function CPS.4.1 (Manage 313
Order Set Templates).
CPS.4.1 の機能（オーダセットテンプレートの管理）に準ずる機能を提供すること。
7. The system SHALL provide the ability to capture and integrate 315
in an order set, various types of orders for a patient (e.g.,
medications, laboratory tests, imaging studies, procedures
and referrals).
患者に対する様々な種類のオーダ（例えば、medication 投薬、
臨床検査、画像診断、処置、そして紹介）をオーダセットに保存
して統合できる機能を提供すること。
CP.4.2320
FunctionManageMedication
OrdersStatement: Create prescriptions or other medication orders with detail adequate for correct filling
and administration. Provide information regarding compliance of medication orders withformularies. Provide drug utilization review functionality including alerts regarding druginteractions and allergies.
正しい調剤と投薬のために、処方箋や、他の処方指示を詳細かつ的確に作成すること。処方指示する
際に、処方薬リスト（医療機関で採用されている医薬品目）の遵守に関連する情報を提供すること。
処方関連の診療内容審査機能（例えば薬物相互作用やアレルギー関連の警告機能）を提供すること。
Description: Medications include prescribed and over the counter (OTC) drugs, allergy shots,oxygen, anesthetics, chemotherapy, and dietary supplements that were ordered, supplied,administered, or continued. Different medication orders, including new, discontinue,
refill/continue, and renew require different levels and kinds of detail, as do medication orders
placed in different situations. Administration or patient instructions are available for selection by
the ordering clinician, or the ordering clinician is facilitated in creating such instructions. The
system may allow for the creation of common content for prescription details. Appropriate timestamps for all medication related activity are generated. This includes series of orders that arepart of a therapeutic regimen, e.g., Renal Dialysis, Oncology. When it comes to capturing the
medication rationale, it is not mandatory that the provider always provide this information.
In addition, the system should present the clinician with clinical decision support functionality(such as the presentation of allergies, drugdrug interactions) during the medication ordering
process. When a clinician places an order for a medication, that order may or may not comply witha formulary specific to the patient’s location or insurance coverage, if applicable. Whether theorder complies with the formulary should be communicated to the ordering clinician at an
appropriate point to allow the ordering clinician to decide whether to continue with the order.
Formulary-compliant alternatives to the medication being ordered may also be presented.
ここでいう投薬とは、処方された薬、店頭で買える（OTC の）薬品、アレルギー注射、酸素、麻酔薬、
化学療法、および栄養補助食品を含んでいる。それらは指示、供給、投薬あるいは継続される。様々な状況に応じた処方オーダを行えるように、新規、中止、追加/継続、再発行を含む処方オーダについては、様々なレベルと詳細な種類が必要とされる。処方オーダする臨床医は、投薬や患者への指示を選択することが可能であり、あるいはそのような指示を作成することが容易となる。システムによって、処方の詳細に関する共通内容の作成が可能になる場合がある。全ての処方に関連した活動については、適切なタイムスタンプが生成される。これには、例えば腎臓透析、腫瘍学といった一部の治療計画の一連のオーダが含まれる。処方の基本原理を捉えるという観点では、この情報（タイムスタンプ）を提供することは必ずしも義務ではない。
さらに、臨床医が処方オーダするときに、診療決定支援機能（例えばアレルギーや薬物間相互作用の提示）がシステムによって提供される。臨床医が処方オーダするとき、そのオーダが、患者の所在地に準拠した処方薬リスト、あるいは保険の保障範囲に準拠した処方薬リストに沿う場合もあれば、そうでない場合もある。そのオーダを継続してもよいのかを臨床医が決定できるように、該当のオーダが処方薬リストに準拠するかどうかという情報は、適切なポイントで臨床医に伝えられるべきである。処方薬リストに沿った代替の処方オーダが提示される場合もある。
1. The System SHALL conform to CP.4.2.1 (Medication 321
Interaction and Allergy Checking).
システムは CP.4.2.1 (薬物の相互作用とアレルギーチェック)を準拠することすること。
2. The System SHALL conform to CP.4.2.2 (Patient-Specific 322
Medication Dosing & Warnings).
システムは CP.4.2.2 (患者特異的薬物療法投薬と警告)を準拠すること。
3. The System SHALL conform to CP.4.2.3 (Medication Order 323
Efficiencies).
システムは CP.4.2.3 (処方指示の効率性) を準拠すること
4. The system SHALL conform to CP.4.2.4 (Medication Alert 324
Overrides).
システムは CP.4.2.4 (処方警告のオーバーライド) を準拠する
こと。
5. The system SHALL provide the ability to capture medication 325
order details as discrete data for correct filling, dispensing
and administration of drug (e.g., dose, route, physical form,
duration, SIG).
システムは、正確な調剤、投薬、薬剤の管理（例えば服用量、投与経路、形状、投薬期間、用法）のために個別のデータとして、

CP.4.2.1

投薬情報の詳細を保存する機能を提供すること。
6. The system SHALL provide the ability to maintain and 326
render, as discrete data, medication orders including all thedetails adequate for correct filling, dispensing andadministration (e.g., drug, dose, route, SIG).
システムは、正しい調剤、調合、投薬のために適切な、あらゆる詳細情報（例えば、薬物、服用量、投与経路、用法）を含む処方
オーダを、個別のデータとして保持し、提示する機能を提供すること。
10. The system SHALL determine and render a notification to the 330
provider that information required to compute a dose is
missing or invalid.
システムは、投与量を計算するのに必要な情報が欠落、あるいは無効であることを判断し、医療提供者に通知する機能を提供すること。
13. The system SHALL provide the ability to capture and 333
maintain documentation regarding patient weight, including
such terms as "unknown", before entering medication orders.
システムは、処方オーダ入力前に、患者の体重に関する文書（「不明」も含む）を取り込み保持する機能を提供すること。
15. The system SHALL provide the ability to determine and 335
render the status of a medication order (e.g., for outpatient
medication ordering: captured, verified, filled, or dispensed topatient; for inpatient: captured, verified, filled, or medication
administered).
システムは、投薬情報のステータス（例えば、外来患者に対する投薬状況としては、保存、確認、調剤、患者に提供がある。また、入院患者に対する投薬状況としては、保存、確認、調剤、投与済
み）を判断し、提示する機能を提供すること。
17. The system SHALL conform to function CP.1.3 (Manage 337
Medication List) and update the appropriate medication list
with the prescribed medications (in case of multiple
medication lists).
システムは、CP.1.3 機能(処方リストの管理)に従い、（多数の処方リストが存在する場合には）処方治療に関する適切な処方リストを最新化する機能を提供すること。
18. The system SHALL provide the ability to enter and maintain 338
medication information supplied by the patient.
システムは、患者によってもたらされた処方情報を入力し、保持する機能を提供すること。
26. The system SHALL provide the ability to order supplies 346
associated with medication orders according to scope ofpractice, organizational policy, and/or jurisdictional law.
システムは、実際のスコープ、組織的なポリシー、かつ/または管轄法に従い、処方オーダに関連した供給を指示する機能を提供すること。
35. The system SHALL provide the ability to manage orders that 355
contain discrete medication components to create combination
drugs or compounds (e.g., Butalbital compound).
システムは、混合薬、化合物（例えばブダルビタール化合物のような）を製造するために、個別の薬物の要素を含むオーダを管理する機能を提供すること。
37. The system SHALL track the number of times that a 357
prescription was transmitted (to maintain a constraint on thenumber of times that a prescription is permitted to betransmitted for printing/ reprinting and faxing/re-faxing).
システムは、処方が送信された回数を追跡すること。
（処方は印刷や再印刷、Fax 送信や Fax 再送信のために、送信することが許可された回数に対する規約を維持するために。
）
366

Function
Medication Interaction
and Allergy Checking
Statement: Provide alerts for potential medication interactions and medication allergy reactions.
薬物の相互作用とアレルギー反応のアラート機能の提供
Description: Check and provide alerts at the time of medication order based upon coded, active
and non-active medications for possible interactions, allergies, sensitivities, intolerances, andother adverse reactions.
相互作用、アレルギー、薬物過敏症、不耐性、および他の副作用等、コードを元にした薬物オーダ時のチェックとアラートの提供
1. The system SHALL conform to function CPS.4.2.1 (Support for 367
Medication Interaction and Allergy Checking) to determine
allergic reactions, drug-drug interactions, and other potential
adverse reactions, and render alerts or notifications when new
medications are ordered.
システムは新しい処方がオーダされる際にアレルギー反応、薬物相互作用、その他の潜在的な副作用を判断する為、警告、注意を提示する為に CPS.4.2.1（薬物の相互作用とアレルギーチェッ
クの支援）の機能を提供すること。
3. The system SHALL conform to function CP.1.2 (Manage 368
Allergy, Intolerance and Adverse Reaction List) to provide theability to manage interaction and allergy checking and render
alerts and notifications when new medications are ordered.
システムは、新規に処方オーダを発行する際に、相互作用とアレルギーのチェックを管理し、警告や通知を表示すう機能を提供するために、CP.1.2(アレルギー、飲食物の過敏症、副作用リストの管理)を準拠すること。
5. The system SHALL provide the ability to render and tag as 371
inactive recently inactivated medications for inclusion incurrent medication screening according to scope of practice,organizational policy, and/or jurisdictional law.
システムは、法律的に許される行動、組織の方針、管轄の範囲に従って、最新の薬剤スクリーニングに含まれる非活性化された処方を提示し、非活性としてタグ付けする機能を提供すること。
CP.4.2.2
372
Function
Patient-Specific
Medication Dosing andWarnings
Statement: Render medication dosing and warnings related to a medication order based on
patient-specific parameters.
患者固有のパラメータに基づく投薬指示と投与量に関する警告の提示
Description: Provide parameter-based (e.g., weight, lean body mass, age, sensitivity, genomics,
body surface area) medication dosing recommendations and warnings for simple medications andcompounded medications at the time of order entry.
薬剤オーダ入力時に、簡易的な投薬と調剤のためのパラメータに基づく（例えば、体重、除脂肪体重、
年齢、感度、遺伝、体表面積）投与量の推奨や警告の提供
1. The system SHALL conform to function CPS.4.2.2 (Support for 373
Patient-Specific Dosing and Warnings) to determine potential
adverse reactions and render alerts or notifications when new
medications are ordered.
システムは潜在的な副作用を判断する為、新しい処方がオーダされたときに警告または通知を提示する為に、CPS.4.2.2 (患者
特異的薬物療法投薬と警告)の機能を提供すること。
12. The system SHALL provide the ability to determine and 384
present drug dosing based on custom compounded medication

components.
システムは個別に調剤された処方の成分に基づいて薬品の用法を規定、提供する機能を提供すること。
CP.4.2.3
Function
Medication
Efficiencies

386
Order

Statement: Provide the tooling necessary to increase the efficiency of medication ordering.
効率的に薬剤オーダを支持するのに必要なツールの提供
Description: Make medication ordering workflows more efficient by allowing medications to besorted and reviewed by key attributes (e.g., generic or trade names). Also support editing
medication orders across multiple instances of an order and capturing medication orders in ordersets.
キーとなる属性（例えば、ジェネリックや商品名）により薬剤をソートすることで、薬剤オーダリン
グのワークフローをより効果的にする。また、複数インスタンスに跨った薬剤オーダの編集とオーダ
セットへの薬剤オーダの保存をサポートする。
7. The system SHALL conform to CP.4.1 (Use Order Sets).
393
システムは CP.4.1 (オーダセットの使用)に準拠すること。
7. The system SHALL provide the ability to extract and render 394
medications by generic, and/or brand name.
システムは一般名もしくは商品名から処方を抽出し提示する機能を提供すること。
CP.4.2.4
395
Function
Medication
Alert
Overrides
Statement: Capture the alerts and warnings for medications being overridden and reasons for theoverride.
投薬や予防接種を指示する際に起こりうるミス（患者や薬剤、適用量、手順、時間などの間違い）などを警告する機能を提供する
Description: Alerts are generated for possible contraindications to administration of medications(e.g., the administration of tetracycline to pregnant women) and the prescriber may choose to
override the alert.
投薬管理（例えば、妊婦に対するテトラサイクリンの管理）において禁忌の可能性がある場合は警告を表示する。また、処方者が警告を無効化を許可する。
1. The system SHALL provide the ability to edit a medication 396
order by overriding the drug alert or warning andtransmitting the updated medication order.
優先される薬品の警告もしくは注意書きと、更新された処方オーダの順番に処方を編集する機能を提供すること。
2. The system SHALL provide the ability to capture reasons for 397
overriding a drug alert or warning at the time of ordering.優
先される薬品の注意や警告をオーダのタイミングで捕捉する機能を提供すること。
（例えば、薬品用法注意喚起）
3. The system SHALL provide the ability to tag and render an 398
indication that a provider has overridden a drug alert or
warning.提供者が薬品の警告や注意を優先した指示をタグ付けし提示する機能を提供すること。
CP.4.3399
FunctionManage Non-Medication
Patient Care Orders
Statement: Enable the origination, documentation, capture, transmission, tracking andmaintenance of non-medication patient care orders.
非服薬患者診療オーダの作成、文書化、保存、転送、追跡、メンテナンスを可能にする。
Description: Non-medication orders that request actions or items can be captured and tracked

including new, renewal and discontinue orders. Examples include orders to transfer a patient
between units, to ambulate a patient, for medical supplies, wound care, durable medical
equipment, home IV, and diet or therapy orders. Additionally, psychotherapy and other mental
health counseling, behavioral counseling (e.g., smoking cessation, alcohol treatment) othersurgical and non-surgical procedures, and complementary alternative medicine are included in
non-medication treatments. Each item ordered includes the appropriate detail, such as orderidentification and instructions. Orders should be communicated to the correct service provider forcompletion.
行為やアイテムを必要とする非服薬オーダが保存され、追跡される。それは新規作成されたものや更新されたもの、また中止されたオーダを含む。例としては、医療ユニット間で患者を引き渡すためのオーダ、歩行訓練のオーダ、医療品、創傷処置、永続性のある医療機器、在宅医療、食事、心理療法のためのオーダが含まれる。加えて、精神療法やその他のメンタルヘルスカウンセリング、その他の外科的あるいは非外科的な処置、補足的な代替の内科的治療が非服薬療法に含まれる。オーダされたそれぞれの項目は、オーダの特定と指示のような適当な詳細を含む。オーダは完了するために正しい
医療提供者に伝達されるべきである。
1. The system SHALL provide the ability to manage non- 400
medication patient care orders for an action or item.
システムは、医療行為やアイテムに対する非薬物療法患者診療
オーダを管理できる機能を提供すること。
2. The system SHALL provide the ability to capture and render 401
order detail for correct order fulfillment.
システムは、正しいオーダの遂行のためにオーダの詳細を取得
して、提示できる機能を提供すること。
3. The system SHALL provide the ability to manage the status 402(e.g., active, discontinued, requisitioned, completed) of theordered action or item.
システムは、オーダされたアクションあるいはアイテムの状態（例えば、有効、中断、オーダ発行済、完了）を管理できる機能を提供すること。
9. The system SHALL conform to function CPS.4.3 (Support for 408
Non-Medication Ordering).
システムは、CPS.4.3 の機能（非薬物療法オーダの処理）に準ずる機能を提供すること。
CP.4.4409
FunctionManageOrdersfor
Diagnostic/Screening
Tests
Statement: Enable the origination, documentation, transmission, tracking and maintenance oforders for diagnostic tests.
診断検査オーダの作成、文書化、転送、追跡、およびメンテナンスを可能にする。
Description: Orders for diagnostic tests (e.g., diagnostic radiology, laboratory ) are captured andtracked including new, renewal and discontinue orders. Each order includes appropriate detail,such as order identification, instructions and clinical information necessary to perform the test.
Orders and supporting detailed documentation shall be communicated to the service provider forcompletion of the diagnostic test(s).Some systems may contain instructions, but in some settings,
instructions may be provided from external sources (e.g., handouts).
診断検査のためのオーダ(例.放射線診断、臨床検査)は保存され追跡される。それは新しいもの、更新されたもの、中止になったものを含む。各オーダは検査を実施するのに必要なオーダ確認や、指示や診療情報等の適切な詳細を含んでいる。オーダとそれを補足する詳細な文書は、診断のための検査完了のために医療提供者に伝達されなければならない。システムによってはシステム上に指示が含まれるのが望ましいが、設定によっては指示が外部情報源から提供されるのが望ましい場合もある(例.印刷物)。
1. The system SHALL provide the ability to manage orders for 410
diagnostic tests.
システムは、診断検査のためのオーダを管理できる機能を提供すること。
2. The system SHALL provide the ability to capture and render 411
standard order detail for diagnostic test order fulfillment.

システムは、診断検査オーダの遂行のために標準的なオーダの詳細を保存し提示できる機能を提供すること。
4. The system SHALL provide the ability to manage the status(e.g., requisitioned, completed, in process) of diagnostic test(s).
システムは、診断検査の状態（例えば、オーダ発行済、完了、処理中）を管理できる機能を提供すること。
6. The system SHALL provide the ability to transmit orders to
the recipient (s) for order fulfillment of the diagnostic test.
システムは、診断検査のオーダを遂行するために、受診者に対してオーダを送信できる機能を提供すること。
8. The system SHALL conform to function CPS.4.3 (Support for
Non-Medication Ordering).
システムは、CPS.4.3 の機能（非薬物療法オーダの処理）に準ずる機能を提供すること。
CP.4.5FunctionManage Orders for Blood
Products and Other
Biologics

413

415

417

422

Statement: Communicate with appropriate sources or registries to manage orders for blood
products or other biologics.
血液製剤や他の生物製剤のオーダを管理するための発行元とのコミュニケーション
Description: Interact with a blood bank system or other source to support orders for blood products
or other biologics including discontinuance orders. Use of such products in the provision of care iscaptured. Blood bank or other functionality that may come under jurisdictional law or otherregulation (e.g., by the FDA in the United States) is not required; functional communication withsuch a system is required.
血液製剤や他の生物製剤のオーダ（中止オーダを含む）をサポートするために血液バンクシステムあるいは他の発行元とコミュニケーションする。ケア提供においてそのような製品を使用することは注目されている。血液バンクや他の機能自体が管轄法や規約 (アメリカ食品医薬品局発行の規約のような) に準じる必要はないが、それらのシステムとの機能的な通信が必要である。
1. The system SHALL provide the ability to manage orders for 423
blood products and biological products.
血液製剤や他の生物製剤オーダが管理できる機能を提供すること。
2. The system SHALL provide the ability to manage the status 424(e.g., requisitioned, completed, in process) of blood product,
and/or biological product orders.
血液製剤や他の生物製剤オーダの状態（依頼中、完了済、実施中）が管理できる機能を提供すること。
3. The system SHALL provide the ability to manage storage 425
request orders for blood products, and/or biological products.
血液製剤や他の生物製剤の在庫を要求するオーダが管理できる機能を提供すること。
4. The system SHALL provide the ability to manage the status of 426
storage request orders (e.g., requisitioned, completed, inprocess) for blood products, and/or biological products.
血液製剤や他の生物製剤の在庫を要求するオーダの状態（依頼中、完了済、実施中）が管理できる機能を提供すること。
5. The system SHALL conform to function CPS.9.2 (Support for 427
Inter-Provider Communication) to provide the ability to
exchange blood product, and/or biological products between
members of the care team.
血液製剤や他の生物製剤に関する管理情報のケアチーム内メン
バー間でのやりとりを可能にするため、CPS.9.2 (ケア提供者間のやりとりのサポート) に準ずる機能を提供すること。
6. The system SHALL provide the ability to manage the use of 428
blood products and other biologics in the provision of care.ケ
ア提供における血液製剤や他の生物製剤の使用が管理できる機能を提供すること。
CP.4.6FunctionManageReferral430
OrdersforStatement: Enable the origination, documentation and tracking of referrals between careproviders or healthcare organizations, including clinical and administrative details of the referral,and consents and authorizations for disclosures as required.
紹介患者の診療情報と管理上の詳細情報、また必要に応じて情報開示の同意書・委任状を含む、患者紹介情報の作成、書類化、トラッキングをケア提供者間または医療機関間で可能とする。
Description: Documentation and tracking of a referral from one care provider to another is
supported, whether the referred to or referring providers are internal or external to the healthcareorganization. Guidelines for whether a particular referral for a particular patient is appropriate
in a clinical context and with regard to administrative factors such as insurance may be provided
to the care provider at the time the referral is created. The EHR-S provides the ability to receive
and act upon referral responses from providers. The EHR-S may provide the ability to capturecompletion of the referral appointment. Referrals may be received electronically (i.e. e-Referrals);or may be received non-electronically. If non-electronic, the system needs to allow the user tocapture the referral information and manage referral request. If the system supports e-Referrals,then the system will also need to support additional functionality to manage the receipt of thereferral request.
ケア提供者から別のケア提供者への紹介患者の書類化、トラッキングは、紹介する側ないしされる側の事業者が医療機関の内部関係者か外部関係者かによらず、サポートされる。
ある患者に対しての紹介が臨床上の状況や、保険などの管理運営上の状況下で適切かどうかのガイド
ラインが紹介が発生した際にケア提供者に提供されるかもしれない。EHS システム提供者からの紹介を受けて、それに基づき行動することを可能にする。EHR システムは紹介の予約の取得完了までを可能にするかもしれない。
1. The system SHALL provide the ability to manage outbound 431
referral(s), whether internal or external to the organization.
紹介先が組織内か組織外かによらず、紹介を管理できる機能を提供すること。
2. The system SHALL provide the ability to capture clinical 432
details necessary for the referral according to scope of practiceof the referral recipient.
紹介を受ける側に許可されている処置に基づいた紹介を行うために必要な、臨床上の詳細情報を取得できる機能を提供すること。
3. The system SHALL provide the ability to link (e.g., link to 433
image stored in PACS) clinical details as necessary for thereferral according to scope of practice of the referral recipient.
紹介を受ける側に許可されている処置に基づいた紹介を行うために必要に応じて、臨床上の詳細情報へのリンク (例：PACS 内の画像イメージへのリンク) ができる機能を提供すること。
4. The system SHALL provide the ability to render clinical details 434
as appropriate for the referral according to scope of practice ofthe referral recipient (e.g., clinical details required fordermatologist differ from those required by oncologist).
紹介を受ける側に許可されている処置に基づいた紹介を行うために必要に応じて、臨床上の詳細情報を提示できる機能を提供すること。
8. The system SHALL provide the ability to capture, store, and 438
render an inbound referral response (e.g., referral accepted,
referral denied, or more information needed).
紹介に対する応答 (例：紹介の受諾、紹介の拒否や、他に必要な情報)を取得し、保存し、提示できる機能を提供すること。
9. The system SHALL provide the ability to determine and render 439
recommended actions based on an inbound referral response(e.g., referral accepted, referral denied, or more informationneeded).
紹介を受け入れるためにケア提供者のスケジュールを取得できる場合、オーダが入った時点でのケア提供者のスケジュールに基づいて紹介可能なケア提供者を決定し提示する機能を提供す
ること。
CP.5
FunctionManage Results
結果の管理

443

Statement: Present, annotate, and route current and historical test results to appropriate
providers for review. Provide the ability to filter and compare results.
機能概要：適切な医療提供者への報告のために、最新および過去の検査結果を示し、注釈をつけて提供する。結果をフィルタ（選別）処理や比較できる機能を提供する。
Description: Results of tests are presented in an easily accessible manner to the appropriate
providers. For example, flow sheets, graphs, or other tools allow care providers to view or uncover
trends in test data over time. The provider may desire to annotate, filter, and/or compare results.
In addition to making results viewable, it is often necessary to send results to appropriate
providers using electronic messaging systems, pagers, or other mechanisms. In addition, thesystem may have the ability to redirect or copy specific test results to a specified individual.
Documentation of notification is accommodated. Results may also be routed to patients
electronically or nonelectronically (e.g., by hard copy). Note: “Results” are understood as applying
to any type of test, whether biological or psychological. Management of the results may also
require the provider's communication of the results to the patient (see function CPS.8.4 (Support
for Communications between Provider and the Patient, and/or the Patient's Representative)).
There may also be a need to notify public health agencies based on the result. See function POP.2(Support Population-based Epidemiological Investigation).
機能説明：検査結果は、適切な医療提供者に対して簡易な利用方法で提供される。例えば、フローシート、グラフや他のツールにより、医療提供者が時間の経過による検査データの傾向を見るか、見つ
け出すことができる。医療提供者は、注釈の付与、フィルタ（選別）処理、または結果の比較を求めても差し支えない。検査結果を視覚的に見せることに加えて、適切な医療提供者に対して電子メッセ
ージ、紙や他の仕組みを用いて（検査結果を）送ることが、たびたび必要となる。そのほかに、シス
テムは特定の個人に対して特殊な試験結果を転送やコピーの機能があっても差し支えない。通知文書が適応される。検査結果は、電子的／非電子的に患者に渡しても差し支えない。
（ハードコピーなど）
注：生物学的や心理学的であれ『結果』は、あらゆる試験の種類に適用している。検査結果の管理は、医療提供者による患者に対しての結果通知のために必要とすることが望まれる。（参照 CPS.8.4(Support for Communications between Provider and the Patient, and/or the Patient's
Representative)）同様に、結果に基づく公衆衛生機関に通知しなくてはならないことが望まれる。参照 POP.2 (Support Population-based Epidemiological Investigation)
1. The system SHALL provide the ability to manage test results 444
in according to scope of practice, organizational policy, and/or
jurisdictional law.
システムは、業務範囲、組織ポリシー、または管轄区域の法律に準拠して、検査結果を管理する機能を提供しなければならない。
2. The system SHALL provide the ability to render numerical 445
and non-numerical current and historical test results.
システムは、数値や数値以外の最新および過去の検査結果を提示する機能を提供しなければならない。
3. The system SHALL provide the ability to render results for 446
an identified patient or group of patients.
システムは、特定の患者や複数患者の結果を提示する機能を提供しなければならない。
4. The system SHALL provide the ability to render results by 447
factors that supports results management including type of
test, critical indicator and abnormal indicator.

システムは、検査の種類、危険指標や異常指標を含む目標管理を要素とする検査結果を提示する機能を提供しなければならない。
5.
6. The system SHALL provide the ability to tag and render 448
normal and abnormal indictors for results based on data
provided from the original data source.
システムは、提供元からのデータに基づく正常／異常の検査結果に対してタグをつけて提示する機能を提供しなければならない。
7. The system SHALL provide the ability to render results by 450
date/time range including ordered date/time, specimen
collection date/time and results received date/time.
システムは、依頼日時、検体採取日時、結果受信日時を含む日時の範囲による結果を提示する機能を提供しなければならない。
17. The system SHALL link results to the electronic order if the 459
system contains the electronic order.
システムに（電子カルテからの）依頼情報が含まれる場合は、検査結果と関連付けなければならない。
20. The system SHALL provide the ability to import and receive 462
preliminary and final result reports from ancillary systems
according to scope of practice, organizational policy, and/or
jurisdictional law.
システムは、業務範囲、組織ポリシー、または管轄区域の法律に準拠した部門システムからの中間／最終結果報告を受信して取り込む機能を提供しなければならない。
21. The system SHALL provide the ability to import or receive 463
preliminary and final results as discrete data from ancillarysystems, when discrete data is sent from the ancillary system,
according to scope of practice, organizational policy, and/or
jurisdictional law.
システムは、部門システムからの個別データが送られる場合、
業務範囲、組織ポリシー、または管轄区域の法律に準拠して、個別データとして中間／最終結果報告を受信するか取り込む機能を提供しなければならない。
22. The system SHALL provide the ability to capture, maintain 464
and render preliminary (e.g., "wet read") and final result
reports according to scope of practice, organizational policy,
and/or jurisdictional law.
システムは、業務範囲、組織ポリシー、または管轄区域の法律に準拠した中間（X 線の至急読影など）／最終結果報告の提示、取り込み、保存する機能を提供しなければならない。
23. The system SHALL provide the ability to tag and render a 465
notification to the appropriate health care team member(s)(using role-based or rule-based alerts) of clinically-significant
results or result changes.
システムは、（役割か規則に基づく警告を用いて）臨床的に重要な結果または結果の変化を適切な医療の専門家にタグをつけて提示する機能を提供しなければならない。
25. The system SHALL provide the ability to render non- 467
diagnostic quality images.
システムは、診断に影響のない画像を提示する機能を提供しなければならない。
27. The system SHALL provide the ability to link one or more 469
images to a result report.
システムは、１つ以上の画像を結果報告に関連付ける機能を提供しなければならない。
28. IF the system provides the ability to annotate a result, THEN 470
the system SHALL render the annotation with subsequentviews of that result.
結果に注釈をつける機能があれば、システムは、以降の結果における注釈も提示しなければならない。
30. The system SHALL determine that results were recieved fora patient who is no longer under the care of the ordering
provider and tag and render a notification according to scopeof practice, organizational policy, and/or jurisdictional law.
システムは、診察を行っていない患者についても、業務範囲、
組織ポリシー、または管轄区域の法律に準拠して、結果にタグをつけて通知を提示し、確定しなければならない。
CP.5.1
FunctionManageResults
Diagnostic Tests
診断検査結果の管理

472

474
of

Statement: Enable the receipt and display of results for diagnostics tests.
機能概要：診断検査のために結果の受信と表示を可能としなさい
Description: Diagnostic test results are received and should be stored and displayed while linked
to the original order in the system.
機能説明：システム内の依頼情報と関連づいている間、診断した検査結果は（有効であると）認められ、保存や表示されるべきである。
5. The system SHALL provide the ability to capture, maintain 479
and render discrete diagnostic results received through anelectronic interface.
システムは、インターフェースにより受信した別々の診断結果の提示、取り込み、保存する機能を提供しなければならない。
8. The system SHALL provide the ability to render indicators of 480
normal and abnormal diagnostic results based on information
provided from the original source (e.g., from a laboratory orradiology department).
システムは、情報元（検査科や放射線科など）より提供された情報に基づく正常や異常となる診断結果の指標を提示する機能を提供しなければならない。
CP.6
HeaderManageMedication,
Immunization
andTreatment
Administration
投薬管理、予防接種と治療
管理

481

Statement: Provide the functionality required to support the management of medication andimmunization administration.
要求事項：薬物治療、予防接種の投与をサポートする機能を提供すること。
Description: Provide the functionality required to support the safe administration of medications
or immunizations to a patient based on medical requirement and orders within the system. This
includes presenting providers with the list of medications or immunizations that are to beadministered to a patient, necessary administration information, and capture all required andrelevant administration details.
機能説明：医療の要求事項と指示に基づく薬物治療と予防接種の安全な投薬をシステム内で患者に提供する。これは患者に投与する投薬治療あるいは予防接種のリストを示すこと、必要な投薬情報、全ての必要で関連性のある処方詳細を医療関係者が保存することを含む。

CP.6.1
FunctionManageMedication
Administration
薬物投薬の管理482

Statement: Present providers with the list of medications that are to be administered to a patient,necessary administration information, and capture administration details.
要求事項：患者に投与する薬物のリストを示すこと、必要な投与情報、投与詳細を医療関係者が保存すること
Description: In a setting in which medication orders are to be administered by a provider rather
than the patient, the necessary information is presented including: the list of medication ordersthat are to be administered; administration instructions, times or other conditions ofadministration; dose and route, etc. The system shall securely relate medications to beadministered to the unique identity of the patient (see CPS.1.1). Additionally, the provider canrecord what actually was or was not administered, whether or not these facts conform to the order.
Appropriate time stamps for all medication related activity are generated.For some settings thatadminister complete sets of medications from a variety of providers' orders, it may be useful toprovide an additional check for possible drug-drug or other interactions.The EHR system shallsupport the five “rights” - Right Patient, Right Drug, Right Dose, Right Route, Right Time.The
system should report medication administration, where appropriate, to public health or disease
management authorities (e.g., oncology related medication orders should be communicated ortransmitted to a cancer registry).
機能説明：患者というよりもむしろ医療関係者によって薬物が投薬される環境において、必要な以下を含む情報が示される。投薬された処方オーダのリスト、投薬指導、回数または他の投薬状態、用量と経路、その他。システムは患者固有の ID に投薬された薬剤を安全に関連させなければならない(参照 CPS.1.1)。加えて、提供者はオーダに適合する投薬が実際にされたか、されなかったかを記録することができる。活動に関連する全ての薬剤の適切なタイムスタンプが生成される。さまざまな提供者のオーダの完全な薬剤セット投薬において、薬物相互作用の可能性の追加チェックを提供する。EHR
システムは 5 つの「正しい」をサポートしなければならない。患者が正しいこと、薬物が正しいこと、用量が正しいこと、経路が正しいこと、時間が正しいこと。システムは薬物投薬を公衆衛生局または疾病管理局など適切な場所に報告することが推奨される。(例、処方オーダに関するオンコロジーはがんレジストリすることが推奨される。)
1. The system SHALL provide the ability to render the list of 483
medications that are to be administered.
システムは投薬された処方歴を提示する機能を提供しなければならない。
2. The system SHALL provide the ability to render the list of 484
medications that are to be administered including all
administration directions/instructions (SIG).
システムは全ての投薬指導、教育(用法)の処方歴を提示する機能を提供しなければならない。
3. The system SHALL provide the ability to render the drug, 487
dose, route, time and frequency of desired administration for
all scheduled medications.
システムは薬剤、用量、ルート、時間、全ての予定された薬剤の望ましい投薬頻度を表示する機能を提供しなければならない。
4. The system SHALL conform to function CPS.4.2.1 (Support 490
for Medication Interaction and Allergy Checking) in order todetermine and render allergies, drug-drug interactions, andother potential adverse reactions, when rendering medication
administration information.
システムは薬物投薬管理情報を表示する時に、アレルギー、薬物
相互作用、その他の潜在的な反作用を決定、表示するために
CPS.4.2.1(投薬相互作用とアレルギーのサポート)の機能が適合することを提示しなければならない。
5. The system SHALL conform to function CPS.4.2.2 (Support 491
for Patient-Specific Dosing and Warnings) in order todetermine and render other potential adverse reactions, whenrendering medication administration information.
システムは薬物投薬管理情報を表示する時にその他の潜在的な反作用を決定、表示するために CPS.4.2.2(個体別の用量と警告のサポート)の提示する機能が適合しなければならない。
6. The system SHALL provide the ability to capture and 492
maintain the medication identification number of the drug
administered to the patient (e.g., NDC number, lot numbers,
expiration date).
システムは患者に投薬した薬物の識別番号(例 National Drug
Code、ロット番号、有効期限)の保存と維持する機能を提供することを必ず要求される。
7. The system SHALL provide the ability to capture, maintain 493
and render medication administration details as discrete
data, including:(1) the medication name, strength anddose;(2) date and time of administration;(3) route and site;(4)administering provider(5) observations, reactions andcomplications(6) reason medication not given, and/or
medication related activity not performed; according to scopeof practice, organizational policy, and/or jurisdictional law.
システムは法律的に許される行動、組織ポリシー、管轄区域で投薬された(1)投薬薬剤名、濃度、用量、(2)投与日時、(3)経路と場
所、(4)投与した医療関係者、(5)観察、反応、合併症、(6)投薬しなかった理由、およびまたは投薬の効力がなかった、個々の詳細データを保存、維持、表示する機能を提示しなければならない。
8. The system SHALL provide the ability to render the 504
medication administration history including administering
provider, date, and time.
システムは投薬した医療関係者、日時を含む投与履歴を提示する機能を提供しなければならない。
9. The system SHALL provide the ability to render the 508
medication order as written (i.e., exact clinician orderlanguage) when rendering administration information.
システムは投与情報を表示する時に(臨床家の指示した正確な専門用語で)書かれたとおりに投薬オーダを表示する機能を提供しなければならない。
10. The system SHALL provide the ability to capture and render 509
patient-specific instructions or other free text related to theadministration of the medication (e.g., use left-arm IV only)
システムは患者特有の指示や投薬に関するフリーコメントを表示、保存する機能を提供しなければならない。(例：左腕は静脈内注射のみ使用する)
11. The system SHALL provide the ability to manage information 510
regarding a second provider witness to co-document
administration.
システムは投薬の共同文書に同意する二次医療関係者提供に関しての情報を管理する機能を提供しなければならない。
12. The system SHALL provide the ability to capture, maintain 517
and render as part of the medication administration record
for infusions the actual date and times of the infusion
including the start and stop times and any modifications to
the infusion and the assessment status of the infusion.
システムは開始と終了時刻を含む点滴の実際の日時、変更点、評価状態を保存、維持、表示する投薬管理機能を提示しなければな
らない。
CP.6.2FunctionManage Immunization
Administration
予防接種管理523

Statement: Capture and maintain discrete data concerning immunizations given to a patient
including date administered, type, manufacturer, lot number, and any allergic or adverse
reactions. Facilitate the interaction with an immunization registry to allow maintenance of apatient’s immunization history.
要求事項：投与日、型、製造業者、ロット番号、アレルギー、副作用を含む患者に与えた予防接種に関しての個々のデータを保存、維持する。予防接種の相互作用をレジストリすることは患者の予防接種歴の維持を促進すること。
Description: During an encounter, recommendations based on accepted immunization schedules
are presented to the provider. Allergen and adverse reaction histories are checked prior to giving
the immunization. If an immunization is administered, discrete data elements associated with the
immunization including date, type, immunization expiration date, manufacturer and lot number
are recorded. Any new adverse or allergic reactions are noted. If required, a report is made to the
public health immunization registry or other organization (e.g., military unit commander, refugeeprogram leadership). This function should include the ability to use GTIN barcode scanners to
capture vaccine information (NDC, lot number, expiration date).
機能説明：外来診察の間、予防接種の予定を基にした提案は医療提供者に提示される。アレルギー源と副作用の履歴は予防接種前に確認される。予防接種を実施した場合、日付、型、有効期限、製造業
者、ロット番号を含む予防接種の関連データは記録される。いくつかの新しい副作用、アレルギー反
応はレジストリされる。必要であれば、公衆衛生予防接種登録や他の団体(例：軍部隊の指揮官、避難民)へ報告書が作成される。この機能は GTIN(Global Trade Item Number)バーコードスキャナを使用してワクチン情報(National Drug Code、ロット番号、有効期限)を保存する機能を含めるべきである。
1. The system SHALL provide the ability to capture 524
immunization administration details as discrete data,
including:(1) the immunization name/type, series, strengthand dose;(2) date and time of administration;(3)manufacturer, lot number, expiration date,(4) route and siteofadministration;(5)administering
provider;(6)observations, reactions and complications;(7) reason
immunization not given, and/or immunization related
activity not performed;according to scope of practice,organizational policy, and/or jurisdictional law.
システムは法律的に許される行動、組織ポリシー、管轄区域で(1)予防接種の名前、型、シリーズ、力価、用量、(2)投与の日時、(3)製造業者、ロット番号、有効期限、(4)経路と投与場所、(5)投与医療関係者、(6)観察、反応、合併症、(7)投与しなかった理由、
およびまたは効果が無かった予防接種を個々のデータとして予防接種の投与詳細を保存する機能を提供しなければならない。
2. The system SHALL provide the ability to determine and 526
render required immunizations, and when they are due,based on widely accepted immunization schedules, whenrendering encounter information.
システムは外来診察の情報を表示する時、広く一般的な予防接種の予定に基づいて、それらの期限が来たときに必要な予防接種を決定、表示する機能を提供しなければならない。
3. The system SHALL conform to function CP.3.2 (Manage 528
Patient Clinical Measurements) to capture other clinical data
pertinent to the immunization administration (e.g., vital
signs).
システムは予防接種投与に関する他の医療データ(例：バイタル
サイン)を保存する CP.3.2(患者の臨床指標の管理)の機能に適合しなければならない。
4. The system SHALL provide the ability to maintain a patient- 530
specific immunization schedule.
システムは患者固有の予防接種予定を維持する機能を提供しなければならない。
5. The system SHALL provide the ability to render a patient's 531
immunization history upon request for appropriate

authorities such as schools or day-care centers.
システムは学校や、デイケアセンターの様な適切な組織に要求により患者の予防接種の履歴を表示する機能を提供しなければならない.
6. The system SHALL conform to function CP.1.2 (Manage
Allergy, Intolerance and Adverse Reaction List).
システムは CP.1.2(アレルギー、不耐、副作用一覧の管理)の機能に適合しなければならない。
7. The system SHALL conform to function CP.1.6 (Manage
Immunization List).
システムは CP.1.6(予防接種一覧の管理)の機能に適合しなければならない。
8. The system SHALL provide the ability to render an
immunization order as written (e.g., exact clinician orderlanguage or as mandated - such as by a public healthrequirement), when rendering administration information.
システムは投与情報を提示するときに記載通りに(例：正確な臨床用語、公衆衛生の既定などで指定された)提示する機能を提供しなければならない。
9. The system SHALL provide the ability to determine due andoverdue ordered immunizations including earliest throughlatest date ranges and render a notification according toorganizational policy, and/or jurisdictional law.
システムは最近の期間を含む指示された予防接種の期限内と期限切れを決定し、組織や管轄区域のポリシー、及びまたは条例に従って通知を提示する機能を提供しなければならない。
10. The system SHALL provide the ability to render a patient
educational
11. information regarding the administration (e.g., Vaccine
Information Statement (VIS).
シ ス テ ム は 投 与 に 関 し て ( 例 ： Vaccine Information
Statements(VIS))の患者の教育情報を提示する機能を提供しなければならない。
12. The system SHALL provide the ability to capture that patient
educational information (e.g., VIS) was provided at the timeof immunization administration.
システムは予防接種時の患者の教育情報(例：VIS)を保存する機能を提供しなければならない。
CP.6.3FunctionManageTreatment
Administration
治療管理の管理

532

537

539

540

541

542

546

Statement: Provide the functionality required to support the management of treatment
administration and documentation. (Treatment defined as the administration or application ofremedies to a patient for a disease or injury; medicinal or surgical management; therapy.)
要求事項：治療と文書作成の管理をサポートするために必要な機能を提供する。治療は病気や怪我、医薬または外科的なの管理、治療法のために患者に投与や治療の適用と定義する。
Description: Provide the functionality required to support the documentation of non-medication
treatments (e.g., wound dressing change that includes use of a topical cream or sterile wash duringthat process) to a patient based on clinical needs and requirements and provider orders within thesystem. This includes presenting end users with the list of clinical treatments that are to beadministered to a patient, necessary administration information, and capture all required andrelevant documentation details.
機能説明：医療要求と必要性、システム内で医療関係者がオーダされたものを基に患者に無投薬治療(例：塗り薬や無菌洗浄を含む包帯交換)の書類提出をサポートするために必要な機能を提供する。これは末端利用者に投与する患者、必要な投与情報、全ての必要で適切な詳細文書を保存する一覧を示

すことを含む。
1. The system SHALL provide the ability to render the list of 547
treatments that are to be administered within a specified
time
frame
and
includingalladministration
directions/instructions.
システムは特定の時間枠内と全ての指示指導を含む処置の一覧を提示する機能を提供しなければならない。
2. The system SHALL conform to CP.6.1 (Medication 548
Administration) to support the administration of medications
as part of the treatment administration.
システムは薬剤治療の一環として投薬をサポートする CP.6.1(薬剤投薬)に適合しなければならない。
3. The system SHALL provide the ability to render the 551
information necessary to adminster the treatment (e.g., bodysite, time and frequency).
システムは投与に必要な情報(例：身体部位、時間、頻度)を提示する機能を提供しなければならない。
4. The system SHALL provide the ability to document multiple 552
body sites of desired administration for all scheduled
treatments.
システムは全ての予定された治療に対し望ましい管理を複数部
位を詳細に記録しなければならない。
5. The system SHALL provide the ability to capture, maintain 554
and render details associated with the treatment as discrete
data, including: treatment; date and time of treatment; site;
administering provider; observations, reactions andcomplications; and reason treatment not given, and/or related
activity not performed;according to scope of practice,organizational policy, and/or jurisdictional law.
システムは法律的に許される行動、組織ポリシー、管轄区域で治療、治療の日時、部位、投与医療関係者、観察・反応・合併症、投与しなかった理由、およびまたは効果が無い、を含む個別の治療に関する詳細を保存、維持、提示する機能を提供しなければならない。
6. The system SHALL provide the ability to capture, maintain 556
and render details associated with treatments (including
routinely scheduled, "one-time", "on-call" and "PRN") in amanner that distinguishes them from other types oftreatments according to scope of practice.
システムは(定期、1 回、オンコール、必要に応じてを含む)治療と法律的に許される行動に従った他の治療と区別する詳細を保存、維持、提示する機能を提供しなければならない。
7. The system SHALL provide the ability to capture verification 560
of patient identity prior to administration of the treatment.
システムは治療前に患者識別を検証する機能を提供しなければならない。
8. The system SHALL provide the ability to render the 564
treatment administration history including administering
provider date and time.
システムは投与された日時を含む投与医療関係者履歴を提示する機能を提供しなければならない。
9. The system SHALL provide the ability to render prior 565
treatment history (including treatment assessment data andpatient response) prior to the administration of thetreatment.
システムは投与前に以前の投与履歴(治療評価日、患者の反応を含む)を表示する機能を提供しなければならない。
10. The system SHALL provide the ability to render the 567
treatment order as written (i.e., exact clinician orderlanguage) when rendering treatment specific information

CP.7
HeaderManage Future Care
今後のケアを管理

including special instructions.
システムは特定の指導を含む特定の治療情報を表示するときに記載されたとおりに(すなわち正確な臨床用語で)治療を提示す
る機能を提供しなければならない。
11. The system SHALL provide the ability to capture and render 568
patient-specific instructions related to the treatment.
システムは治療に関する患者固有の指導を保存、提示する機能を提供しなければならない。
12. The system SHALL provide the ability to manage information
regarding a second provider witness to co-document
treatment. 569
システムは治療の共同記録を証言する二次医療関係提供者に関する情報を管理する機能を提供しなければならない。
13. IF the system provides the ability to manage treatment 573
schedules, THEN the system SHALL provide the ability torender a notification of a change in the treatment schedule.
システムは治療予定を管理する機能を提供する場合、システムは治療予定の変更通知を提示する機能を提供しなければならない。
14. The system SHALL conform to function CP.3.2 (Manage 577
Patient Clinical Measurements) to capture other clinical data
pertinent to the treatment (e.g., vital signs, blood glucose
reading).
システムは治療に関連する他の医療データ(例：バイタルサイン、
血糖値)を保存するために CP.3.2(患者の臨床指標の管理)の機能に適合しなければならない。
582

Statement: Provide the functionality to manage treatment and care planning throughpresentation of guidelines and protocols as well as managing recommendations for future care.
要求事項：将来の治療の提案の管理はもちろん、ガイドラインとプロトコルを通じて治療と治療計画を管理する機能を提供すること。
Description: The presentation of appropriate guidelines and protocols for future care and thecapture and management of recommendations for future care are required to ensure lifetime careof the patient. This includes the management of recommendations for post-encounter care andlinkage of recommendations to other components in the health record such as the problem lists
and other source documentation.
機能説明：将来の治療とそれの提案の保存と管理の適切なガイドラインとプロトコルは、患者の終身ケアを保証することが要求される。これは外来後の提案とその他のプロブレムリストとその他の文書のような健康診断書の構成要素の関連を含む。
CP.7.1
583
Function
Present Guidelines andProtocols for Planning
Care
計画的ケアのための現ガイドラインとプロトコル
Statement: Present organizational guidelines for patient care as appropriate to support planningof care, including order entry and clinical documentation.
要求事項：オーダエントリと診療文書作成を含む、治療計画を適切にサポートする患者の治療のための組織のガイドラインを提供する。
Description: Guidelines, and protocols presented for planning care may be site specific, community
or industry-wide standards.

機能説明：ガイドラインとプロトコルは特定の場所、団体、業界標準で治療の計画を提供する。
1. The system SHALL provide the ability to present current 584
guidelines and protocols to providers who are creating plans
for treatment and care.
システムは治療計画を作成している医療関係提供者に現在のガイドラインとプロトコルを表示する機能を提供しなければならない。
2. IF decision support prompts are used to support a specific 587
clinical guideline or protocol, THEN the system SHALL
conform to function CPS.3.8 (Manage Documentation ofClinician Response to Decision Support Prompts).
もし意志決定支援システムが特定の医療ガイドラインやプロト
コルを使用する場合、システムは CPS.3.8(意志決定支援システ
ムの臨床家の反応の文書作成管理)の機能に適合しなければならない。
3. IF the system supports context sensitive care plans, 588
guidelines and protocols, THEN the system SHALL conformto function CPS.3.4 (Support for Context-Sensitive Care
Plans, Guidelines, Protocols).
もしシステムが状況に応じた治療計画、ガイドライン、プロトコ
ルをサポートする場合、システムは CPS.3.4 の機能(状況に応じた治療計画、ガイドライン、プロトコルのサポート)に適合しなければならない。
CP.7.2589
FunctionManageRecommendationsfor
Future Care
今後のケアのための推奨事項の管理Statement: Document and support the management of the disposition process for a patient bymanaging recommendations for future care.
要求事項：将来の治療の提案管理で患者への処置手順の管理の文書作成とサポート。
Description: Patient encounters or treatments can end in many different states and support forthese requires that the EHR support the ability to capture and maintain recommendations for thefurther future care of the patient. The EHR should accommodate, at a minimum, the following
possible recommendations for future care (or dispositions) along with other supporting
information for the recommendations:
機能説明：外来や治療は多くの異なる状態に至ることが出来、それらの必要な将来の治療の提案を保存、維持する機能を提供する EHR システムをサポート出来る。EHR システムはその他のサポートする推奨情報（退院、入院、移動、死亡、診療前に帰宅、処置前に帰宅、逃亡(施設に告知なしに外出や徘徊)、診察に反抗して帰宅、患者が他の診療所を選別、行政上の過誤）に加えて将来の治療（や処置）の可能な提案について最小限順応することが推奨される。
- discharge, 退院- admission, 入院- transfer, 転院（移動- death, 死亡- left without being seen (LWBS), 診療前に帰宅- left without treatment (LWOT), 治療前に帰宅- elopements (i.e. leaving without notifying the facility or wandering), 逃亡（施設に告知なしに外出や徘徊）- left against medical advice (AMA), 診察に反抗して帰宅- patients triaged to other clinics, and 患者が他の診療所を選別- administrative errors. 行政上の過誤
1. The system SHALL provide the ability to capture 590
recommendations for future care as discrete data elements
including the recommending provider and an alert date for

2.

3.

4.

the recommendation to take effect.
システムは医療関係者、効果がある提案の警戒日を含む個々のデータとして将来の治療提案を保存する機能を提供しなければならない。
The system SHALL provide the ability to maintainrecommendations and associated recommendation metadata (e.g., date of alert).
システムは提案とメタ情報(例えば警戒日)を維持する機能を提供しなければならない。
The system SHALL provide the ability to render an alert of
the recommendation based on the date associated with therecommendation (e.g., if recommendation is to "bookappointment for physical therapy in 2 weeks" - alert will be
triggered in 1.5 weeks for follow-up).
システムは提案に関する日付を基に提案の警告を提示する機能を提供しなければならない。
（例：もし 2 週間後に理学療法の予約という提案の場合、1.5 週間後にアラートを示す）
The system SHALL provide the ability to capture
recommendations for future care or post-encounter
disposition from encounter and diagnostic studies imported
in structured documents.
システムは将来の治療や外来後の治療と構造化文書に流入した診断上の研究提案を保存する機能を提供しなければならな
い。

CP.8
HeaderManagePatient
Education&
Communication
患者教育およびコミュニ
ケーション管理

591

592

593

597

Statement: Provide the functionality to effectively communicate with the patient regarding theircare and document the communication as part of the patient's medical record.
要求事項： 効果的に患者と治療に関するコミュニケーションを行いその内容を患者の医療記録として文書化する機能を提供する。
Description: During an encounter with a patient or when any medical decision is made that affects
the patient and requires action from the patient it is necessary to communicate effectively withthe patient (or their representative) to ensure that they can participate appropriately in their care.
This includes providing instructions pertaining to preparation for a procedure, self-administrationof medications and self care.
機能説明： 患者の診察中あるいは患者に影響を及ぼす診断を下す際、そして患者の対応が必要な際に患者（あるいはその代理人）と効果的にコミュニケーションを行うことは、患者が治療を適切に受けることができることを保証するために必要である。これには処置、薬剤の自己投与、セルフケアの準備に関する指示も含まれる。
CP.8.1
598
Function
Generate, Record andDistribute
PatientSpecific Instructions
患者個別指示の作成、記録および指示出しStatement: Generate and record patient-specific instructions related to pre- and post-proceduraland post-treatment/discharge requirements.
要求事項： 患者個別の事前、事後手順と治療後/退院要件に関する指示の作成と記録

Description: When a patient is scheduled for a test, procedure, or discharge, specific instructions
about diet, clothing, transportation assistance, convalescence, follow-up with physician, etc., may
be generated and recorded, including the timing relative to the scheduled event. In an outpatient
scenario, similar instructions for post-diagnosis, and/or post-treatment needs may also be
generated and recorded (e.g., exercise instructions for low back pain, wound or burn care).
機能説明：患者の検査、処置、退院が予定される場合またこれらのイベントに関連するタイミングで、
食事、衣服、移動補助、療養、医師によるフォローアップ等の特別な指示が作成され記録される。外来患者に関しては、診断後および/または治療後に必要となる同様な指示が作成され記録される（例えば、腰痛、けが、火傷治療のためのエキササイズ指示等）。
1. The system SHALL provide the ability to determine and render 599
standardized instruction sets pertinent to the patient
condition, for procedures, or scheduled events.
システムは処置や予定されたイベントに対して患者の状態に適した標準化された指示セットを決定し提示する機能を提供できなければならない。
2. The system SHALL provide the ability to render instructions 600
pertinent to the patient as selected by the provider.
システムは指示者により選択された患者に適した指示を提示す
る機能を提供できなければならない。
4. The system SHALL provide the ability to render as part of 602
patient instructions details on further care such as follow up,
return visits and appropriate timing of further care.
システムは患者への指示の一部として、フォローアップ、再来あ
るいは今後のケアの適切な時期のような今後のケアに関する詳細を提示できる機能を提供できなければならない。
5. The system SHALL provide the ability to capture an indication 603
that instructions were given to the patient.
システムは患者に指示がされたことを示す内容を取り込むことができる機能を提供できなければならない。
6. The system SHALL provide the ability to capture the actual 604
instructions given to the patient or a reference to the
document(s) containing those instructions.
システムは患者に与えられた実際の指示あるいはその指示を含
むドキュメントへの参照情報を取り込みことできる機能を提供できなければならない。
CP.9
HeaderManageCare
Coordination&
Reporting
ケアの整備とレポート

613

Statement: Provide the functionality required to coordinate care with other providers and reportcare provided.
機能概要：他の医療提供者による診断と提示された診断報告の整備に必要となる機能を提供する。
Description: During care provision it is necessary to coordinate care with other providers, internalor external to the organization, as well as to communicate the care provided.
機能説明：診療中は、診断を伝えるのと同じくらい他の医療提供者、部門内／外の診断を整備する必要がある。
CP.9.1
614
Function
Produce a Summary
Record of Care
ケアのサマリ記録の作成

Statement: Render a summarized review of a patient's episodic, and/or comprehensive EHR,
subject to jurisdictional laws and organizational policies related to privacy and confidentiality.
機能概要：プライバシーや守秘義務に関連した組織ポリシーや管轄区域の法律を前提に、患者の症状報告や様々な電子診療録の要約を提示する。
Description: Create summary views and reports at the conclusion of an episode of care. Create
service reports at the completion of an episode of care such as, but not limited to, discharge
summaries, specialist or consultation reports and public health reports, using information
captured in the EHR and without additional input from clinicians.
機能説明：治療を終える際に、サマリと報告書を作成する。例えば、退院サマリ、専門医または診察医の報告書や公衆衛生報告書などがあるが、これらに限らず臨床家による付加情報の入力が無くても電子診療録に保存された情報を用いて治療を終える際に業務としての報告書を作成する。
1. The system SHALL provide the ability to render summaries 615
of the patient's comprehensive EHR that include at aminimum: problem list, medication list, allergy and adverse
reaction list, and procedures.
問題点リスト、投薬リスト(薬歴)、アレルギーや副作用、また術式などを最低限含めた患者の様々な電子診療録サマリを提示する機能を提供しなければならない。
CP.9.2616
Function
Capture Heath Service
Report Information
ヘルスサービスレポート
情報の取り込み
Statement: Support the creation of health service reports to authorized health entities that aprovider may be required to generate (e.g., the creation of an oncologist's report that must be
submitted to a national cancer registry).
機能概要：認可された医療団体への医療提供者からの提示が必須となり得る診療業務に関する報告書の作成を支援する。 （全国がん登録に提出しなければならないがん専門医の報告書の作成など）
Description: Providers are prompted to collect sufficient information in the course of care to avoid
duplicate, retrospective or other additional data entry as part of supporting health management
programs and reporting, for example public health, such as notifiable condition reports,
immunization, cancer registry and discharge data.
機能説明：例えば公衆衛生（届出が必要な症状報告、予防接種、がん登録や退院データ）などの健康管理計画の支援や報告の一環として、既存または新たな付加情報のあらためての入力を避けるために、医療提供者は診療中に充分な情報を収集することを促される
5. The system SHALL conform to function CP.9.1 (Produce a 621
Summary Record of Care).
システムは、CP.9.1 (Produce a Summary Record of Care)に従わなければならない。

3. Care Provision Support Section
Section/id#：
Type:
Name:
CPS.1
HeaderRecord Management
記録の管理

Conformance Criteria

Row#
623

Statement: Manage the patient record including all patient demographics, identifiers and otherinformation to support the provision of care.
機能概要：患者の基本情報、識別子、その他ケア提供の支援に必要な情報のすべてを含む患者記録を管理する。
Description: Management of the patient record includes creation through quick registration or
through a captured referral request as well as managing the patient encounter information linked
to the appropriate patient record. It is also critical to manage the patient's relationships throughgenealogy, insurance, living situation or other means. This section also includes support for the
management of patient and family preferences including patient advance directives, consents andauthorizations linked to the unique patient record. For those functions related to data capture,
data should be captured using standardized code sets or nomenclature, depending on the natureof the data, or captured as unstructured data. Care-setting dependent data are entered by avariety of caregivers. Data may also be captured from devices or other tele-health applications.
機能説明：患者記録の管理には、患者の受療に関する情報の管理と同様、迅速な登録あるいは紹介要
求を通じての記録の作成を含む。患者の家系、保険、生活状態、その他を通じた患者の関係を管理することも極めて重要である。本セクションは、患者記録に紐づけられた患者の事前指示、同意と認定をはじめ患者と家族の意向の管理の支援を含む。データの取得に関する機能については、データはその性質に応じて標準化されたコードセットやノメンカルチャーを用いて取得するか、または非構造化されたデータとして取得される。医療機関依存のデータは様々な医療提供者により入力される。デー
タは装置や、他のテレヘルス・アプリケーションから取得される。
CPS.1.1
624
FunctionManagea
Patient
Record患者記録の管理Statement: Manage a single logical record for each patient.
機能概要：個々の患者について、単一の論理的な記録を管理する。
Description: A single record is needed for legal purposes, as well as to organize it unambiguously
for the provider. Health information is captured and linked to the patient record. Static data
elements as well as data elements that will change over time are maintained. The patient is
uniquely identified, after which the record is tied to that patient. Combining information on thesame patient, or separating information where it was inadvertently captured for the wrong
patient, helps maintain health information for a single patient. In the process of creating a patient
record, it is at times advantageous to replicate identical information across multiple records, sothat such data does not have to be re-entered. For example, when a parent registers children as
new patients, the address, guarantor, and insurance data may be propagated in the children’s
records without having to re-enter them.
機能説明：法的に、また提供者が曖昧さなく管理するため、単一の医療記録が必要とされる。患者が特定されると、その患者と記録が紐づけされる。同一患者の情報を組み合わせること、あるいは誤って結びつられた情報を分離することは、一人の患者の情報の維持に有用である。患者記録の作成過程
で、再入力をせずに、同じ情報を複数記録に複製することが有用な場合がある。例えば、親が子供をSection/id#：
Type:
Conformance Criteria
Row#
Name:
新規の患者として登録する場合、住所や保証人、保険テータなどは再入力することなく、子供の記録に写すことができる。
1. The system SHALL manage a single logical record for each 625
patient.
1. システムは、一人ひとりの患者に対し、単一の論理的記録を管理しなければならない。
2. The system SHALL provide the ability to determine the unique 626
identity of a patient and link the record to a single patient.
2. システムは、患者をユニークに識別でき、その患者の記録を、患者に結び付ける機能を提供しなければならない。
3. The system SHALL provide the ability to manage a record for 627
a patient when the identity of the patient is unknown.
3. システムは、一人の患者の識別が不明な場合に、その患者に対し、一つの記録を管理する機能を提供しなければならない。
5. The system SHALL provide the ability to manage more than 629
one patient identifier for each patient record.
5. システムは、個々の患者記録に対し、一つ以上の患者の識別子を管理する機能を提供しなければならない。
6. The system SHALL link key patient identifier information 630(e.g., system ID, medical record number) to each patient
record according to scope of practice, organizational policy,
and/or jurisdictional law.
6. システムは、患者のキーとなる識別子情報(システム ID、診療録
番号、等)を、個々の患者記録に紐づけできなければならない。
8. The system SHALL provide the ability, through a controlled 632
method, to integrate or link information for an individual
patient upon recognizing the identity of the patient (e.g., if
portions of a record were not yet integrated or linked because
the patient's identity was not yet known, or a temporary
identity (an alias) was being used, or there were duplicate
records)
8. システムは、患者の識別を確認できたとき、統制された方法により、情報を統合化し、紐づけする機能を提供しなければならない。例えば、記録の一部が統合化または結合されていないとき、まだ患者の識別が不明なとき、あるいは一時的な識別子(エリアス)が使用された場合、あるいは重複した記録がある場合など。
9. The system SHALL provide the ability, when health 633
information has been mistakenly associated with a patient, to
tag the information as erroneous in the record of the patientin which it was mistakenly associated and render that
information as erroneous in all renderings (i.e., outputs)
containing that information.
9. システムは、医療情報が誤って患者に結び付けられたとき、その情報が誤りであるというタグを付け、その情報を含む、すべの表示において、その部分が誤りであることを表示する機能を提供しなければならない。
10. The system SHALL provide the ability, when health 634
information has been mistakenly associated with a patient, tolink the health information with the correct patient and tag
as erroneous in the wrong patient record.
10. システムは、医療情報が間違って患者と結び付けられた場合、その情報を正しい患者と紐付けし、間違っていた患者にはエラーであることを表すタグを付す機能を提供しなければならない。
11. The system SHALL render appropriate health information 635
that has been tagged as erroneous in a patient's record (e.g.,
identify as erroneous when rendering or render in audit logs

Section/id#：
Type:
Name:

CPS.1.2
FunctionManagePatient
Demographics
患者基本情報の管理

Conformance Criteria

Row#only).
11. システムは、患者記録において、エラーとしてタグ付けされた情報を表示する機能を提供しなければならない。(例えば、表示の際にエラーであることを識別するか、あるいは監査記録にのみ表示する。)
12. The system SHALL provide the ability to render parts of a 636
single patient's record using a primary identifier (e.g., Uniquepatient identifier, encounter number), secondary identifiers(e.g., Social Security Number), or other information, or
combination of information, which are not identifiers, but
could be used to help identify the patient (e.g., name or Dateof Birth).
12. システムは、一人の患者記録の一部分を、主識別子(例えば、ユニークな患者識別子、受診番号)、および二次識別子(例えば社会保障番号)か、他の情報、あるいは識別子ではないが患者識別に有用な情報の組み合わせ(例えば、氏名と生年月日)を用いて表示する機能を提供しなければならない。
13. The system SHALL provide the ability to tag as obsolete, 637
inactivated or nullified, to store in archives and to remove apatient's record in accordance with local policies andprocedures, as well as applicable laws and regulation.
13. システムは、組織の方針、手続き、該当する法規制に準じて、患者の記録をアーカイブに格納するとき、あるいは記録を削除するとき、古くなった、イナクティベイトされた、あるいは無効化された、というタグ付けをする機能を提供しなければならない。
17. The system SHALL provide the ability to render patient 641
records based on previous names.
17. システムは、患者の記録を、以前の氏名に基づいて表示する機能を提供しなければならない。
643

Statement: Manage patient demographic information.
機能概要：患者の属性情報を管理する。
Description: Demographic information (including names, addresses, phone numbers, email
addresses, date of birth, gender, race, and ethnicity) must be managed to support unique patient
identification, reporting, care provision requirements. Patient Demographic information may also
include information about the patient's contacts, methods of contact (e.g., email or telephone), andmodes of contact (e.g., call secretary during the day, send text message on the weekend). Patient
demographic data are captured and maintained as discrete fields and may be enumerated,numeric, or codified according to scope of practice, organizational policy, and/or jurisdictional law.
Key patient identifiers (i.e., name and primary patient record identifier) often appear on patient
information output (e.g., rendering of a patient's record). Patients may have multiple, and/or
compound names, sometimes employing accent marks or special characters. To help parse patient
names, discete fields are often used.
機能説明：属性情報(氏名、住所、電話番号、メールアドレス、生年月日、性別、人種、民族)は、患者のユニークな識別、報告、ケア提供のための要件として管理される必要がある。患者の属性情報は、親の連絡先、連絡手段(email、電話)、コンタクトのモード(日中は秘書に電話する、週末はテキストを送るなど)を含む場合もある。患者の属性データは、離散的なフィールドに取得され、提供するケアや、組織の方針、法規等により列挙された、あるいは数値やコード化された情報の場合もある。キーとなる患者識別子(氏名、主たる親の記録識別子など)は、患者情報出力に表示されることがある。患Section/id#：
Type:
Conformance Criteria
Row#
Name:
者は複数の、あるいは複合的な氏名を持ち得る。またアクセント記号や特殊文字を用いる場合もある。
患者氏名をパースするため、複数フィールドが用いられることがある。
1. The system SHALL provide the ability to capture demographic 644
information as discrete data as part of the patient record.
1. システムは、患者の属性情報を、患者記録の一部である離散的データとして把握する機能を提供しなければならない。
2. The system SHALL provide the ability to maintain 645
demographic information as discrete data as part of thepatient record.
2. システムは、属性情報を、患者記録の一部である離散的なデータとして維持する機能を提供しなければならない。
3. The system SHALL provide the ability to render demographic 646
information as discrete data as part of the patient record.
3. システムは、属性情報を、患者記録の一部である離散的なデータとして表示する機能を提供しなければならない。
4. The system SHALL provide the ability to manage historic 647
information for demographic data including prior names,
addresses, phone numbers and email addresses.
4. システムは、属性情報の履歴、例えば、以前の氏名、住所、電話番号、email アドレスなどを管理する機能を提供しなければならない。
5. The system SHALL render a set of patient identifying 648
information at each interaction with the patient record,
according to scope of practice, organizational policy, and/or
jurisdictional law (e.g., a certain realm may require that thepatient's picture appear on every screen that is used during aprovider's face-to-face interactions with the patient).
5. システムは、業務範囲、組織のポリシー、管轄区域の法律に準じて、患者の一組の識別情報を、患者記録とのインタラクションごとに表示する機能を提供しなければならない。(例えば、国によっては、医療提供者が患者と対面で接する都度、患者の写真が画面に表示されることを要求される場合もある。)
7. The system SHALL provide the ability to capture valid 650
date/time values in discrete fields (e.g., 2011/12/31 2330),
including valid incomplete or partial date/time values (e.g.,
2011/12).
7. システムは、日付/時間の有効な値(例えば、2011/12/31 2330)を、
不完全であるが有効な値や部分的な日付/時間の値(例えば、2011/12)を含めて離散的フィールドに取得する機能を提供しなければならない。
9. The system SHALL provide the ability to capture the patient's 652
gender used for administrative purposes (as distinct from theclinical gender).
9. システムは、管理目的で利用される患者の性別(臨床的性別とは異なる)を取得する機能を提供しなければならない。
13. The system SHALL provide the ability to manage the 656
date/time of birth, down to the minute, according to scope ofpractice, organizational policy, and/or jurisdictional law.
13. システムは、業務範囲、組織のポリシー、管轄区域の法律に準じて、生まれた日付/時間を分の単位まで管理する機能を提供しなければならない。
18. The system SHALL provide the ability to manage multiple 661
patient names in each name component field (e.g., first,
middle, last, suffix, or title).
18. システムは、患者の複数の名前を、個々の名前のフィールド(例えば、名、ミドルネーム、姓、名前の後ろに付ける称号、肩書き)
ごとに管理する機能を提供しなければならない。

Section/id#：
Type:
Name:

CPS.1.3
Function
CaptureRegistration
迅速登録の把握

Conformance CriteriaRow#

19. The system SHALL provide the ability to manage patient 662
names that include any accent marks or special characters.
19. システムは、患者の名前を、アクセント記号や特殊文字も含め、管理する機能を提供しなければならない。
664
Quick

Statement: Capture a registration, either directly entered or received from an external system,without complete supporting demographics, in order to facilitate patient care before the fullregistration is complete.
機能概要：迅速な患者ケアを優先するため、完全な登録が完了する前に、直接入力された、あるいは
外部システムからの受信による登録を把握する。
Description: The registration process, including the verification of full demographics data,
insurance, contact information, etc. is frequently time consuming. To facilitate patient care in
emergency situations, the system must be able to register a patient with minimal information ina time critical manner. Examples of situations when this might be necessary include when apatient presents with acute myocardial infarction, a disaster response, or a mass casualty event.
After care is given during an emergent situation, records are often incomplete or invalid. Such
records may need to be completed and validated. Afterwards, those records may need to beharmonized. For example, the records of "John Doe1; approximate age is 30" may need to bematched with existing records for "Henry Smith; age 28".
機能説明：すべての属性データ、保険情報、連絡先等の検証を含めた登録プロセスは、時間を要することが多い。救急の場合に、患者ケアを迅速に行うため、システムは最小限の情報で登録できる機能を持たなければならない。例えば、心筋梗塞を発症した場合、災害時対応、多数の傷病者事故の場合などである。救急時のケアが提供された後は、記録は不完全で不適切である。このような記録は完成させ検証する必要がある。また、後にこれらの記録を調整する必要がある。例えば「John Doe1、年
齢およそ 30 才」の記録は、既に登録されている「Henry Smith、年齢 28 才」の記録にマッチさせる必要が生じることがある。
1. The system SHALL provide the ability to capture patient 665
registration information to accommodate an expedited
registration situation (e.g., during a disaster or during a
census overload at a facility).
1. システムは、迅速登録の状況に対応するため、患者の登録情報を把握する機能を提供しなければならない。(例えば、災害時や、施設における患者数が超過しているとき。)
3. The system SHALL provide the ability to harmonize 667
information generated during an expedited registration
process with the EHR.
3. システムは、EHR の迅速登録プロセスの間に生成された情報を調整する機能を提供しなければならない。
CPS.1.4
668
Function
CaptureReferralRequest
紹介要求の把握Statement: Enable the receipt and processing of referrals from care providers or healthcareorganizations, including clinical and administrative details of the referral, and consents andauthorizations for disclosures as required.
機能概要：医療提供者あるいは医療施設から、臨床的、管理的な紹介の詳細、および必要に応じて同意および開示の権限を含めて、紹介状を受け取り処理することを可能にする。

Section/id#：
Type:
Name:

Conformance Criteria

Row#

Description: Incoming referrals may be from physicians' offices, specialists, clinics, Emergency
Medical Services (EMS), transfers from other hospitals or emergency departments, nursing
homes, etc. Referrals may be received electronically (i.e. e-Referrals); or may be received nonelectronically. If non-electronic, the system needs to allow the user to capture the referral
information and manage referral request. If the system supports e-Referrals, then the system will
also need to support additional functionality to manage the receipt of the referral request. Whena system receives a referral request the request must be validated against established criteria todetermine if it meets the recipient’s requirements and is appropriate. Referrals may be received
for patients who do not previously exist in the recipient system and the system must allow for theability to triage the request and respond to the requestor. If appropriate the system should allow
for the creation of a patient record including the capture of clinical and administrative information
received with the referral request. The management of information on patients who are inboundto the care setting is an important component of information management. Data must be easily
accessible, centrally retrievable, updatable, transportable and reusable. Clinical data fromprovider to provider is essential to quality-coordinated care for patients referred to the caresetting. Knowledge of patients who are expected to arrive helps both care setting andadministrative staff plan resource use in real time.
機能説明：患者紹介は、医師のオフィスから、専門医から、診療所から、あるいは救急医療サービス
からの場合や、あるいは他の病院、救急部門、介護施設等からの転送の場合もある。紹介は、電子的に、または非電子的手段で受理される。電子的でない場合、システムは利用者に対し、紹介情報を把握し、紹介の要求を管理することができるようにする必要がある。システムが、電子紹介状を支援する場合は、受領した紹介状の管理に関して追加的支援を必要とする。システムが、紹介要求を受け取ったとき、紹介状は事前に設定されている基準に照らして、要求事項を満たしているか、バリデートする必要がある。紹介状は、それ以前に、当該システムに登録されていない患者に関するものである
場合、システムは要求をトリアージし、要求者に対して回答する必要がある。適切な場合、システム
は紹介状の要求に基づいて、臨床上、管理上の情報を含む患者の記録を作成する。ケア施設に入所した患者情報の管理は、情報管理において重要な要素である。データは容易にアクセスでき、中央で取り出しでき、更新可能であり、転送、再利用も可能でなければならない。医療提供者から医療提供者
への臨床データは、ケア施設に紹介された患者のための、質的コーディネートされたケアのために必須である。到着が予定されている患者についての知識は、ケア施設にとって、また管理スタッフが、実時間で資源の利用を計画する上で、有用である。
1. The system SHALL provide the ability to capture referral(s) in 669
some form (e.g., paper, fax, electronic) from other careprovider(s), whether internal or external to the organization.
1. システムは、何等かの形式(紙、Fax、電子的、等)で、組織内あるいは外部組織の、他の医療提供者からの紹介状を取得する機能を提供しなければならならない。
2. The system SHALL capture and render the Source of Referral 670
and the Reason for Referral.
2. システムは紹介状のソースと、紹介の理由を把握し、表示する機能を提供しなければならない。
4. The system SHALL conform to function CPS.2.1 (Support 672
externally-sourced Clinical Documents) to support the captureof referral documents.
4. システムは、紹介文書の取得を支援するため、機能 CPS.2.1 (外部から提供された臨床ドキュメントの支援)に準じなければならない。
5. The system SHALL conform to function CPS.2.2 (Support 673
externally-sourced Clinical Data) to support the capture ofreferral data.
5. システムは、紹介データの取得を支援するため、機能 CPS.2.2 (外部から提供された臨床ドキュメントの支援)に準じなければならない。
7. The system SHALL conform to function CPS.2.4 (Support 675
externally-sourced Clinical Images) to support the capture ofreferral images.

Section/id#：
Type:
Name:

Conformance CriteriaRow#

7. システムは、紹介画像の取得を支援するため、機能 CPS.2.4 (外部から提供された臨床画像)に準じなければならない。
8. The system SHALL provide the ability to analyze and present 676
recommendations for potential matches between the patient
identified in a received referral and existing patients in thesystem.
8. システムは、受領した紹介状の患者とシステムに記録されている患者の潜在的なマッチについて、分析し、忠告する機能を提供しなければならない。
9. IF the system provides the ability to electronically capture 677
referrals, THEN the system SHALL provide the ability toreceive an e-referral for a patient that did not previously exist
in the system.
9. システムは、電子的に紹介状を取得する機能を提供できるなら
ば、これまでにシステムには記録されていない患者の電子的紹介状を受信する機能を提供しなければならない。
10. IF the system provides the ability to electronically capture 678
referrals, THEN the system SHALL provide the ability todefine a minimum set of required information that must be
included in an e-referral to be accepted, according to scope ofpractice, and/or organizational policy.
10. システムは、電子的に紹介状を取得する機能を提供できるなら
ば、業務範囲及び組織ポリシーに準じて、受入可能な電子紹介状に含むべき要求されるミニマムセットの情報を定義する機能を提供しなければならない。
13. IF the system provides the ability to electronically capture 681
referrals, THEN the system SHALL provide the ability topresent received e-referrals to a user for triage and approval.
13. システムは、電子的に紹介状を取得する機能を提供できるなら
ば、受信した電子紹介状をトリアージュおよび承認のためユー
ザに提示する機能を提供しなければならない。
17. IF the system provides the ability to electronically capture 685
referrals, THEN the system SHALL provide the ability for auser to create a patient record from information received in
the referral.
17. システムは、電子的に紹介状を取得する機能を提供できるなら
ば、ユーザが、受領した紹介状の情報から患者記録を作成する機能を提供しなければならない。
18. IF the system provides the ability to electronically capture 686
referrals, THEN the system SHALL provide the ability for auser to reject a e-referral request
18. システムは、電子的に紹介状を取得する機能を提供できるなら
ば、ユーザが、電子的紹介状の要求を拒否する機能を提供しなけ
ればならない。
19. IF the system provides the ability to electronically capture 687
referrals, THEN the system SHALL provide the ability tocapture the reason for an e-referral acceptance or rejection.
19. システムは、電子的に紹介状を取得する機能を提供できるなら
ば、電子紹介状の受入れもしくは拒否の理由を把握する機能を提供しなければならない。
20. IF the system provides the ability to electronically capture 688
referrals, THEN the system SHALL provide the ability totransmit to the referring provider the acceptance or rejectionof the e-referral request including the reasons provided for
acceptance/rejection.
20. システムは、電子的に紹介状を取得する機能を提供できるなら
ば、紹介元の医療提供者に、電子紹介要求の受入れ又は拒否を、

Section/id#：
Type:
Name:

Conformance Criteria
その理由と共に伝達する機能を提供しなければならない。
22. IF the referral includes a transfer of care (complete or partial
or temporary), THEN the system SHALL provide the ability
to capture the documentation of the transfer of care according
to scope of practice, organizational policy, and/or jurisdictionallaw.
22. 紹介状に(完全な、又は一部の、又は一時的な)診療の依頼が含まれるならば、システムは業務範囲、組織ポリシー、管轄区域の法律に準じて、診療の依頼に関する文書を取得する機能を提供しなければならない。

CPS.1.5
FunctionManagePatient
Encounter
患者の受療(受診)管理

Row#

690

694

Statement: Manage patient encounter information, including tele-health encounters, and support
follow-up encounters.
機能概要：遠隔医療も含め、患者の受療(受診)情報を管理し、その後のフォローアップの受療を支援する。
Description: Each encounter of the patient with the healthcare setting needs to be recorded andthe information relevant to the distinct encounter managed. This information includes date andtime of the encounter, providers involved, location(s), and the reason for the encounter etc.
Additionally, follow-up encounters may require prior administrative and clinical information to be
determined or captured, maintained and rendered. Tele-health encounters have uniquerequirements that may also be supported by the system.
機能説明：医療提供者、提供施設による個々の患者の受療を記録し、異なる受療に関する情報を管理する。この情報には、受療の日付、時間、関与した医療提供者、場所、受療の理由などが含まれる。
さらにフォローアップの受療のため、以前の管理情報、臨床情報を、決定、取得、維持、あるいは表示することが必要な場合がある。遠隔医療における受療は、特殊な要求事項があり、システムによる支援が必要とされる場合がある。
1. The system SHALL provide the ability to manage information 695
regarding a patient encounter, including a minimum of thefollowing data: the date/time, providers, location, and reason
for the encounter.
1. システムは、患者の受療に関する情報を管理する機能を提供しなければならない。情報としては、最低限以下を含む: 受療の日付/時間、関与した医療提供者、場所、受療の理由。
7. The system SHALL provide the ability to capture one or more 701
complaints, presenting problems, or other reasons for the visit
or encounter (e.g., chest pain, gunshot wound, and drug
overdose during a single encounter).
7. システムは、一つあるいは複数の主訴、提示されたプロブレム、あるいはその他の、来院や受療の理由を把握する機能を提供しなければならない。(例えば、一回の受療で確認された、胸痛、銃創、薬の過剰摂取)
8. The system SHALL provide the ability to capture the primary 702
reason (e.g., the Chief Complaint or the most importantreason) for visit/encounter from the patient's perspective.
8. システムは、患者からみた、来院/受療の主たる理由を取得する機能を提供しなければならない(他例えば、主訴、あるいは最も重要な理由) 。
CPS.1.6
704
HeaderSubjecttoSubject

Section/id#：
Type:
Name:
Relationship
患者とその関係者

Conformance Criteria

Row#

Statement: Information about the relationships between patients and others facilitate healthcaredelivery and appropriate access to health information.
機能概要：患者と、他の人々の関係に関する情報は、医療提供および医療情報への適切なアクセスを促進する。
Description: Information regarding relationships between patients and others serve to provide
caregivers with an understanding of the patient's environment and support systems. Examples ofrelationships between patients and others include parent, relative, legal guardian, health caresurrogate or payer.
機能説明：医療者に、患者の環境を理解してもらうのに必要な、患者と他の人々との関係に関する情報である。患者と関わる他の人々として、例えば、親、親戚、法的代理人、医療における代理人、支払者などがある。
CPS.1.6.1
705
Function
Related by Genealogy
家系上の関係Statement: Provide information on relationships by genealogy.
機能概要：家系上の関係に関する情報を提供する。
Description: Relationships by genealogy may include genetic mother, next of kin, or family
members. Appropriate consents must be acquired prior to the collection or use of this information.
機能説明：家系上の関係としては、遺伝上の母親、近親者、家族構成員などがある。これらの情報を取得するにあたっては、適切な同意を取得しておかなければならない。
1. The system SHALL provide the ability to capture, maintain 706
and render genealogical relationship information.
1. システムは、家系関係の情報を取得し、維持する機能を提供しなければならない。
2. The system SHALL provide the ability to extract the identity 707
of persons related by genealogy to the patient.
2. システムは、患者にとって家系的に関係する人々の識別情報を取得する機能を提供しなければならない。
CPS.1.6.2
710
Function
Related by Insurance
保険関係Statement: Support interactions with other systems, applications, and modules to provide
information on an insured person's relationships. Examples of relationships include domestic
partner, spouse, and guarantor of payment.
機能概要：被保険者である患者の関係に関する情報を提供するため、他のシステム、アプリケーショ
ン、モジュールとのインタラクションを支援する。関係者の例としては、家庭内のパートナー、配偶者、支払保証人などである。
Description: Identifying relationship of persons insured under the same insurance plan isimportant for administrative transactions.
機能説明：管理業務トランザクションで、同じ保険プランでカバーされる人々の関係を特定することは重要である。
CPS.1.6.3

712

Section/id#：
Type:
Name:
Function
Related by Living
Situation
住まいの状況関係

Conformance Criteria

Row#

Statement: Provide information on relationships by living situation. Examples of living situations
include college dormitory, military deployment, in same household.
機能概要：住まいの状況による関係に関する情報を提供する。住いの状況の例としては、同じ世帯での大学の寮、軍隊、などである。
Description: Living situations may be important means for providers to uniquely identify patientsor to identify illnesses that may occur within a given proximity. Patient relationships that may beaffected by past situations may include the environment of the patient when the patient was a
fetus, for example, a mother who worked in a chemical factory last week or while pregnant withthe patient thirty years prior, or mother carried child during time of extreme famine.
機能説明：住まいの状況は、患者を特定するのに、あるいは近隣で発症した疾病を特定するのに重要な場合がある。過去の状況に影響されうる患者の関係としては、例えば、患者が胎児であったときの親の環境、例えば母親が 30 年前に妊娠しているとき化学工場で働いていた、あるいは極度の飢饉にあった等である。
CPS.1.6.4
714
Function
Related by Other Means
その他の関係Statement: Provide information on patient relationships that are represented other than by
genealogy, insurance or living situation.
機能概要：家系、保険、住まいの状況以外によって表わされる、患者の関係に関する情報を提供する。
Description: Patients relationships are not limited to genealogy, insurance or living situations.
Other examples of patient relationships that are relevant to the healthcare or administrative
process may include surrogate mother, guardian, a person authorized to see health records, healthcare surrogate, and persons who may be related by epidemiologic exposure.
機能説明：患者の関係は、家系、保険、生活状況だけに限るものではない。他に、代理母、後見人、医療記録の閲覧を認められた人、医療代理人、疫学的暴露による関係者などがある。
CPS.1.7
718
Function
Preferences, Directives,
Consents
andAuthorizations
希望、事前指示、同意、権限付与
Statement: Capture and manage patient preferences, advance directives, consents andauthorizations.
機能概要：患者の希望、事前指示、同意、および権限付与について把握し、管理する。
Description: In the Preferences, Directives, Consents and Authorizations functions there are times
when actions/activities related to “patients” are also applicable to the patient representative.
Therefore, in this section, the term “patient” could refer to the patient, and/or the patient’s
personal representative (i.e. guardian, surrogate, proxy, health care agent).
機能説明：希望、事前指示、同意、権限付与の機能においては、患者に関する行為や活動が、患者の代理人に適用される場合がある。したがって、ここでいう「患者」とは、患者あるいは患者の個人的な代理人を指す。

Section/id#：
Type:
Name:
CPS.1.7.1
Function
Support for Patient andFamily Preferences
患者及び家族の希望の支援

Conformance Criteria

Row#
720

Statement:
機能概要：
Description: Decision support functions should permit consideration of patient/family preferences
and concerns, such as with language, religion, culture, medication choice, invasive testing, andadvance directives. Such preferences should be captured in a manner that allows for theirintegration with the health record and easy retrieval from the health record. Preferences may be
specified across all treatment plans or specifically to individual or set of treatment plans.
Preferences may also be used to adjust patient information including labeling and medication
instructions (e.g., for language and print size).
機能説明：意思決定支援の機能は、例えば、言語、宗教、文化、薬の選択、介入検査、事前指示などの患者/家族の意向や懸念を考慮に入れることを支援する。このような意向は、容易に抽出できるよう、医療記録に統合的に捉えられるべきである。意向はすべての治療計画にわたるかもしれない。あるいは特定の治療、治療群についてであるかもしれない。意向の情報は、たとえばラベリングや薬の用法(言語やフォントサイズなど)などの調整にも利用される。
1. The system SHALL provide the ability to capture, maintain 721
and render patient and family preferences as they pertain tocurrent treatment plans.
1. システムは、いまの治療計画に関わる患者や家族の意向を、取得、維持、表示する機能を提供しなければならない。
CPS.1.7.2
728
FunctionManagePatient
Advance Directives
患者の事前指示の管理
Statement: Capture and maintain patient advance directives.
機能概要：事前指示の取得と維持
Description: Patient advance directives and provider Do Not Resuscitate (DNR ) orders arecaptured, as well as the date and circumstances under which the directives were received, and thelocation of any paper or electronic advance directive documentation.Advanced Directives may
include for example living will, durable power of attorney, preferred interventions for known
conditions, or the existence of a "Do Not Resuscitate" order.Circumstances is used to indicate
where, how and when an advanced directive was captured (e.g., provided by the patient's parent
during initial consultation visit).
機能説明：患者の事前指示および、蘇生措置拒否(DNR)指示を、日付とそれら指示が受領された状況とともに取得する。紙もしくは電子的事前指示文書の場所も記録する。事前指示は、例えばリビング
ウィル、永続的委任状、未知の状態における希望する介入、あるいは心肺蘇生拒否指示の存在などを含む。どこで、どのように、いつ事前指示が取得されたか、状況が記載される(例えば、最初のコンサルテーションの際、患者の親から提供された等)
1. The system SHALL provide the ability to manage advance 729
directive information including the type of directive, relevant
dates (e.g., received, reviewed, rescinded, updated),
circumstances under which the directives were received (e.g.,during initial consultation), and the location of any paper orelectronic advance directive documentation.
1. システムは、指示のタイプ、関連する日付(受領した、確認した、

Section/id#：
Type:
Name:

Conformance Criteria
破棄された、更新たれた等)、受領された環境(例えば最初のコン
サルテーション)、および紙や電子媒体の事前指示文書の所在を含めて、事前指示に関する情報を管理する機能を提供しなければならない。
2. The system SHALL render an indication that advancedirective(s) have been captured.
2. システムは、事前指示が取得されたことを表示する機能を提供しなければならない。
3. The system SHALL provide the ability to render the type ofadvance directives captured for the patient (e.g., living will,
durable power of attorney, preferred interventions for known
conditions, or the existence of a "Do Not Resuscitate" order).
3. システムは、患者について把握した事前指示のタイプ(例えば、リビングウィル、永続的委任状, 既知の状態に対し希望する介入、蘇生措置拒否指示の存在)を表示する機能を提供しなければならない。
4. The system SHALL provide the ability to manage "Do Not
Resuscitate" orders.
4. システムは、蘇生措置拒否指示を管理する機能を提供しなければならない。
6. The system SHALL provide the ability to manage the date andcircumstances of the most recent review of the advanced
directives.
6. システムは、最も、最近の事前指示のレビューについて、日付と状況を管理する機能を提供しなければならない。
8. The system SHALL provide the ability to manage the date andtime an advance directives paper document was
signed/completed.
8. システムは、事前指示文書が署名/完成された日付と時間を管理する機能を提供しなければならない。

CPS.1.7.3
FunctionManage Consents andAuthorizations
同意・承認の管理

Row#

730

731

732

734

736

737

Statement: Create, maintain, and verify patient decisions (such as informed consent for treatment
or disclosure).
機能概要：患者の意思(治療や開示についてのインフォームドコンセントなど)を作成、維持し、検証する。
Description: Decisions are documented and include the extent of information, verification levels
and exposition of treatment options. This documentation helps ensure that decisions made at thediscretion of the patient, family, or other responsible party, govern the actual care that is deliveredor withheld. There may be several documents active at any one time that may govern a patient’scare. Both clinical and administrative consents and authorizations are considered part of thisfunction. A consent or authorization includes patient authorization for re-disclosure of sensitive
information to third parties. Consents/Authorizations for printing should include appropriate
standardized forms for patients, guardians, or foster parents. The system must appropriately
present forms for adolescents according to privacy rules. Some jurisdictions may mandate assent.
Assent is agreement by the patient to participate in services when they are legally unable toconsent (e.g., an adolescent, an adult with early dementia).
機能説明：情報の程度、確認のレベル、治療のオプションの提示などを含め、決定についての文書化をはかる。文書は、患者もしくは他の責任を負う者による意向のもとで、決定がなされたことを保障
し、実際に提供された、もしくは取り下げられたケアを管理する。患者のケアに関わる文書は、複数存在する場合がある。臨床的、管理的な同意及び権限付与は、この機能の一部である。同意もしくはSection/id#：
Type:
Conformance Criteria
Row#
Name:
権限付与は、患者の第三者への機微な情報の再開示の権限付与を含む。印字のための同意/承認には、患者や代理人に対する標準的な様式を含むべきである。システムは青少年に対して、プライバシールールに則り、適切な様式を提示しなければならない。地域によっては、アセントを義務付ける規制がある。アセントは、サービスに参加する、法的に同意することはできない(例えば、青少年、若年性の認知症のある成人等)患者による同意である。
1. The system SHALL provide the ability to capture and render 738
an indication that a patient has completed a consent andauthorization (e.g., the patient completes an eye surgery related consent before receiving eye surgery).
1. システムは、患者が同意と権限付与を完了したことを把握し、表示する機能を提供しなければならない。(例えば、患者が眼の手術の前に、手術に関する同意を行った。)
2. The system SHALL provide the ability to capture and render 739
an indication that a patient has withdrawn applicableconsents and authorizations.
2. システムは、患者が同意と権限付与を撤回したことを、把握し、表示する機能を提供しなければならない。
12. The system SHALL provide the ability to capture the source 749
of each consent, such as the patient or the patient's personal
representative if the patient is legally unable to provide it.
12. システムは、患者本人、あるいは患者に法的同意能力がない場
合は患者の代理人など、個々の同意について、同意を行った人を把握する機能を提供しなければならない。
CPS.2
Function
Supportexternallysourced Information
外部ソース情報支援

751

Statement: Capture and maintain a variety of information from multiple external sources.
機能概要：複数の外部ソースからの多様な情報の取得と維持
Description: External sources are those outside the EHR system, including clinical,
administrative, and financial information systems, other EHR systems, Personal Health Record(PHR) systems, and data received through health information exchange networks.
機能説明：外部ソースは当該 EHR システム外の、臨床・管理・財務情報システム、他の EHR シス
テム、個人健康記録（PHR)システム、健康情報交換ネトワークを通じて得られたデータを含むものである。
3. The system SHALL provide the ability to render tagged patient 754
health information derived from administrative or financial
data and the source of that data for use by authorized users.
3. システムは、権限がある利用者が利用するために、タグ付けされた管理あるいは財務データから得られた患者健康情報とそのデータの情報ソースを提示することが要求される。
CPS.2.1
755
Function
Supportexternallysourced
ClinicalDocuments
外部ソース診療文書支援
Statement: Incorporate clinical documentation (computable and scanned) from external (to thesystem) sources.
機能概要：外部ソースから診療文書（コンピュータ利用可能、そしてスキャンしたもの）を取り込む

Description: Mechanisms for incorporating external clinical documentation (including
identification of source) are available. External is considered anything that is external to thesystem - i.e. documents from the organization; but created in another system would be considered'external' for the purposes of this function. Documentation incorporated through thesemechanisms is presented alongside locally captured documentation and notes wherever
appropriate. This covers all types of documents received by the provider that would typically beincorporated into a medical record, including but not limited to faxes, referral authorizations,consultant reports, and patient/resident correspondence of a clinical nature. Intrinsic to theconcept of electronic health records is the ability to exchange health information with otherproviders of health care services. Health information from these external sources needs to bereceived, stored in the patient record, and displayed upon request. External data and documents
addressed in the function include:
1. Laboratory results received through an electronic interface - This information is to be received
and stored in the resident record as discrete data, which means that each separate element of thedata needs to be stored in its own field. Therefore, if laboratory results are received through anelectronic interface, the results are received in the EHR and the laboratory test name, result(value), and unit of measure are correctly displayed as discrete data (vs. report format).
2. Scanned documents received and stored as images (e.g., power of attorney forms, Living wills)- These scanned documents are indexed and can be retrieved based on the document type, date of
the original document, and the date of scanning.
3. Text-based outside reports (e.g., x-ray reports, hospital discharge summaries, history &physicals) - Any mechanism for capturing these reports is addendable: OCR, PDF, image file ofreport, etc.
4. Clinical images from an external source (e.g., radiographic images, digital images from adiagnostic scan or graphical images) – These images may be stored within the system or beprovided through direct linkage to an external source such as a hospital PACS system.
5. Other forms of clinical results, such as wave files of EKG tracings.
6. Medication detail (e.g., a medication history) from an external source such as a pharmacy, thepatient, payer, or another provider - While the medication detail includes the medication name,strength, and SIG, this does not imply that the data will populate the medication module.
7. Structured, text-based reports (e.g., medical summary text in a structured format).
8. Standards-based structured, codified data (e.g., a Continuity of Care Document (CCD) with
SNOMED CT).
Data incorporated through these mechanisms is presented alongside locally captured
documentation and notes wherever appropriate.
機能説明：外部診療文書（情報ソースの識別を含む）を取り込む仕組みが利用可能で、医療用以外のデバイスや実体との通信が職場や患者の自宅のようなケア環境に適した形で支援される。外部ソース
データは適切であればローカルで発生した文書や記録といっしょに提示できる。これは、医療機関が受け取り一般的には医療記録に取り込まれるすべてのタイプのデータを対象とし、ファックスに限定されるわけではなく、紹介許可、コンサルタント報告書、臨床面に関する患者・住民とのやりとりを含む。電子健康記録の本質的なコンセプトとして、健康情報を他の医療ケアサービス提供者と交換できることがあげられる。これらの外部ソースからの健康情報は、受け取られ、患者記録の中に蓄積され、要求に基づいて表示できる必要がある。
外部ソースデータや文書の例として下記が含まれる：
1.電子的インターフェースを通じて受信した臨床検査結果
この情報は受信され、住民の記録の中に不連続データとして保管され、各個別のデータ要素はそれぞれのフィールドに保管される必要がある。したがって、検査結果が電子的インターフェースを通じて受信される場合、その結果は HER の中に受信され、臨床検査名・結果（値）・測定値の単位が正確に表示される（報告書の中あるいはサマリーした形式の代わりに）

2.スキャンした文書として受信し、画像（例 法的委任状、リビングウィル）として保管
3.テキストの外部報告書（例 Ｘ線レポート、病院の退院時サマリ、病歴や理学的検査）
これらの報告書を取り込む仕組みであればよい（例

OCR, PDF, JPEG, TIFF)

4.外部ソースからの臨床画像(例 放射線画像、診断スキャンのデジタル画像、グラフィカル画像）
5.その他の形式の臨床結果（例 心電図波形）
6.小売薬局、患者、他の医療サービス提供者などの外部ソースからの薬歴
薬歴は薬剤名、分量、SIG（一回量）を含む、ただし、データが薬剤管理モジュールに存在することを示すものではない。
7.構造化されたテキストの報告書（例 構造化された形式の医療サマリーテキスト）
8.標準ベースの構造化、コード化データ（SNOMED CT コードを含んだ標準ベース紹介状など）

このようなデータは適切な限りローカルで発生した文書や記録といっしょに提示してよい。
1. The system SHALL provide the ability to capture, store and 756
render external documents.
1. システムは外部文書を取得し、保管し、表示できる機能を提供することが要求される。
2. The system SHALL provide the ability to capture, store and 757
render scanned documents.
2. システムはスキャン文書を取得し、保管し、表示できる機能を提供することが要求される。
5. The system SHALL provide the ability to receive from an 760
external source unstructured, text-based documents andreports.
5. システムは外部ソースの非構造化、テキストベースの文書やレポートを受信できる機能を提供することが要求される。
7. The system SHALL provide the ability to uniquely tag and 762
render scanned documents based on the document type, thedate of the original document and the date of scanningaccording to scope of practice, organizational policy, and/or
jurisdictional law.
7. システムは実行範囲、組織ポリシー、かつ／あるいは管轄区域の法律に従って、文書タイプ、オリジナル文書の日付、スキャンした日付に基づいて、スキャン画像のユニークなタグ付と提示ができる機能を提供することが要求される。
8. The system SHALL provide the ability to link documentation 763
and annotations with structured content (e.g., link
information gathered during an office visit, phone
communication, or e-mail consult with structured content thatis stored as a laboratory result, problem, or diagnosis).
8. システムは文書と注釈を構造化コンテンツとリンクできることが要求される(例 検査結果、プログレムや診断として保管された構造化コンテンツと、診察中、電話のやりとり、あるいは電子メールでのコンサル中に収集した情報をリンク）
11. IF a system receives information from external sources, 766
THEN the system SHALL be able to identify the source of that
information.
11. システムが外部ソースからの情報を受信した場合、システムはその情報のソースを識別できることが要求される。
CPS.2.2
767
Function
Supportexternallysourced Clinical Data

外部ソース臨床データ支援Statement: Incorporate discrete clinical data from external sources and support
communication/presentation of data captured from medical and non-medical devices and entities.
機能概要：外部ソースから個別臨床データを取り込み、そして医療用あるいは非医療用のデバイスや実体からの収集されたデータの通信/表示を支援
Description: Mechanisms for incorporating external clinical data (including identification ofsource) are available and communication with non-medical devices and entities is supported as
appropriate to the care setting such as an office or a patient's home. Externally-sourced data may
be presented with locally-sourced documentation and notes wherever appropriate. This covers all
types of data received by the provider that would typically be incorporated into a medical record,
including but not limited to faxes, referral authorizations, consultant reports, and patient/resident
correspondence of a clinical nature. Intrinsic to the concept of electronic health records is theability to exchange health information with other providers of health care services. Healthinformation from these external sources needs to be received, stored in the patient record, anddisplayed upon request.
Examples of externally-sourced data and documents include:
1. Laboratory results received through an electronic interface.
This information is received and stored in the resident record as discrete data, which means thateach separate element of the data needs to be stored in its own field. Therefore, if laboratory
results are received through an electronic interface, the results are received in the EHR and thelaboratory test name, result (value), and unit of measure are correctly displayed as discrete data
(instead of in report or summarized format).
2. Scanned documents received and stored as images (e.g., power of attorney forms or living wills).
These scanned documents are indexed and can be retrieved, e.g., based on the document type, dateof the original document, and the date of scanning.
3. Text-based outside reports (e.g., x-ray reports, hospital discharge summaries or history andphysical examinations).
Any mechanism for capturing these reports is acceptable (e.g., OCR, PDF, JPG or TIFF).
4. Clinical images from an external source (e.g., radiographic images, digital images from adiagnostic scan or graphical images).
These images may be stored within the system or be available by direct linkage to an externalsource (e.g., a hospital's picture archiving and communication system).
5. Other forms of clinical results (e.g., EKG waveforms).
6. Medication history from an external source such as a retail pharmacy, the patient, or anotherprovider.
While the medication history includes the medication name, strength, and SIG, this does not imply
that the data will populate the medication administration module. In many systems the
medication administration module is populated from the medication order rather than from the
medication history.
7. Structured, text-based reports (e.g., medical summary text in a structured format).
8. Standards-based structured, codified data (such as a standards-based referral letter that
contains SNOMED CT codes).
Such data may be presented with locally-sourced documentation and notes wherever appropriate.
外部臨床データ（情報ソースの識別を含む）を取り込む仕組みが利用可能で、医療用以外のデバイスや実体との通信が職場や患者の自宅のようなケア環境に適した形で支援される。外部ソースデータは適切であればローカルで発生した文書や記録といっしょに提示できる。これは、医療機関が受け取り一般的には医療記録に取り込まれるすべてのタイプのデータを対象とし、ファックスに限定されるわけではなく、紹介許可、コンサルタント報告書、臨床面に関する患者・住民とのやりとりを含む。電子健康記録の本質的なコンセプトとして、健康情報を他の医療ケアサービス提供者と交換できること

があげられる。これらの外部ソースからの健康情報は、受け取られ、患者記録の中に蓄積され、要求に基づいて表示できる必要がある。
外部ソースデータや文書の例として下記が含まれる：
1.電子的インターフェースを通じて受信した臨床検査結果
この情報は受信され、住民の記録の中に不連続データとして保管され、各個別のデータ要素はそれぞれのフィールドに保管される必要がある。したがって、検査結果が電子的インターフェースを通じて受信される場合、その結果は EHR の中に受信され、臨床検査名・結果（値）・測定値の単位が正確に表示される（報告書の中あるいはサマリーした形式の代わりに）
2.スキャンした文書として受信し、画像（例 法的委任状、リビングウィル）として保管
3.テキストの外部報告書（例 Ｘ線レポート、病院の退院時サマリ、病歴や理学的検査）
これらの報告書を取り込む仕組みであればよい（例

OCR, PDF, JPEG, TIFF)

4.外部ソースからの臨床画像(例 放射線画像、診断スキャンのデジタル画像、グラフィカル画像）
5.その他の形式の臨床結果（例 心電図波形）
6.小売薬局、患者、他の医療サービス提供者などの外部ソースからの薬歴
薬歴は薬剤名、分量、SIG（一回量）を含む、ただし、データが薬剤管理モジュールに存在することを示すものではない。
7.構造化されたテキストの報告書（例 構造化された形式の医療サマリーテキスト）
8.標準ベースの構造化、コード化データ（SNOMED CT コードを含んだ標準ベース紹介状など）

このようなデータは適切な限りローカルで発生した文書や記録といっしょに提示してよい。
1. The system SHALL provide the ability to capture and store 768
computable data (e.g., laboratory results, telemetry, or
medication details).
1. システムはコンピュータで扱えるデータ(例 臨床検査結果、テ
レメトリー、薬物詳細）を取得し、保管できる機能を提供することが要求される。
2. The system SHALL provide the ability to capture and store a 769
reference to external data.
2. システムは外部データへの参照を取得し保管できる機能を提供することが要求される。
3. The system SHALL provide the ability to capture and store 770
externally-sourced computable data (e.g., laboratory results,
telemetry, medication details).
3. システムは外部ソースのコンピュータが扱えるデータ（例 臨床
検査結果、テレメトリー、薬物詳細）を取得し、保管できる機能を提供することが要求される。
4. The system SHALL provide the ability to capture and store 771
externally-sourced standards-based structured, codified data.
4. システムは外部ソースの標準ベースの構造化、コード化データを取得し、保管できる機能を提供することが要求される。
CPS.2.3
776
Function
Support
Emergency
MedicalSystemOriginated Data
救急医療システム発生データ支援Statement: Provide the ability to capture and maintain patient information from an external
Emergency Medical System (EMS).

機能概要：外部救急医療システム（EMS）から患者情報取得と維持をできる機能の提供
Description: Emergency Medical Systems can provide care at the patient’s location, prior totransport, or while enroute to medical facilities via ambulance, aeromedical evacuation and othertransport mechanisms. Key parts of information about the patient can be gathered here, some ofwhich is computable data (e.g., EKG and other telemetry), non-computable text-based andmultimedia digital objects (e.g., images, audio reports and conversations).
機能説明：救急医療システムは、患者の所在地や、移送前にあるいは、救急車・患者空輸・その他の搬送方法を通じて医療機関への搬送する間に、ケアを提供することができる。
CPS.2.4
779
Function
Supportexternallysourced Clinical Images
外部ソース臨床画像支援
Statement:
Incorporate
clinical
imagesfromexternal
sourcesandsupportcommunication/presentation of images from medical and non-medical devices and entities.
機能概要：外部ソースから臨床画像を取り込み、そして医療用あるいは非医療用のデバイスや実体からの画像の通信/表示を支援
Description: Mechanisms for incorporating external clinical images (including identification ofsource) are available and communication with non-medical devices and entities is supported as
appropriate to the care setting such as an office or a patient's home. Externally-sourced images
may be presented with locally-sourced documentation and notes wherever appropriate. This
covers all types of images received by the provider that would typically be incorporated into a
medical record. These image documents are indexed and can be retrieved, e.g., based on the
document type, date of the original document, and the date of scanning. Images may also be stored
within the system or accessed by reference to an external system (e.g., a hospital's picturearchiving and communication system). Examples of image formats include OCR, PDF, JPG or
TIFF. Examples of externally-sourced images include: laboratory results report images 2.
Radiographic images3. Images of power of attorney forms, living wills or birth certificates4.
Graphs and charts5. Photographs or drawings of patient wounds6. Wave files of EKG tracings
機能説明：外部臨床画像（情報ソースの識別を含む）を取り込む仕組みが利用可能で、医療用以外のデバイスや実体との通信が職場や患者の自宅のようなケア環境に適した形で支援される。外部ソース
データは適切であればローカルで発生した文書や記録といっしょに提示できる。これは、医療機関が受け取り一般的には医療記録に取り込まれるすべてのタイプの画像を対象とする。これらの画像文書
はインデックス付され検索できる、例えば文書タイプ、オリジナル文書の日付、スキャンした日付に基づいて。また画像はシステム内に保管されてもよいし、外部システム（例 病院の PACS）を参照
することでアクセスしてもよい。例えば画像形式は OCR、PDF、JPG あるいは TIFF を含む：
1.検査結果レポート画像
2.レントゲン写真画像
3.法的委任状、リビングウィル、あるいは出産証明書の画像
4.グラフやチャート
5.写真あるいは患者創傷部スケッチ
6.心電計出力の波形ファイル
CPS.2.5
Function
Supportpatientoriginated Data
患者由来データの支援

783

Statement: Capture and explicitly label patient-originated data, link the data source with thedata, and support provider authentication for inclusion in patient health record.

機能概要：患者に由来するデータの取得と明示的なラベル付け、データとデータ・ソースをリンク、
そして患者健康記録に含めるための医療提供者の認証
Description: It is critically important to be able to distinguish clinically authored andauthenticated data from patient-originated data that is either provided by the patient for inclusionin the EHR or entered directly into the EHR by the patient from clinically authenticated data.
Patients may provide data for entry into the health record or be given a mechanism for entering
this data directly. Patient-originated data intended for use by providers will be available for theiruse.Data about the patient may be appropriately provided by: the patient;2. a surrogate (e.g.,parent, spouse, guardian); 3. an informant (e.g., teacher, lawyer, case worker); or4. devices (e.g.,
blood pressure/ sugar monitors).An electronic health record may provide the ability for direct data
entry by any of these. Patient-originated data may also be captured by devices and transmitted
for inclusion into the electronic health record. Data entered by any of these must be stored withsource information. A provider must authenticate patient-originated data included in the patient's
legal health record. A provider must be able to indicate they have verified the accuracy of patientoriginated data (when appropriate and when a verification source is available) for inclusion in thepatient record. Such verification does not have to occur at each individual data field and can be ata higher level of the data.
機能説明：臨床的に発生し認証されたデータと、患者由来のデータ（患者によって提供され EHR に含められたものや、臨床的に認証されたデータから患者によって直接 EHR に入力されたもの）を区別できることは非常に重要である。患者は健康記録に入力するためにデータを提供したり、このデー
タを直接入力する方法を提供されたりするかもしれない。医療機関によって利用することを意図されて収集された患者由来のデータは医療機関によって利用される。

患者に関するデータは適宜以下によって提供される：
1.患者;
2.代理人（親、配偶者、後見人）あるいは
3.情報提供者（教師、弁護士、ケースワーカー）
4.デバイス（例 血圧/血糖モニター）

電子健康記録はこれらによる直接データ入力機能を提供できるかもしれない。患者由来データはデバ
イスによって取得され、電子健康記録の中に送信されるかもしれない。

これらいずれかによって入力されたデータはソース情報とともに蓄積されなければならない。医療機
関は患者の法的な健康記録に含まれる患者由来データの認証をしなければならない。医療機関は患者記録に含めるために、患者由来データの正確性を（適切で、検証根拠が得られる時）検証し表明できなければならない。
そのような検証は各個人データのフィールドごとに発生すべきではなく、より上位レベルで行うことができる。
1. The system SHALL capture the source of clinical data provided 784
on behalf of the patient and tag the data accordingly.
1. システムは患者のために臨床データの情報ソースを取得し、それに応じてデータにタグ付することが要求される。
2. The system SHALL provide the ability for an authorized user 785(e.g., clinician) to tag as accurate and verified patientoriginated data (when appropriate and when a verification
source is available) for inclusion in the patient record (e.g.,patient-orginated allergy report is verified by clinician so thatit may appear in the allergy list).
2. システムは、権限のある利用者（例 臨床医）が、正確で検証された患者由来のデータとして（適切で、検証根拠が得られる時）

タグ付けし、 患者記録に含めることが要求される（例 患者が発したアレルギー報告は臨床医によって検証され、それがアレ
ルギーのリストの中に入る）。
3. The system SHALL capture patient-sourced data distinctlyfrom provider-sourced data (i.e. ensure that provider sourced
data is not modified by patient-sourced data).
3. システムは医療機関ソースのデータから患者ソースのデータを区別して取得することが要求される（すなわち、医療機関ソースのデータは、患者ソースのデータによって変更されない）
4. The system SHALL capture both structured and unstructured
data as defined in RI.1.2.1 (Manage Record Entries).
4. システムは RI.1.2.1（記録エンティティ管理）に定義されているように構造化と非構造化の両方のデータを取得することが要求される。
CPS.2.6
Function
Support Patient Health
Data
Derivedfrom
AdministrativeandFinancial
DataandDocumentation
管理および財務データや文書から得られた患者健
康データ支援

786

787

790

Statement: Capture and explicitly label patient health data derived from administrative or
financial data; and link the data source with that data.
機能概要：管理および財務データや文書から得られた患者健康データの取得と明示的なラベル付け、
データとデータ・ソースをリンク
Description: It is critically important to be able to distinguish patient health data derived fromadministrative or financial data from clinically authenticated data.
機能説明：臨床的に認証されたデータと、管理および財務データから得られたデータを区別できることは非常に重要である
1. The system SHALL provide the ability to capture, store and 791
render patient health data derived from administrative or
financial data and tag it as such.
1. システムは管理および財務データから得られた患者健康データを取得、保管、表示し、タグ付できる機能を提供することが要求される。
CPS.2.7794
Function
Support Patient Data
Derived from Eligibility,
Formulary and Benefit
Documentation
forElectronic Prescribing
電子処方のための保険加入資格、処方薬リスト、保険プラン文書から得られた患者データ支援Statement: Capture and explicitly label patient data derived from eligibility, formulary andbenefit information; and link the data source with that data.
機能概要：保険加入資格、処方薬リスト、保険プラン情報から得られた患者データの取得と明示的なラベル付け、データとデータ・ソースをリンク
Description: Sources of eligibility, formulary and benefit may provide data for entry into theelectronic prescribing or be given a mechanism for entering this data directly. The data must beexplicitly labeled as derived from eligibility, formulary and benefit information. Patient data thatis derived from eligibility, formulary and benefit data may be provided by:
1. a provider
2. a payer, or
3. entities that transmit or process eligibility, formulary and benefit data
機能説明：保険加入資格、処方薬リスト、保険プランの情報ソースは電子処方に入力するデータを提供する、あるいは直接それらデータを入力する仕組みを持っている。保険加入資格、処方薬リスト、保険プランデータから得られる患者データは次から提供される：
1.医療機関
2.保険者、あるいは
3.保険加入資格、処方薬リスト、保険プランの送信や処理を行うもの
1. The system SHALL provide the ability to manage patient data 795
derived from eligibility, formulary and benefit information.
1. システムは保険加入資格、処方薬リスト、保険プラン情報から得られた患者データを管理できる機能を提供することが要求される。
CPS.2.8
797
Function
Support Medical Device
Originated Data
医療デバイス発生データ
支援
Statement: Support collection and presentation of data captured from medical and medication
monitoring devices.
機能概要：医療用あるいは薬物モニタリングデバイスから獲得されたデータの収集と提示の支援
Description: Collection of medical device information is supported as appropriate to the caresetting. Examples include: vital signs/pulse-oximeter, anesthesia machines, home diagnostic
devices for chronic disease management, laboratory machines, bar coded artifacts
機能説明：医療デバイス情報の収集はケア環境に適切な形で支援される。例としては；バイタル・サ
イン/酸素濃度計、麻酔機器、慢性疾患管理用在宅診断デバイス、臨床検査機器、バーコード付のもの(例 薬剤、予防注射、患者基本、病歴、識別子）、経頭蓋磁気刺激装置、服薬リマインダーシステム
1. The system SHALL provide the ability to capture electronic 798
data from medical devices according to scope of practice,organizational policy, and/or jurisdictional law.
1. システムは実行範囲、組織ポリシー、かつ／あるいは管轄法令に従って、医療デバイスから電子的データを取得する機能を提供することが要求される。
2. The system SHALL provide the ability to render information 799
collected from medical devices as part of the medical record.
2. システムは医療デバイスから取得した情報を医療記録の一部として提示できることが要求される。
CPS.3
HeaderSupportClinicalDocumentation
診療録のサポート

805

Statement: Standard assessments, guidelines and prompts are provided to facilitate decision
support for the optimization of patient care based on specific medical conditions.
要求事項：標準のアセスメント、ガイドライン、助言は、固有の医学的な状況に応じた患者ケアの最適化の決定支援を促進するために提供される。
Description: Provider support is offered for the consideration of issues that would help assure
optimal patient management. These may include standard assessments, care plans and treatment
protocols, with triggers and prompts to assist during the patient encounter. Recommendation forpatient testing and follow-up is also included along with decision support for patient selfmanagement of a condition between patient-provider encounters.
機能説明：医療従事者へのサポートは、最適な患者管理を助ける課題の考察のために提供される。これらは、患者が診療している間、補助するためのトリガーと助言とともに標準なアセスメント、ケアプラン、治療方針を含むかもしれない。患者の検査とフォローアップのための提案も、患者と医療従事者間の状況に応じた患者の自己管理の決定支援とともに含まれる。
CPS.3.1
806
Function
Support for Standard
Assessments
標準アセスメントのサポートStatement: Support the establishment, updates and use of assessment forms that will assist in
the development of and adherence to care plans, guidelines, and protocols at the point of
information capture.
要求事項：情報を取り込む際のケアプラン、ガイドライン、およびプロトコルの開発と定着を補助す
るアセスメントフォームの作成、更新、および使用のサポート
Description: As part of managing assessment definitions, the system will support the ability tocreate a set of assessment forms and, optionally, associated logic (e.g., workflow, business andclinical rules). This assessment definition process may include the ability to define, revise andmanage the tools, files and processing for the conduct of a patient assessment. Furthermore, theassessment definition may also include template development, prompts for additional
information, related notification alerts and workflow processes. When a clinician fills out anassessment, data entered triggers the system to prompt the assessor to consider issues that would
help assure a complete/accurate assessment. A simple demographic value or presenting problem(or combination) could provide a template for data gathering that represents best practice in thissituation, e.g., Type 2 (Adult Onset) Diabetes diabetic review, fall and 70+, and rectal bleeding.
Support for standard assessment may include the ability to record and store the value for theanswers to specific questions in standardized assessment tools or questionnaires. When a specificrecognized-standard assessment does not exist, the system will support the creation of uniquenew, locally-defined assessment. The system may enable, and/or encourage the use of the format
and data elements of similar assessments in the systems whenever possible. (NOTE: A newassessment may not necessarily be unique, since a facility may copy an assessment from anotherfacility.).
機能説明：アセスメント定義の管理の一部として、システムはアセスメントフォームや関連したロジック（例えば、ワークフロー、ビジネスや医療のルール）の作成を支援する。このアセスメント定義のプロセスは、患者アセスメントの指導のためのツールやファイルやプロセスを定義し、改版し、管理することを含むかもしれない。さらに、アセスメント定義は、テンプレート開発、追加の情報の助言、関連した警告の通知、およびワークフローの過程も含むかもしれない。医師がアセスメントを記述した時に、入力されたデータは、完全で正確なアセスメントを確実にするを助ける課題の考察を監査するシステムのきっかけとなる。簡単な人口統計、または当面の問題は、（例えば、２型糖尿病検
査、fall and 70+、直腸出血などの）状況下でのベストプラクティスを示すデータ収集のテンプレー
トを提供できる。標準アセスメントのサポートは標準化されたアセスメントツールの中の特定の質問への回答や質問票を記録し、保存する機能を提供するかもしれない。特定の認められた標準アセスメ
ントが存在しないとき、システムは、固有の新しい、ローカル定義のアセスメントをサポートする。
システムは、可能な範囲で、そのフォーマットと同様なアセスメントの中のデータ要素の利用を有効にし、奨励するかもしれない。
（注釈：新しいアセスメントは、ある施設からコピーされることもある
ため、必ずしも唯一である必要は無いかもしれない）
1. The system SHALL provide the ability to capture, maintain, 807
and render recognized-standard assessment information in
the patient record.
システムは、患者記録の中の認められた標準アセスメント情報を取り込み、管理、提供できなければいけない。
CPS.3.2
815
Function
Supportfor
Patient
Context-Driven

Assessments
患者の状況に応じたアセ
スメントのサポート
要求事項：Statement: Offer prompts based on patient-specific data at the point of information
capture for assessment purposes.
アセスメントを目的とした情報取得の際の、患者固有のデータに基づいた提案
Description: When a clinician fills out an assessment, data entered is matched against data
already in the system to identify potential linkages and optimize patient care. For example, thesystem could scan the medication list and the knowledge base to see if any of the symptoms are
side effects of medication already prescribed. Important diagnoses could be brought to the doctor’s
attention, for instance ectopic pregnancy in a woman of child bearing age, or appendicitis in ageriatric patient who has abdominal pain.
機能説明：医師がアセスメントを記述した時に、入力されたデータは、潜在的なリンクを識別し、患者ケアを最適化するためのシステムの中に存在するデータとあらかじめ結びついている。例えば、システムは、症状のいくつかが既に処方された薬剤の副作用であるかどうかを見るため、薬歴とナレッ
ジベースを取り込む。重要な診断は、医師の注意をもたらすことができる。例えば、子供を出産する
年齢の女性の子宮外妊娠や、腹痛を感じる老人の患者の虫垂炎等。
CPS.3.3
824
Function
Support for Standard
Care Plans, Guidelines,
Protocols
標準的なケアプランとガ
イドラインとプロトコルのサポート
Statement: Support the use of appropriate standard care plans, guidelines, protocols, and/or
clinical pathways for the management of specific conditions.
要求事項：特定の状況を管理するための適切な標準ケアプラン、ガイドライン、プロトコル、クリニ
カルパスの利用支援
Description: A core capability of Clinical Decision Support is that of providing guidelines, plansand protocols to clinicians. These templates or forms can be specific for populations, medical
conditions or individual patients. Before they can be used in care provision standard care plans,
guidelines, protocols, and clinical pathways must be created. These templates or forms may residewithin the system or be provided through links to external sources, and can be modified and used
on a site specific basis. To facilitate retrospective decision support, variances from standard careplans, guidelines, protocols and clinical pathways can be identified and reported.
機能説明：クリニカルデシジョンサポートの中心となる特性は、医師にガイドライン、プラン、プロ
トコルを提供することである。これらのテンプレートやフォームは、母集団（populations）や症状や個々の患者のために特化されることができる。それらが診療の中で使われる前に、標準的なケアプラ
ン、ガイドライン、プロトコル、クリニカルパスは作られなければいけない。これらのテンプレート
やフォームは、システムの中に存在するかもしれないし、外部ソースへのリンクとして提供されるかもしれない。そして、サイト固有の基準において修正され、使われることができる。デシジョンサポ
ートの振り返りを支援するために、標準ケアプランからの逸脱、ガイドライン、プロトコル、クリニ
カルパスは識別され、報告されることができる。
6. The system SHALL conform to function CPS.3.4 (Support for 830
Context-Sensitive Care Plans, Guidelines, Protocols).
システムは、CPS.3.4（状況に応じたケアプラン、ガイドライン、
プロトコルのサポート）に従わなければいけない。
7. The system SHALL conform to function CPS.3.1 (Support for 831
Standard Assessments).
システムは、CPS.3.1（標準アセスメントのサポート）に従わなければいけない。
CPS.3.4
839
FunctionSupport for ContextSensitive Care Plans,
Guidelines, Protocols
状況に応じたケアプラ
ン、ガイドライン、プロト
コルのサポート
Statement: Identify and present the appropriate care plans, guidelines, protocols, and/or clinicalpathways for the management of patient-specific conditions that are identified in a patient clinicalencounter.
要求事項：患者が診療中に識別された患者固有の症状の管理のための最適なケアプラン、ガイドライン、プロトコル、クリニカルパスの識別と提供
Description: At the time of the clinical encounter (problem identification), recommendations fortests, treatments, medications, immunizations, referrals and evaluations are presented based on
evaluation of patient-specific data such as age, gender, developmental stage, their health profile,and any site-specific considerations. These may be modified on the basis of new clinical data at
subsequent encounters.
機能説明：診療時（プロブレム識別時）に検査、治療、薬剤、免疫処置、紹介、評価の推奨は、年齢、性別、発育段階、ヘルスプロフィール、サイト特有の考え方のような患者固有のデータの評価に基づいて提供される。これらは、後の受診において、新しい診療データの基礎として修正されるかもしれない。
1. The system SHALL provide the ability to render care and 840
treatment plans that are sensitive to the context of patient
data and assessments.
システムは、患者データとアセスメントの文脈に応じたケアと治療計画を提供できなくてはいけない。
4. The system SHALL conform to function CPS.3.1 (Support for 843
Standard Assessments).
システムは、CPS.3.1（標準アセスメントのサポート）に従わなければいけない。
5. The system SHALL conform to function CPS.3.2 (Support for 844
Patient Context-Driven Assessments).
システムは、CPS.3.2（患者の状況に応じたアセスメントのサポート）に従わなければいけない。
6. The system SHALL conform to function CPS.3.3 (Support for 845
Standard Care Plans, Guidelines, Protocols).
システムは、CPS.3.3（標準的なケアプランとガイドラインとプ
ロトコルのサポート）に従わなければいけない。
9. The system SHALL provide the ability to capture, maintain 848
and render care plan templates to be used as a basis for thecreation of new plans of care and treatment.
システムは、ケアと治療の新しい計画を作るための基礎として使われるためのケアプランテンプレートを取り込み、管理し、提供できなくてはいけない。
CPS.3.5
848
Function
Support for ResearchProtocols Relative to
Individual Patient Care
個々の患者ケアに関連する研究プロトコルのサポートStatement: Provide support for the management of patients enrolled in research protocols.
要求事項：研究プロトコルに登録された患者の管理のためのサポートの提供
Description: The clinician is presented with appropriate protocols for patients participating inresearch studies, and is supported in the management and tracking of study participants.

機能説明：医師は、臨床研究に参加している患者のための適切なプロトコルを与えられて、研究参加者の管理と追跡の中でサポートされる。
1. The system SHALL provide the ability to present protocols for 850
patients enrolled in research studies.
システムは、臨床研究の中で登録された患者のためのプロトコルを提供できなければいけない。
2. The system SHALL provide the ability to capture, maintain 851
and render research study protocols.
システムは、臨床研究のプロトコルを取り込み、管理、表示できなければいけない。
6. The system SHALL conform to CP.3.3 (Manage Clinical 855
Documents and Notes) to capture patient condition andresponse to treatment.
システムは、患者状態と治療の効果を取り込むため、CP.3.3（診療録とメモの管理）に従わなければいけない。
CPS.3.6860
Function
Support Self-Care
セルフケアのサポート
Statement: Provide the patient with decision support for self-management of a condition between
patient/provider encounters.
要求事項：患者と医療提供者の間のセルフマネージメントのための、患者へのデシジョンサポートの提供
Description: Patients need to follow self-management plans related to their specific conditions.
These plans may include schedules for home monitoring, laboratory tests, and clinical checkups;
recommendations about nutrition, physical activity, tobacco use, etc.; and guidance or reminders
about medications. Information to support self-care may be appropriately provided to: the patient,a surrogate (parent, spouse, guardian), or others involved directly in the patients self care.
機能説明：患者は、固有の状態に関連した、セルフマネージメントのフォローを必要とする。これらの計画は、栄養、身体活動、タバコ等の推奨 薬についてのガイダンスや注意といった、在宅モニタ、
臨床検査、健康診断のスケジュールを含むかもしれない。セルフケアのサポートのための情報は、適切に患者、代理人（両親や配偶者、保護者）や患者のセルフケアに直接関わるその他の人に提供される。
1. The system SHALL provide the ability to capture, maintain 861
and render patient guidelines, protocols and reminders
related to specific clinical conditions.
システムは、固有の症状に関連した患者のガイドライン、プロト
コル、注意を取り込み、維持し、患者に提供されなければいけな
い。
2. The system SHALL provide the ability to determine patient 862
eligibility for, and render appropriate patient guidelines,
protocols, and reminders for, self-management of clinicalconditions.
システムは、症状のセルフマネージメントのための適切な患者のためのガイドライン、プロトコル、注意を決定し、提供しなけ
ればいけない。
5. The system SHALL conform to function CP.1.4 (Manage 865
Problem list).
システムは CP1.4.（(Manage Problem list)）に従わなければい
けない。
CPS.3.7
866
Function
Capture Guidelines andStandards from External
Sources
外部ソースからのガイド

ラインと標準の取り込み
Statement: Capture practice guidance from a variety of “trusted” external sources.
要求事項：各種の“信頼できる”外部ソースからの診療ガイダンスの取り込み
Description: Capture and import information provided by external health care organizations as
relates to clinical practice guidelines (CPGs). External healthcare organizations in this function
include, but are not limited to Patient management systems, Healthcare delivery organizations,
Population health/surveillance organizations (e.g., local, regional, national and global Public
Health services, PAHO, WHO), and professional, governmental, or industrial healthcare
optimization initiatives.
機能説明：診療ガイドライン(CPGs)に関連する外部のヘルスケア組織によって提供された情報の取り込みとインポート。この機能における外部のヘルスケア組織は、ヘルスケア提供業者、住民の健康／監査組織（例えばローカル、地域的、国の、世界的な公共ヘルスサービス、PAHO、WHO）、専門
家、政府、ヘルスケアの最適化を率先する産業界を含むが、患者管理システムには制限されない。
CPS.3.8
868
FunctionManage Documentationof Clinician Response to
Decision
Support
Prompts
デシジョンサポートを促すための医師の対応に関する文書の管理Statement: Capture the decision support prompts and manage provider actions to accept oroverride decision support prompts.
要求事項：デシジョンサポートの助言の取り込みと、デシジョンサポートの助言を受け入れたり、無効化するための提供者の行動の管理。
Description: Provider actions in response to prompts offered from decision support are captured.
Management of these actions be accomplished at the patient level or aggregated for patient
population, research protocol, or organizational trending.
機能説明：デシジョンサポートから促された対応への提供者の行動は、取り込まれる。これらの行動の管理は、患者のレベルや、患者集合、調査プロトコル、組織の傾向に基づく。
1. The system SHALL provide the ability to capture that clinical 869
decision support prompts have been rendered and user
response to accept or override those prompts.
システムは、クリニカルデシジョンサポートの助言が提示され、それらの助言を受け入れまたは変更したことを取り込めなくてはいけない。
2. The system SHALL provide the ability to capture the reason 870
for variation from the decision support prompt.
システムは、デシジョンサポートからなされた助言を変更した
理由を取り込めなくてはいけない。
CPS.3.9873
Function
ClinicalDecision
Support
SystemGuidelines Updates
クリニカルデシジョンサ
ポートシステムのガイド
ラインの更新Statement: Capture and maintain updates of clinical decision support system guidelines andassociated reference material.
要求事項：クリニカルデシジョンサポートシステムのガイドラインと関連する参照資料の更新の取り込みと維持Description: System content such as discharge instructions, clinical guidelines, formularies, andother knowledge bases should be capable of being maintained and updated, independent of aparticular encounter. Clinical decision support rules may be applied to the system using a manual
process. As standards are developed to represent these rules, an automated update will berecommended. Any process to update decision support rules should include the verification of theappropriateness of the rules to the system. This may include but not be limited to authenticity ofthe source, the currency of the version, and any necessary approvals before updates can take place.
機能説明：退院の手順、臨床のガイドライン、処方一覧、他の知識ベースなどのシステムの内容は、特定の診療から独立し、維持され、更新されるべきである。クリニカルデシジョンサポートのルール
は、手動のプロセスによってシステムに適用されるかもしれない。標準がこれらのルールを代表する
ように開発されるため、自動化された更新が推奨される。デシジョンサポートのルールを更新するための様々なプロセスは、システムに対するルールへの妥当性の証明を含むべきである。これは、更新が置き換わる前に、そのバージョンでの流通している内容と必要な承認を含むかもしれない。しかし、その出所の信頼性に左右されてはいけない。
1. The system SHALL provide the ability to maintain the clinical 874
content or rules utilized to generate clinical decision support
reminders and alerts.
システムは、診療内容やクリニカルデシジョンサポートに気づ
かせ、警告するために利用されるルールを維持できなくてはいけない。
CPS.3.10
877
Function
Supportfor
IdentificationofPotential Problems andTrends
潜在的なプロブレムと傾向の識別のサポート
Statement: Identify conditions of clinical interest, identify trends that may lead to significant
problems, and provide prompts for clinical decision support.
要求事項：診療上の重要性の状態の識別と、重要なプロブレムを導く傾向の識別とクリニカルデシジョンサポートの助言の提供
Description: Providing the health care provider with a prompt, notification or alert for identified
specific concerns of clinical interest is a cornerstone of Clinical Decision Support. When personal
health information is collected directly during a patient visit, input by the patient, or acquired
from an external source (laboratory results), it is important to be able to identify and tag potential
problems and trends that may be condition- or patient-specific (given the individual's personal
health profile), or changes warranting further assessment.
機能説明：診療上重要な具体的な関係を示す助言や通知や警告を医療従事者に提供することは、クリニカルデシジョンサポートの基礎である。パーソナルヘルスインフォメーションが患者訪問の間に直接収集されたとき（患者によって入力されたり検査結果等の外部ソースから取得したものを含む）、
それは、潜在的なプロブレムか、（個人のヘルスプロファイルによって与えられた）状況や患者固有や是正されたそれ以上のアセスメントによる変化による傾向かを識別するために重要である。
1. The system SHALL conform to function CP.3.1 (Conduct 878
Assessments) and provide the ability to access standard
assessment data in the patient record.
システムは、CP.3.1（アセスメントの実施）に従い、患者記録の中の標準的なアセスメントデータにアクセスできなければいけない。
CPS.3.11896
Function
Support
Other
Encounter and Episodeof Care Documentation
その他の受診とエピソー
ドオブケア文書のサポートStatement: Where not covered above, provide the means to manage and organize thedocumentation of the health care needed and delivered during an encounter/episode of care.
要求事項：上記で取り扱えない、診療やエピソードオブケアの間に必要とされ、提供されるヘルスケ
アの文書管理と体系化
Description: Using data standards and technologies that support interoperability, effective
documentation of an encounter can promote patient- centered/oriented care and enables real-time,
immediate point-of-service care delivery. Effective encounter and episode-of-care documentation
can facilitate efficient work flow and improve operations performance. This can help to ensure theintegrity of (1) the health record, (2) public health, financial and administrative reporting, and (3)the healthcare delivery process.
機能説明：相互運用性をサポートし、受診時の効果的な文書化をサポートするデータ標準とテクノロジーを使うことによって、患者中心で患者オリエンテッドなケアとリアルタイムで即時なサービス提供時点の配信を促進できる。効果的な診療とエピソードオブケア文書は、効率的なワークフローを容易にし、運用のパフォーマンスを改善できる。これは、(1)ヘルスレコード、(2)パブリックヘルス、財務的で経営上のレポート、および(3)ヘルスケアの提供プロセスの完全性を保証するのに役立つことができる。
1. The system SHALL provide the ability to render patient data 897
by encounter, including previous admissions and episodes ofcare.
システムは、診療による患者データを提供できなくてはいけない。それには、以前の入院やエピソードオブケアを含む。
3. The system SHALL provide the ability to capture encounter 899
documentation by one or more of the following input methods:- direct keyboard entry of text; - structured data entry utilizing
templates, forms, pick lists or macro substitution; anddictation with subsequent transcription of voice to text, either
manually or via voice recognition system.
システムは、次の入力方法による、ひとつやそれ以上の診療文書を取り込めなくてはいけない。テキストのキーボードによる直接入力、構造化データのテンプレート、フォームによる入力、リスト選択、マクロによる置換、音声をテキスト化するディクテーション（手動のものも音声認識システムによるものも含む）
CPS.3.12901
FunctionManageHealthInformation
RecordQuality
ヘルスインフォメーショ
ン記録の品質管理
Statement: Support grammatical and lexical integrity of the health record by providing medical
spelling, thesaurus and grammar ready assistance during clinical documentation as well as
enabling shortcuts for pre-defined text.
要求事項：あらかじめ定義されたテキストのためのショートカットのような、クリニカルドキュメン
テーションを記述する間に手軽にアシストする、医療のスペル、シソーラス、文法を提供することによるヘルスレコードの文法および語彙のサポート
Description: Users and patients will benefit from features that enable rapid checking of spellingand grammar, a medical thesaurus function as well as text shortcuts to expand pre-defined text
during clinical documentation. A shortcut may also be defined to trigger a specific system function
such as the opening of a pre-defined template. These functions may be defined at an enterpriselevel based on scope of practice, organizational policy, and/or jurisdictional law. However, predefined text may also be configured by provider or provider type.
機能説明：利用者と患者は、診療の文書化の際に、あらかじめ定義されたテキストショートカットと同様に、すばやいスペルや文法チェック、医療シソーラス機能から恩恵を受ける。ショートカットは、

既に定義されて公開されたテンプレートのように、特定のシステムで定義されるかもしれない。これ
らの機能は、経験の範囲や、組織のポリシー管轄地域の法律に従って、エンタープライズレベルで定義される。しかし、あらかじめ定義されたテキストは、提供者や提供者のタイプによって設計されているかもしれない。

CPS.3
HeaderSupportClinicalDocumentation
診療文書のサポート

805

Statement: Standard assessments, guidelines and prompts are provided to facilitate decision
support for the optimization of patient care based on specific medical conditions.
要求事項：標準のアセスメント、ガイドライン、助言は、固有の医学的な状況に応じた患者ケアの最適化の決定支援を促進するために提供される。
Description: Provider support is offered for the consideration of issues that would help assure
optimal patient management. These may include standard assessments, care plans and treatment
protocols, with triggers and prompts to assist during the patient encounter. Recommendation forpatient testing and follow-up is also included along with decision support for patient selfmanagement of a condition between patient-provider encounters.
機能説明：医療関係者へのサポートは、最適な患者管理を助ける課題の考察のために提供される。これらは、患者が受療期間、補助するためのトリガーと助言とともに標準的なアセスメント、ケアプラ
ン、治療プロトコルを含むかもしれない。患者の検査とフォローアップのための提案も、患者と医療関係者間の受療に応じた患者の自己管理の決定支援とともに含まれる。
CPS.3.1
806
Function
Support for Standard
Assessments
標準アセスメントのサポートStatement: Support the establishment, updates and use of assessment forms that will assist in
the development of and adherence to care plans, guidelines, and protocols at the point of
information capture.
要求事項：情報を取り込む際のケアプラン、ガイドライン、およびプロトコルの開発と定着を補助す
るアセスメントフォームの作成、更新、および使用のサポート
Description: As part of managing assessment definitions, the system will support the ability tocreate a set of assessment forms and, optionally, associated logic (e.g., workflow, business andclinical rules). This assessment definition process may include the ability to define, revise andmanage the tools, files and processing for the conduct of a patient assessment. Furthermore, theassessment definition may also include template development, prompts for additional
information, related notification alerts and workflow processes. When a clinician fills out anassessment, data entered triggers the system to prompt the assessor to consider issues that would
help assure a complete/accurate assessment. A simple demographic value or presenting problem(or combination) could provide a template for data gathering that represents best practice in thissituation, e.g., Type 2 (Adult Onset) Diabetes diabetic review, fall and 70+, and rectal bleeding.
Support for standard assessment may include the ability to record and store the value for theanswers to specific questions in standardized assessment tools or questionnaires. When a specificrecognized-standard assessment does not exist, the system will support the creation of uniquenew, locally-defined assessment. The system may enable, and/or encourage the use of the format
and data elements of similar assessments in the systems whenever possible. (NOTE: A newassessment may not necessarily be unique, since a facility may copy an assessment from anotherfacility.).
機能説明：アセスメント定義の管理の一部として、システムはアセスメントフォームや関連したロジ

ック（例えば、ワークフロー、ビジネスや医療のルール）の作成を支援する。このアセスメント定義のプロセスは、患者アセスメントの指導のためのツールやファイルやプロセスを定義し、改版し、管理することを含むかもしれない。さらに、アセスメント定義は、テンプレート開発、追加の情報の助言、関連した警告の通知、およびワークフローの過程も含むかもしれない。臨床家がアセスメントを記述した時に、入力されたデータは、完全で正確なアセスメントを確実にするのを助ける課題の考察を監査するシステムのきっかけとなる。単純な患者の基本情報の値、または当面の問題は、（例えば、２型糖尿病検査、fall and 70+、直腸出血などの）状況下でのベストプラクティスを示すデータ収集のテンプレートを提供できる。標準アセスメントのサポートは標準化されたアセスメントツールの中の特定の質問への回答や質問票を記録し、保存する機能を提供するかもしれない。特定の広く認められた標準アセスメントが存在しないとき、システムは、固有の新しい、ローカル定義のアセスメントをサポートする。システムは、可能な範囲で、そのフォーマットと同様なアセスメントの中のデータ要素の利用を有効にし、奨励するかもしれない。
（注釈：新しいアセスメントは、ある施設からコピーされることもあるため、必ずしも唯一である必要は無いかもしれない）
1. The system SHALL provide the ability to capture, maintain, 807
and render recognized-standard assessment information in
the patient record.
システムは、患者記録の中の広く認められた標準アセスメント
情報を取り込み、管理し、提示する機能を提供しなければならない。
CPS.3.2
815
Function
Supportfor
Patient
Context-Driven
Assessments
患者の状況に応じたアセ
スメントのサポート
Statement: Offer prompts based on patient-specific data at the point of information capture forassessment purposes.
アセスメントを目的とした情報取得の際の、患者固有のデータに基づいた提案
Description: When a clinician fills out an assessment, data entered is matched against data
already in the system to identify potential linkages and optimize patient care. For example, thesystem could scan the medication list and the knowledge base to see if any of the symptoms are
side effects of medication already prescribed. Important diagnoses could be brought to the doctor’s
attention, for instance ectopic pregnancy in a woman of child bearing age, or appendicitis in ageriatric patient who has abdominal pain.
機能説明：臨床家がアセスメントを記述した時に、入力されたデータは、潜在的なリンクを識別し、患者ケアを最適化するためのシステムの中に存在するデータとあらかじめ結びついている。例えば、システムは、症状のいくつかが既に処方された薬剤の副作用であるかどうかを見るため、薬歴とナレッジベースを取り込む。重要な診断は、医師の注意をもたらすことができる。例えば、子供を出産す
る年齢の女性の子宮外妊娠や、腹痛を感じる老人の患者の虫垂炎等。
CPS.3.3
824
Function
Support for Standard
Care Plans, Guidelines,
Protocols
標準的なケアプランとガ
イドラインとプロトコルのサポート
Statement: Support the use of appropriate standard care plans, guidelines, protocols, and/or
clinical pathways for the management of specific conditions.
要求事項：特定の状況を管理するための適切な標準ケアプラン、ガイドライン、プロトコル、クリニ
カルパスの利用支援
Description: A core capability of Clinical Decision Support is that of providing guidelines, plansand protocols to clinicians. These templates or forms can be specific for populations, medical
conditions or individual patients. Before they can be used in care provision standard care plans,guidelines, protocols, and clinical pathways must be created. These templates or forms may residewithin the system or be provided through links to external sources, and can be modified and used
on a site specific basis. To facilitate retrospective decision support, variances from standard careplans, guidelines, protocols and clinical pathways can be identified and reported.
機能説明：クリニカルデシジョンサポートの中心となる特性は、臨床家にガイドライン、プラン、プ
ロトコルを提供することである。これらのテンプレートやフォームは、母集団（populations）や症状や個々の患者のために特化されることができる。それらが診療の中で使われる前に、標準的なケアプ
ラン、ガイドライン、プロトコル、クリニカルパスは作られなければいけない。これらのテンプレー
トやフォームは、システムの中に存在するかもしれないし、外部ソースへのリンクとして提供されるかもしれない。そして、サイト固有の基準において修正され、使われることができる。デシジョンサ
ポートの振り返りを支援するために、標準ケアプランからの逸脱、ガイドライン、プロトコル、クリニカルパスは識別され、報告されることができる。
6. The system SHALL conform to function CPS.3.4 (Support for 830
Context-Sensitive Care Plans, Guidelines, Protocols).
システムは、CPS.3.4（状況に応じたケアプラン、ガイドライン、
プロトコルのサポート）に従わなければならない。
7. The system SHALL conform to function CPS.3.1 (Support for 831
Standard Assessments).
システムは、CPS.3.1（標準アセスメントのサポート）に従わなければならない。
CPS.3.4
839
Function
Support for ContextSensitive Care Plans,
Guidelines, Protocols
状況に応じたケアプラ
ン、ガイドライン、プロト
コルのサポート
Statement: Identify and present the appropriate care plans, guidelines, protocols, and/or clinicalpathways for the management of patient-specific conditions that are identified in a patient clinicalencounter.
要求事項：患者が受療中に識別された患者固有の症状の管理のための最適なケアプラン、ガイドライン、プロトコル、クリニカルパスの識別と提供
Description: At the time of the clinical encounter (problem identification), recommendations fortests, treatments, medications, immunizations, referrals and evaluations are presented based on
evaluation of patient-specific data such as age, gender, developmental stage, their health profile,and any site-specific considerations. These may be modified on the basis of new clinical data at
subsequent encounters.
機能説明：受療時（プロブレム識別時）に検査、治療、投薬、免疫処置、紹介、評価の推奨は、年齢、性別、発育段階、ヘルスプロフィール、サイト特有の考え方のような患者固有のデータの評価に基づいて提供される。これらは、後の受療において、新しい診療データの基礎として修正されるかもしれない。
1. The system SHALL provide the ability to render care and 840
treatment plans that are sensitive to the context of patient
data and assessments.
システムは、患者データとアセスメントの文脈に応じたケアと治療計画を提示する機能を提供しなければならない。
4. The system SHALL conform to function CPS.3.1 (Support for 843
Standard Assessments).
システムは、CPS.3.1（標準アセスメントのサポート）に従わなければならない。
5. The system SHALL conform to function CPS.3.2 (Support for 844
Patient Context-Driven Assessments).
システムは、CPS.3.2（患者の状況に応じたアセスメントのサポート）に従わなければならない。
6. The system SHALL conform to function CPS.3.3 (Support for 845
Standard Care Plans, Guidelines, Protocols).

システムは、CPS.3.3（標準的なケアプランとガイドラインとプ
ロトコルのサポート）に従わなければならない。
9. The system SHALL provide the ability to capture, maintainand render care plan templates to be used as a basis for thecreation of new plans of care and treatment.
システムは、ケアと治療の新しい計画を作るための基礎として使われるためのケアプランテンプレートを取り込み、管理し、提示する機能を提供しなければならない。
CPS.3.5
Function
Support for ResearchProtocols Relative to
Individual Patient Care
個々の患者ケアに関連する研究プロトコルのサポ
ート

848

848

Statement: Provide support for the management of patients enrolled in research protocols.
要求事項：研究プロトコルに登録された患者の管理のためのサポートの提供
Description: The clinician is presented with appropriate protocols for patients participating inresearch studies, and is supported in the management and tracking of study participants.
機能説明：臨床家は、臨床研究に参加している患者のための適切なプロトコルを与えられて、研究参加者の管理と追跡の中でサポートされる。
1. The system SHALL provide the ability to present protocols for 850
patients enrolled in research studies.
システムは、臨床研究の中で登録された患者のためのプロトコ
ル機能を提供できなければならない。
2. The system SHALL provide the ability to capture, maintain 851
and render research study protocols.
システムは、臨床研究のプロトコルを取り込み、管理、提示する機能を提供しなければならない。
6. The system SHALL conform to CP.3.3 (Manage Clinical 855
Documents and Notes) to capture patient condition andresponse to treatment.
システムは、患者状態と治療の効果を取り込むため、CP.3.3（診療文書とメモの管理）に従わなければならない。
CPS.3.6860
Function
Support Self-Care
セルフケアのサポート
Statement: Provide the patient with decision support for self-management of a condition between
patient/provider encounters.
要求事項：患者と医療関係者の受療の間のセルフマネージメントのための、患者へのデシジョンサポートを提供すること
Description: Patients need to follow self-management plans related to their specific conditions.
These plans may include schedules for home monitoring, laboratory tests, and clinical checkups;
recommendations about nutrition, physical activity, tobacco use, etc.; and guidance or reminders
about medications. Information to support self-care may be appropriately provided to: the patient,a surrogate (parent, spouse, guardian), or others involved directly in the patients self care.
機能説明：患者は、固有の状態に関連した、セルフマネージメントのフォローを必要とする。これらの計画は、栄養、身体活動、タバコ等の推奨 投薬についてのガイダンスや注意といった、在宅モニ
タリング、臨床検査、健康診断のスケジュールを含むかもしれない。セルフケアのサポートのための情報は、適切に患者、代理人（両親や配偶者、後見人）や患者のセルフケアに直接関わるその他の人に提供される。
1. The system SHALL provide the ability to capture, maintain 861

and render patient guidelines, protocols and reminders
related to specific clinical conditions.
システムは、固有の症状に関連した患者のガイドライン、プロト
コル、注意を取り込み、維持し、患者に提示する機能を提供しなければならない。
2. The system SHALL provide the ability to determine patienteligibility for, and render appropriate patient guidelines,
protocols, and reminders for, self-management of clinicalconditions.
システムは、症状のセルフマネジメントのための患者のための
適切なガイドライン、プロトコル、注意を表示し、患者の保険加入資格を決定し、提示する機能を提供しなければならない。
5. The system SHALL conform to function CP.1.4 (Manage
Problem list).
システムは CP1.4.（(Manage Problem list)）に従わなければな
らない。
CPS.3.7
Function
Capture Guidelines andStandards from External
Sources
外部ソースからのガイド
ラインと標準の取り込み

862

865

866

Statement: Capture practice guidance from a variety of “trusted” external sources.
要求事項：各種の“信頼できる”外部ソースからの診療ガイダンスの取り込み
Description: Capture and import information provided by external health care organizations as
relates to clinical practice guidelines (CPGs). External healthcare organizations in this function
include, but are not limited to Patient management systems, Healthcare delivery organizations,
Population health/surveillance organizations (e.g., local, regional, national and global Public
Health services, PAHO, WHO), and professional, governmental, or industrial healthcare
optimization initiatives.
機能説明：診療ガイドライン(CPGs)に関連する外部の医療機関によって提供された情報の取り込みとインポート。この機能における外部の医療機関は、ヘルスケア提供業者、住民の健康／監査組織（例えばローカル、地域的、国の、世界的な公共衛生サービス、PAHO、WHO）、専門家、政府、ヘルスケアの最適化を率先する産業界を含むが、患者管理システムには制限されない。
CPS.3.8
868
FunctionManage Documentationof Clinician Response to
Decision
Support
Prompts
デシジョンサポートを促すための臨床家の対応に関する文書の管理Statement: Capture the decision support prompts and manage provider actions to accept oroverride decision support prompts.
要求事項：デシジョンサポートの助言の取り込みと、デシジョンサポートの助言を受け入れるか、覆す医療関係者のアクションを管理すること。
Description: Provider actions in response to prompts offered from decision support are captured.
Management of these actions be accomplished at the patient level or aggregated for patient
population, research protocol, or organizational trending.
機能説明：デシジョンサポートから促された対応への医療関係者の行動は、取り込まれる。これらの行動の管理は、患者のレベルや、患者集合、調査プロトコル、組織の傾向に基づく。
1. The system SHALL provide the ability to capture that clinical 869

CPS.3.9
Function
ClinicalDecision
Support
SystemGuidelines Updates
クリニカルデシジョンサ
ポートシステムのガイド
ラインの更新decision support prompts have been rendered and user
response to accept or override those prompts.
システムは、クリニカルデシジョンサポートの助言が提示され、それらの助言を受け入れまたは変更したことを取り込める機能を提供しなければならない。
2. The system SHALL provide the ability to capture the reason 870
for variation from the decision support prompt.
システムは、デシジョンサポートからなされた助言を変更した
理由を取り込める機能を提供しなければならない。
873

Statement: Capture and maintain updates of clinical decision support system guidelines andassociated reference material.
要求事項：クリニカルデシジョンサポートシステムのガイドラインと関連する参照資料の更新の取り込みと維持
Description: System content such as discharge instructions, clinical guidelines, formularies, andother knowledge bases should be capable of being maintained and updated, independent of aparticular encounter. Clinical decision support rules may be applied to the system using a manual
process. As standards are developed to represent these rules, an automated update will berecommended. Any process to update decision support rules should include the verification of theappropriateness of the rules to the system. This may include but not be limited to authenticity ofthe source, the currency of the version, and any necessary approvals before updates can take place.
機能説明：退院の手順、臨床のガイドライン、処方一覧、他の知識ベースなどのシステムの内容は、特定の受療から独立し、維持され、更新されるべきである。クリニカルデシジョンサポートのルール
は、手動のプロセスによってシステムに適用されるかもしれない。標準がこれらのルールを代表する
ように開発されるため、自動化された更新が推奨される。デシジョンサポートのルールを更新するための様々なプロセスは、システムに対するルールへの妥当性の証明を含むべきである。これは、更新が置き換わる前に、そのバージョンでの流通している内容と必要な承認を含むかもしれない。しかし、その出所の信頼性に左右されてはいけない。
1. The system SHALL provide the ability to maintain the clinical 874
content or rules utilized to generate clinical decision support
reminders and alerts.
システムは、診療内容やクリニカルデシジョンサポートに気づ
かせ、警告するために利用されるルールを維持する機能を提供しなければならない。
CPS.3.10
877
Function
Supportfor
IdentificationofPotential Problems andTrends
潜在的なプロブレムと傾向の識別のサポート
Statement: Identify conditions of clinical interest, identify trends that may lead to significant
problems, and provide prompts for clinical decision support.
要求事項：診療上の重要性の状態の識別と、重要なプロブレムを導く傾向の識別とクリニカルデシジョンサポートの助言の提供
Description: Providing the health care provider with a prompt, notification or alert for identified
specific concerns of clinical interest is a cornerstone of Clinical Decision Support. When personal

health information is collected directly during a patient visit, input by the patient, or acquired
from an external source (laboratory results), it is important to be able to identify and tag potential
problems and trends that may be condition- or patient-specific (given the individual's personal
health profile), or changes warranting further assessment.
機能説明：診療上重要な具体的な関係を示す助言や通知や警告を医療関係者に提供することは、クリニカルデシジョンサポートの基礎である。パーソナルヘルスインフォメーションが患者訪問の間に直接収集されたとき（患者によって入力されたり臨床検査結果等の外部ソースから取得したものを含む）、それは、潜在的なプロブレムか、（個人のヘルスプロファイルによって与えられた）状況や患者固有や是正されたそれ以上のアセスメントによる変化による傾向かを識別するために重要である。
1. The system SHALL conform to function CP.3.1 (Conduct 878
Assessments) and provide the ability to access standard
assessment data in the patient record.
システムは、CP.3.1（アセスメントの実施）に従い、患者記録の中の標準的なアセスメントデータにアクセスする機能を提供しなければならない。
CPS.3.11896
Function
Support
Other
Encounter and Episodeof Care Documentation
その他の受療とケア文書のサポート
Statement: Where not covered above, provide the means to manage and organize thedocumentation of the health care needed and delivered during an encounter/episode of care.
要求事項：上記で取り扱えない、診療やケアの間に必要とされ、提供されるヘルスケアの文書管理と体系化
Description: Using data standards and technologies that support interoperability, effective
documentation of an encounter can promote patient- centered/oriented care and enables real-time,
immediate point-of-service care delivery. Effective encounter and episode-of-care documentation
can facilitate efficient work flow and improve operations performance. This can help to ensure theintegrity of (1) the health record, (2) public health, financial and administrative reporting, and (3)the healthcare delivery process.
機能説明：相互運用性をサポートし、受療時の効果的な文書化をサポートするデータ標準とテクノロジーを使うことによって、患者中心で患者オリエンテッドなケアとリアルタイムで即時なサービス提供時点の配信を促進できる。効果的な受療とケアの間の文書は、効率的なワークフローを容易にし、運用のパフォーマンスを改善できる。これは、(1)ヘルスレコード、(2)公衆衛生、財務的で経営上のレポート、および(3)ヘルスケアの提供プロセスの完全性を保証するのに役立つことができる。
1. The system SHALL provide the ability to render patient data 897
by encounter, including previous admissions and episodes ofcare.
システムは、受療による患者データを提示する機能を提供しなければならない。それには、以前の入院やエピソードオブケアを含む。
3. The system SHALL provide the ability to capture encounter 899
documentation by one or more of the following input methods:- direct keyboard entry of text; - structured data entry utilizing
templates, forms, pick lists or macro substitution; anddictation with subsequent transcription of voice to text, either
manually or via voice recognition system.
システムは、次の入力方法による、ひとつやそれ以上の受療文書を取り込める機能を提供しなければならない。テキストのキー
ボードによる直接入力、構造化データのテンプレート、フォーム
による入力、リスト選択、マクロによる置換、音声をテキスト化
するディクテーション（手動のものも音声認識システムによるものも含む）
CPS.3.12901
Function

Manage
HealthInformation
RecordQuality
ヘルスインフォメーショ
ン記録の品質管理
Statement: Support grammatical and lexical integrity of the health record by providing medical
spelling, thesaurus and grammar ready assistance during clinical documentation as well as
enabling shortcuts for pre-defined text.
要求事項：あらかじめ定義されたテキストのためのショートカットのような、診療文書を記述する間に手軽にアシストする、医療のスペル、シソーラス、文法を提供することによるヘルスレコードの文
法および語彙のサポート
Description: Users and patients will benefit from features that enable rapid checking of spellingand grammar, a medical thesaurus function as well as text shortcuts to expand pre-defined text
during clinical documentation. A shortcut may also be defined to trigger a specific system function
such as the opening of a pre-defined template. These functions may be defined at an enterpriselevel based on scope of practice, organizational policy, and/or jurisdictional law. However, predefined text may also be configured by provider or provider type.
機能説明：利用者と患者は、診療の文書化の際に、あらかじめ定義されたテキストショートカットと同様に、すばやいスペルや文法チェック、医療シソーラス機能から恩恵を受ける。ショートカットは、
既に定義されて公開されたテンプレートのように、特定のシステムで定義されるかもしれない。これ
らの機能は、経験の範囲や、組織ポリシー管轄区域の法律に従って、エンタープライズレベルで定義される。しかし、あらかじめ定義されたテキストは、医療関係者や医療関係者のタイプによって設計されているかもしれない。

CPS.4HeaderSupport Orders

911

Statement: Support for Orders is required to ensure that appropriate decision support and safety
checks are conducted by the system at the time of ordering as well as at the time of dispensing
medications or immunizations.
薬処方オーダの発行時に、分かっている患者特有な条件や特徴に基づき適切な投薬量を確認し提示する
Description: Support for orders includes the management of order set templates, the support for
specific types of orders including medication, immunization, non-medication, diagnostic tests aswell as blood products and biologicals. Decision Support for orders includes checking for allergies
or adverse interactions, dosing checking and issuing the appropriate warnings. It may also include
functions to increase ordering efficiency such as verifying all necessary information to fulfill theorder is captured and making recommendations for supporting orders. A component of ordering
medications and immunizations is the dispensing of those orders and, where applicable, thisfunction will include criteria to support dispensing. Note: Administration of Orders is included in
CPS.6 (Support for Treatment Administration).
臨床医は薬剤の相互作用と患者特有の禁忌や警告（例えば、妊娠、授乳、職業的なリスク、肝臓薬や腎不全など）を注意喚起される。また患者の好み（例えば、抗生物質を使用することを好まないなど）を提示することが求められる。例えば、年齢、世代、遺伝的傾向、身長、体重や体表面積などを患者の付加できる変数として組み込まれることを推奨する。
CPS.4.1
915
FunctionManageOrder
Set
Templates
1. The system SHALL provide the ability to manage order set
templates, including creation from provider input and version
control.
医療提供者の入力による作成物と版数管理を含めてオーダセッ
トテンプレートを管理できる機能を提供すること。
6. The system SHALL conform to function CP.4.1 (Use Order
Sets).
CP.4.1 の機能（オーダセットの使用）に準拠すること。
17. The system SHALL provide the ability to capture a name foran order set.
オーダセットに対する名前を保存できる機能を提供すること。
18. The system SHALL provide the ability to render order set(s)by name.
名前によってオーダセットを提示する機能を提供すること。
19. The system SHALL provide the ability to render orders in thesame manner regardless of the manner in which they wereordered (individually or from within an order set).
（個別にオーダされたかあるいはオーダセットの中からオーダされたかといった）オーダされた方法に関係なく、同じ方法でオーダを提示する機能を提供すること。
21. The system SHALL determine and render drug-druginteraction and drug-allergy reaction checking to orders
placed through an order set in the same way as orders placed
individually.
個別に出されたオーダと同じ方法で、オーダセットを介して出されたオーダに対して、薬物相互作用と薬物アレルギー反応を確定して提示する機能を提供すること。
23. The system SHALL provide the ability to capture, maintainand render order sets that allow or disallow individual orders
to be selected or deselected by the user (e.g., standing orders

916

921
932
933
934

936

938

that can't be modified during care provision).
使用者によって選択あるいは選択解除された個々のオーダを承認するあるいは却下するオーダセットを保存して保持して提示する機能を提供すること。
（例えば、処置を提供している間に修正できなかった有効なオーダ）
CPS.4.2
Function
Support for Medication
andImmunization
Ordering

940

Statement: Provide functionality to alert providers to potential medication and immunization
ordering errors (such as wrong patient, wrong drug, wrong dose, wrong route and wrong time).
投薬や予防接種を指示する際に起こりうるミス（患者や薬剤、適用量、手順、時間などの間違い）などを警告する機能を提供する
Description: During medication or immunization ordering it is critical to minimize potential errorsthat can cause adverse events. This is accomplished by the EHR system through the use of clinicaldecision support and prompting to validate the order at time of ordering. Whist many of thesefunctions are more commonly associated with medication ordering; they also apply to ordering of
immunizations when such ordering occurs. The support includes the checking for drug/druginteractions, checking against documented allergies or previous adverse events as well as
validating patient-specific dosing and providing appropriate warnings. support for medial
ordering efficiencies also ensures that orders are appropriate and contain all required supporting
information.
投薬や予防接種を指示している間、重大な病気を引き起こすかもしれないミスを最小限にすることが重要である。医師の決定をサポートしたり、その時の処方の正当性を証明する EHR システムによって実現可能である。投薬や予防接種を指示する際に、これらのシステムの機能を適用することが可能である。投薬が正当であるかどうかだけではなく、薬の相互作用やアレルギー、以前に重大な病気にかかっていないかなどをチェックし、適切に警告することが可能である。医学的な指示を効率的に実現させるだけでなく、その処置処方が適切で、必要な全ての情報を含んでいることをサポートする。
1. The system SHALL provide the ability to maintain a discrete 941
list of orderable medications and immunizations (i.e.,
formulary).
システムはオーダが可能な薬剤と予防接種の個々の一覧を保持する機能を提供すること。(すなわち、処方一覧）
8. The system SHALL provide the ability to maintain directly or 948
by reference a list (i.e. formulary) of medications andimmunizations which includes a unique identifier for each
medication / immunization.
システムは薬剤それぞれに対して一意の識別名を持つ薬剤と予防接種のコード化された処方一覧を保持する機能を提供すること。
CPS.4.2.1
952
Function
Support for Medication
Interaction and Allergy
Checking
Statement: Identify medication interaction warnings at the time of medication or immunization
ordering, or prescribing, as well as at the time of dispensing.
処方オーダの発行時に、薬剤間の相互作用の警告を確認する
Description: The clinician is alerted to medication-medication, medication-allergy, medicationfood, medication-supplement (herbal or dietary) interactions at levels appropriate to the healthcare setting and with respect to the patient condition. These alerts may be customized to suit theuser or group.Note, medication may be affected by food or diatary choices; whist this is notconsidered an interaction it is consequently not included in this function; however, the provisionof drug-food effectiveness in information to be provided to the patient is included in the function
CP.8.1 (Generate, Record and Distribute Patient-Specific Instructions).If the patient’s condition isone where, in order to view the necessary components of the health record, patient authorizationor consent is required; then the system should show the
medication but mask the condition for which the medication is prescribed until the requiredconsent or authorization is available. In an emergent situation, where all health information isrequired to provide the most effective treatment, and it is not possible to obtain an authorizationor consent; the system should provide an override (e.g., "break the glass") function to allow accessto the diagnosis or problem for which a medication was ordered, according to scope of practice,organizational policies, and/or jurisdictional law.
薬と薬、薬とアレルギー、薬と食物、薬と薬草、薬とサプリメントなどの健康に関わる相互作用と患者の健康状態について、臨床家は注意喚起される。これらの警告は、ユーザやグループにより適切に
カスタマイズが可能である。投薬は食物や食生活の選択に影響を与える可能性がある。薬剤と食物の相互作用は、患者に対して情報提供が必要であり、本節では検討しないが CP.8.1 に含む。患者の状
態は患者固有のものであるので、患者の承認や同意はヘルスレコードの必須要素である。同意や承認が得られるまで、処方された薬剤はマスクされた状態でシステム上は提示する必要がある。緊急時には、全てのヘルスインフォメーションは最も効率的な取り扱いが求められるが、患者から承認や同意が得られるとは限らない。システムは、慣習や組織の方針、管轄区域の法律に従う範囲で、以前に処方された薬剤に対する診断やプロブレムにアクセスするために、アクセス状態を無視する機能が必要になる。
1. The system SHALL determine and present the presence of 953
interactions between medications ordered and medications
already on the current medication list.処方された薬剤と現在服用している薬剤や現時点の情報の間に相互作用があることを判断し、症状を判断すること。
2. The system SHALL determine and present the presence of 954
interactions between medications ordered and true-allergies
on the current allergy list.処方された薬剤と現在患っているア
レルギーの間に相互作用があることを判断すること。
7. The system SHALL provide the ability to capture, maintain 959
and render a medication order despite alerts for interactions,
and/or allergies being present.相互作用やアレルギーがあるという警告にも関わらず処方された薬剤を保存、保持する機能を提供すること。
9. The system SHALL conform to function CPS.3.8 (Manage 961
Documentation of Clinician Response to Decision Support
Prompts) and provide the ability to document why a druginteraction warning was overridden. CPS 3.8 （ 意思決定支援に対する臨床家の反応に関する文書の管理 ） の機能と薬剤を相互作用が拒絶された理由を文書化する機能に準拠すること。
12. The system SHALL provide the ability to present, on demand, 964
potential medication-allergy, medication-medication andmedication-condition interactions based on current
medications, active allergies and active problems lists.要求に応じて、現在の処方、アクティブなアレルギー、問題点に基づき潜在的な薬物アレルギー、薬品間相互作用、薬剤診断相互作用を表示する機能を提供すること。
14. The system SHALL conform to CP.1.3 (Manage Medication 966
List) in order to maintain a coded list of medications for thepatient (including a unique identifier for each medication).
患者のためにコード化された薬品の一覧（薬品毎に一意の識別子を含む）をメンテナンスするために、CP.1.3(投薬リスト管理)に準拠すること。
CPS.4.2.2
969
Function
Support for patientspecific
DosingandWarnings
Statement: Identify and present appropriate dose recommendations based on known patient
conditions and characteristics at the time of medication ordering and dispensing.

薬処方オーダの発行時に、分かっている患者特有な条件や特徴に基づき適切な投薬量を確認し提示する
Description: The clinician is alerted to patient-specific contraindications and warnings e.g.,pregnancy, breast-feeding or occupational risks, hepatic or renal insufficiency. The preferences ofthe patient may also be presented (e.g., reluctance to use an antibiotic). Additional patientparameters, such as age, gestation, genetic disposition, height, weight, and Body Surface Area
(BSA), shall also be incorporated.
臨床家は薬剤の相互作用と患者特有の禁忌や警告（例えば、妊娠、授乳、職業的なリスク、肝臓薬や腎不全など）を注意喚起される。また患者の好み（例えば、抗生物質を使用することを好まないなど）を提示することが求められる。例えば、年齢、世代、遺伝的傾向、身長、体重や体表面積などを患者の付加できる変数として組み込まれることを推奨する。
1. The system SHALL determine and render contraindications to 970
the ordered dosage range.
オーダに対する投与量の範囲を禁忌を判断し表示すること。
4. IF the maximum daily doses are known, THEN the system 973
SHALL present the maximum dose per day in dosing decision
support.
一日の最大投与量が既知の場合、投与量の意思決定を支援し一日あたりの最大投与量を提示すること。
12. The system SHALL determine whether data required to 981
compute a dose are missing or invalid and render notifications
to the provider.
投与量を計算するために不足や無効な必須データがないか判断し、医療関係者に対して通知を提示すること。
20. The system SHALL provide the ability to capture, store and 989
render information concerning medication orders including
any alerts following screening of medication orders and theclinician responses (place, modify or cancel order).薬剤オーダのスクリーニングに続く警告と臨床家の反応（場所、修正や中止オーダ）含む薬剤オーダの警告情報を保存、蓄積、提示する機能を提供すること。
CPS.4.2.3
993
Function
Support for Medication
Ordering Efficiencies
Statement: Provide the tooling necessary to support efficient medication ordering.
効率的に薬剤オーダを支持するのに必要なツールの提供
Description: Support efficient medication ordering workflows by allowing medications to be sorted
and reviewed by key attributes, e.g., generic or trade names. Also support editing medication
orders across multiple instances of an order and capturing medication orders in order sets.
処方オーダが主要な属性、例えば、同種医薬品によって分類されて、見直されるのを許容することによって作業フローを命令する効率的な薬物療法か商号をサポートしてください。また、オーダの多発性例の向こう側に処方オーダを編集して、順位セットで処方オーダの支援する。
CPS.4.2.4
1002
Function
Support for Medication
Recommendations
Statement: Offer recommendations and options in medication treatment protocols as well as
supporting medication monitoring on the basis of patient diagnosis, patient characteristics, ortherapeutic guidelines and protocols.
推薦される処置処方、また患者の症状に基づいた監視、費用、地域で採用されている医薬品、治療ガ
イドラインと規約のオプションなどを提供する。
Description: The system should list medication treatment options on the basis of practicestandards and the patient's conditions, diagnoses and characteristics (e.g., obesity, occupation).
The system may also provide prompts and notifications to support medication monitoring.
システムは処方のオプションを、実施基準(例えば、費用やガイドラインの遵守)、ジェネリック薬品、

異なる用量、異なる薬剤、薬剤なし(静観)に基づいてリストアップするべきです。検査指示のモニタ
リングを、処方オーダの影響を処方オーダ、医学的状態による指標として提案する。腎臓透析、腫瘍、移植などの治療計画の一部である一連の処方オーダの入力を促進する。
1. The system SHALL conform to function CPS.4.2.2 (Support for 1003
Patient-Specific Dosing and Warnings).
CPS.4.2.2(患者特定の投与量と警告のサポート)に準拠すること。
3. The system SHALL determine and present recommendations 1005
for alternative medication treatments on the basis of practicestandards, patient conditions and characteristics.
実施基準、費用、処方一覧、プロトコルに基づく代替薬での治療を判定し表示すること。
CPS.4.2.5
1007
Function
Support for Medication
Reconciliation
Statement: Review a patient’s medication information (from more than one source) and reconcile
conflicts.
患者の投薬情報のレビューと薬剤の再確認
Description: Medication reconciliation is the process of comparing a patient's medication
information (from all sources) to the medications that the patient is actually has been taking.
Medication reconciliation is done to avoid medication errors such as omissions, duplications,dosing errors, or drug interactions. Medication Reconciliation should be done at every episode ortransition of care in which new medications are ordered or administered, existing orders are
rewritten or where medications may influence the care given.Transitions in care include changes
in setting, service, practitioner, or level of care. The Medication Reconciliation process comprises
five includes several steps: (1) develop a list of current medication list of medications that thepatient is taking, (2) develop a list of medications to be prescribed or recommended (3) compare
the medication information from all sources; (4) make shared and informed clinical decisions basedon the comparison and provide the ability to document the interaction; and (5) communicate theupdated medication information to the healthcare teams, the patient and appropriate caregivers.
For example: If a patient’s pain, anticoagulation, hyperglycemia or other high risk therapy is being
managed by a specialist, the healthcare team must be aware to avoid prescribing an additional
equivalent of this medication.(6) Verify the patient’s/caregiver’s understanding and agreement to
the patient’s medication treatment plan.(7) Standardization of shared medication information(name, dose, instructions, indications, prescriber, etc)
薬剤の再確認は、患者の投薬情報（全てのソースからの）と実際に患者が服薬した薬剤の比較である。
薬剤の再確認は、手落ちによる薬剤の誤り、重複、用法の誤りを避ける必要がある。また、薬剤の再確認は、全てのエピソード、新しい薬剤のオーダや投与によるケアの変遷、オーダの修正および薬剤が治療に影響を与える場合に実施する必要がある。ケアにおける変遷は、環境、サービス、医療提供者やケアのレベルでの変更を含む。薬剤の再確認プロセスは、いくつかの段階を含む 5 つから成る。
(1)現在、患者が服用している薬剤のリストを明らかにする (2)処方薬剤もしくは推奨薬剤のリストを明らかにする (3)全てのソースから薬剤の情報を比較する (4) 比較に基づく臨床的な判断や相互作用の働きについて提供や通知する (5) 最新の薬剤情報を医療チーム、患者や適切な介護者へ伝達する。例えば、患者が痛みを感じた場合、抗凝固や高血糖や他のリスクの高い治療はスペシャリストにより管理され、医療チームは同等の効果がある投薬を避ける必要がある (6) 患者の服用計画に対する患者や介護者の理解や承認を確認する (7) 共有された薬剤情報を標準化する（薬剤名、投与量、指示、指標、処方者等）
1. The system SHALL provide the ability to manage the process 1008
of medication reconciliation according to scope of practice,organizational policy, and/or jurisdictional law.
慣習、組織の方針、組織の方針、管轄区域の法律の範囲で処方確認の管理機能を提供すること。
CPS.4.3
1010
Function
Supportfor
NonMedication OrderingStatement: Facilitate provider review and validation of order information to make it pertinent,effective and resource-conservative at the point of order entry.
オーダ時に、提供元レビューとオーダ情報のバリデーションを適正化、効率化、省資源化する。
Description: The system assists provider during order entry for therapies, treatments, care,diagnostics and medical supplies and equipment. Support includes, for example: alerts toduplicate orders, missing results or other information required to initiate order, suggested
corollary orders, order sets, best practice guidelines, institution-specific order guidelines andpatient diagnosis specific recommendations. Also alerts for orders that may be inappropriate orcontraindicated for specific patients, for example, X-rays on pregnant women.
療法、治療、介護、診断、医療品と医療機器のためのオーダを支援する。例えば、重複オーダに対する警告や、オーダの作成に必要とされる結果や他の情報の不足に対する警告、必然とされるオーダや
オーダセット、ベストプラクティスガイドライン、医療機関独自のオーダガイドラインや患者診断の個別の推奨の示唆である。また、特定の患者に対し不適切であったり禁忌であるオーダに対し警告する。例えば妊娠中の女性に対するレントゲン検査などがある。
1. The system SHALL determine and render, at the time of order 1011
entry, required order entry components for non-medication
orders.
オーダの入力時に、薬剤の非オーダ者に対して、オーダの入力必須項目を判断し表示すること。
2. The system SHALL render an alert at the time of order entry 1012
if a non-medication order is missing required information.
オーダ入力時に、薬剤の非オーダ者の場合に必須情報が抜けていることを表示し警告すること。
4. The system SHALL provide the ability to capture, maintain 1014
and render elapsed time parameters for purposes of duplicate
order checking.
重複オーダをチェックするため、経過期間をパラメータとして、保存、保持、表示する機能を提供すること。
。
11. The system SHALL provide the ability to manage the process 1021
of order reconciliation according to scope of practice,organizational policy, and/or jurisdictional law.
慣習、組織の方針、管轄区域の法律の範囲に従い、オーダ調整のプロセスを管理する機能を適用すること。
CPS.4.4
1022
Function
SupportOrdersfor
Diagnostic/
Screening
Tests
Statement: This function has not been defined and is captured here as a place-holder for potential
further development of the Functional Model and to maintain alignment with the corresponding
CP section.
この機能はこれまで定義されてこなかった。そして、ここでは Functional Model の潜在的な更なる発展のためのプレースホルダ―として捉えられている。
Description: None Defined at this time.
今の時点では定義されていない。
CPS.4.5
Function
Support Orders for Blood
Products and Other
Biologics

1023

Statement: This function has not been defined and is captured here as a place-holder for potential
further development of the Functional Model and to maintain alignment with the corresponding
CP section.
本機能はまだ定義されておらず、機能モデルのさらなる進歩の可能性のためにプレイスホルダーとして確保されている。
Description: None Defined at this time.

今の時点では定義されていない。
CPS.4.6
HeaderSupport for Referrals

1024

Statement: Evaluate patient information for referral indicators.
患者の保険医療情報から、紹介を評価する。
Description: The system assists with patient referrals, including prompting the provider withreferral recommendations based on the patient's medical record. When creating the referral order,
support is provided in the compilation of relevant clinical and behavioral health results,
demographic and insurance information (if available). Standardized or evidence based protocols
for workup prior to referral may also be presented.
システムは関連した臨床上や行動上の健康の実績, 人口統計学的情報や保険情報（可能であれば）の編集などで、患者の紹介を支援する。紹介前の精密検査用に、標準化されたもしくは証拠ベースのプロトコルも提示されるかもしれない。
CPS.4.6.1
1025
Function
Support for Referral
Process
Statement: Evaluate referrals within the context of a patient’s healthcare data.
患者データを評価し、特定の基準で患者紹介を推奨する。
Description: The system assists with patient referrals, including compilation of relevant clinicaland behavioral health results, demographic and insurance information (if available).
Standardized or evidence based protocols for workup prior to referral may also be presented.
システムは紹介の推薦につながりうる患者のある状態の評価を支援する。例えば、患者が禁煙スクリーニングや健康状態の評価を補助する薬を処方されている場合、禁煙カウンセリングを推奨する。
さらにシステムは他のオーダに基づく紹介も提供するかもしれない。例えばアドリアマイシンのオーダのような、心臓のマルチゲートスキャンや心エコーといった追加試験を先に完了すべきオーダで、結果として放射線科および／または循環器科への紹介が推奨されることとなる。
1. The system SHALL provide the ability to capture and render 1026
clinical and administrative data (e.g., insurance information)as part of the referral process.
紹介プロセスの一部として、臨床上のデータと管理上のデータ（例：保険情報）を保存し提示する機能を提供すること。
4. The system SHALL provide the ability to render clinical and 1029
administrative data, as well as test and procedure results to
the referred-to provider.
紹介先へ、検査と手術の結果と同様に、臨床的な管理データを提示する機能を提供すること。
5. The system SHALL provide the ability to capture and render 1030
referral orders with detail adequate for correct routing to thereferred-to provider.
紹介オーダとともに紹介医療機関への適切なルート設定に必要な詳細情報を保存し提示する機能を提供すること。
7. The system SHALL provide the ability to capture and render 1032
age appropriate data as part of the referral process according
to scope of practice. (e.g., inclusion of growth chart in pediatricreferral).
紹介プロセスの一部として、年齢に応じた情報(例：小児科の成長曲線を含む）を保存し提示する機能を提供すること。
CPS.4.6.2
1036
Function
Support for Referral
Recommendations
Statement: Evaluate patient data and recommend patient referral based on specific criteria.
EHR-S から電子的な紹介オーダの送信を可能とする。

Description: The system assists evaluation of certain patient conditions which may lead to a
recommendation for referral, for example, for smoking cessation counseling if the patient isprescribed a medication to support cessation screening or assessment for behavioral healthconditions. Additionally the system may present recommendations based on other orders – forexample, an order for Adriamycin, where additional testing such as a MUGA (heart) scan or an
Echocardiogram should be completed prior to administration, could result in a recommendedreferral to radiology, and/or cardiology.
システム上で紹介オーダが発行された時、 システムは臨床上や管理上の補足情報を含む紹介パッケージを構成し、紹介オーダを紹介先のケア提供者へ電子的に送信することができるべきである。
1. The system SHALL determine and present recommendations 1037
for potential referrals based on patient factors or guidelines
including:clinicalguidelines,
jurisdictionally-based
guidelines, patient diagnosis(es), and/or patient condition(e.g., for smoking cessation counseling if the patient smokes
cigarettes or other tobacco products or was prescribed a
medication to support smoking cessation).
患者要因やガイドライン、すなわち、臨床的なガイドライン、管轄区域のガイドライン、診断、患者の状態（例えば、禁煙を補助する薬を処方されている場合、禁煙カウンセリング）に基づき、候補となる紹介先の推奨を判断し提示すること。
CPS.4.6.3
1039
Function
Support for Electronic
Referral OrderingStatement: Enable the transmission of electronic referral orders from the EHR-S.
EHR システムから電子的な紹介オーダの送信を可能とする
Description: When a referral order is created in the system, the system should have the ability tocompose the referral package, including any supporting clinical and administrative information,and transmit the referral order to the referred-to provider electronically.
紹介オーダがシステムで作成される場合、システムは紹介パッケージと臨床的・管理的な情報のサポート、紹介先の医療提供者へ電子的に送信する紹介オーダにて構成される機能を有する必要がある。
1. The system SHALL provide the ability to export or transmit 1040
electronic referral(s) (e-referral), including all supporting
clinical and administrative information to other careprovider(s), whether internal or external to the organization.
組織内外によらず他のケア提供者に対して、全ての補助的な臨床上の情報と管理上の情報を含んだ形で紹介状を出力または電子データで送信する機能を提供すること。
3. IF the system provides the ability to capture a minimum set of 1042
required information that must be included in an e-referral to
be transmitted, THEN the system SHALL determine if theminimum set of information is satisfied prior to transmitting
an e-referral.
送信する電子的な紹介として必須情報の基本セットを保存し、送信する前に電子的な紹介として基本セットの情報を満たしているか判断する機能を提供すること。
4. IF the system provides the ability to capture a minimum set of 1043
required information that must be included in an e-referral to
be transmitted and determines that the minimum set is notsatisfied, THEN the system SHALL render prompts tocapture missing information prior to transmitting an ereferral.
送信する電子的な紹介として必須な情報の基本セットを保存し、基本セットを満たしているか判断し、電子的な紹介を送信する前に不足している情報を保存し提示する機能を提供すること。
5. The system SHALL provide the ability to capture 1044
administrative information (e.g., insurance information,consents and authorizations for disclosure) for inclusion in an
e-referral according to scope of practice, organizational policy,
and/or jurisdictional law.
慣例や組織の方針、管轄地域の法律に従うために、電子的な紹介に含めるために管理上の情報(例：保険情報、情報開示の同意書
や委任状) を保存する機能を提供すること。
6. The system SHALL provide the ability to capture clinicalinformation (e.g., medications, diagnostic results) for
inclusion in an e-referral.
電子的な紹介に含めるために臨床上の情報 (例：投薬, 診断結果) を保存する機能を提供すること。
7. The system SHALL provide the ability to present e-referrals,
including all attached information, and capture an esignature prior to transmission.
すべての付属情報を含んだ電子的な紹介を提供でき、送信前に電子署名を保存する機能を提供すること。
9. IF the system provides the ability to capture diagnosis-based
requirements for sending an e-referral based on the referredto provider's requirements, THEN the system SHALL provide
the ability to present those requirements at the time ofreferral order entry.
紹介先の医療機関の要求事項に基づき、電子的な紹介を送信するために診断情報に基づく要求事項を保存する機能を提供すること。そして、紹介オーダの入力時に、その要求事項を提示する機能を提供すること。
11. IF the system provides the ability to capture clinicalrequirements for sending an e-referral based on the referredto provider's requirements, THEN the system SHALL provide
the ability to present those requirements at the time ofreferral order entry.
紹介先の医療機関の要求事項に基づき、電子的な紹介を送信するために臨床上の要求事項を保存する機能を提供すること。そして、紹介オーダの入力時に、その要求事項を提示する機能を提供すること。
12. The system SHALL capture and render a electronic
acceptance or rejection of an e-referral request.
電子的な紹介オーダに対する電子的な受諾通知や拒否通知を保存し提示すること。
13. The system SHALL capture and render the reason for an ereferral acceptance or rejection.
電子的な紹介に対する受諾や拒否の理由を電子的に保存し提示すること。
16. The system SHALL provide the ability to amend an e-referral
order with additional information.
電子的な紹介オーダに対して、情報を修正することが可能な機能を提供すること。
CPS.5
Function
Support for Results
結果のサポート

1045

1046

1048

1050

1051

1052

1055

1058

Statement: Evaluate results and notify provider and patient of results within the context of thepatient’s healthcare data.
機能概要：結果を評価して、患者の診療データ状況の範囲内で結果を医療提供者と患者に通知する。
Description: The system suggests result interpretations and notifications including those for,abnormal results, trending of results (such as discrete laboratory values over time), evaluation of
pertinent results at the time of provider order entry (such as evaluation of laboratory results atthe time of ordering a radiology exam), evaluation of incoming results against active medication
orders.
機能説明：システムは、異常値、結果の傾向（時間の経過により異なる臨床検査値のように）、医療提供者のオーダ登録時点に適した結果の評価（放射線検査を依頼した時点での臨床検査結果の評価など）、現在の投薬に対して返って来る結果の評価を含めた結果の判断と通知を示唆する。
1. The system SHALL render alerts for a result that is outside 1059
of a normal value range.
システムは、正常値範囲外の結果に対して警告を提示しなければならない。
6. The system SHALL tag critical value results that have not been 1064
acknowledged.
システムは、承認されることのない危険な結果値に対してタグをつけなければならない。

CPS.6
HeaderSupport Treatment
治療のサポート

1068

Statement: Alert providers to potential administration errors (such as wrong patient, wrong drug,
wrong dose, wrong route and wrong time) in support of safe and accurate medication andimmunization administration and support administration workflow.
要求事項:安全で正確な投薬と薬剤予防接種と投与業務の支援における潜在的な投与エラー（誤った患者、誤った薬剤、誤った用量、誤った投与経路、誤った時間など）を提供者に警告すること。
Description: The system promotes the reduction of errors at time of administration and at the
point of care by positive patient identification, by checks on drug identification including name,dose, route and designated time of administration. Access to drug monograph information may beprovided to allow providers to check details about a drug and enhance patient education. Workflow
for administration is supported through prompts and reminders regarding the “window” for timely
administration of medications and immunizations.
機能説明：システムは薬剤名、用量、投与経路、指定時間を含む薬剤識別をチェックすることにより、投与時や看護の患者識別時のエラーの減少を促進する。薬剤の論文情報へのアクセスは、提供者に薬剤の詳細を確認するためと患者教育を向上するために提供することが許可される。薬剤や予報接種の投与業務は薬剤を適時投与するためのプロンプトやリマインダのウインドウを通じて支援される。
CPS.6.1
1069
Function
Support for Medication
Administration
投薬管理のサポート
Statement: Alert providers to potential administration errors (such as wrong patient, wrong drug,
wrong dose, wrong route and wrong time) in support of safe and accurate medication
administration and support medication administration workflow.
要求事項:安全で正確な薬剤投与と投与業務の支援における潜在的な投与エラー（誤った患者、誤った
薬剤、誤った用量、誤った投与経路、誤った時間など）を医療関係者に警告すること。
Description: The system promotes the reduction of medication errors at time of administration
and at the point of care by positive patient identification, by checks on drug identification
including name, dose, route and designated time of administration. Access to drug monographinformation may be provided to allow providers to check details about a drug and enhance patient
education. Medication administration includes the administration of medication therapies suchas chemotherapy. Workflow for medication administration is supported through prompts andreminders regarding the “window” for timely administration of medications.
機能説明：システムは薬剤名、用量、投与経路、指定時間を含む薬剤識別をチェックすることにより、投与時や看護の患者識別時のエラーの減少を促進する。薬剤の論文情報へのアクセスは、医療関係者に薬剤の詳細を確認するためと患者教育を向上するために提供することが許可される。薬剤投与は化学療法のような薬物療法も含む。薬剤投与業務は薬剤を適時投与するためのプロンプトやリマインダのウインドウを通じて支援される。
1. The system SHALL determine and render notifications 1070
regarding potential administration errors such as wrong
patient, wrong drug, wrong dose, wrong route and wrong time
as it relates to medication administration at the point of
medication administration.
システムは薬剤投薬に関連する誤った患者、誤った薬剤、誤った用量、誤った経路、誤った時間などの潜在的な投薬エラーを判定して提示しなければならない。
CPS.6.2
1079
FunctionManage Immunization
Administration
予防接種管理サポート
Statement: Alert providers to potential administration errors (such as wrong patient, wrong drug,
wrong dose, wrong route and wrong schedule) in support of safe and accurate immunization
administration and support immunization administration workflow.
要求事項:安全で正確な予防接種と予防接種業務の支援における潜在的な投与エラー（誤った患者、誤った薬剤、誤った用量、誤った投与経路、誤った時間など）を医療関係者に警告すること。
Description: The system assists in reduction of medication errors at time of administration bypositive patient identification and by checks on immunization identification. Workflow for
immunization administration is supported through prompts and reminders regarding the“window” for timely administration of immunizations.
機能説明：システムは患者識別時や予防接種識別時の投薬エラーの減少を支援する。予防接種業務は適時に予防接種するためのプロンプトやリマインダのウインドウを通じて支援される。
1. The system SHALL determine and render notifications 1080
regarding potential administration errors such as wrong
patient, wrong drug, wrong dose, wrong route and wrong time
as it relates to immunization administration at the point of
immunization administration.
システムは潜在的な投与エラーを判定して提示しなければならない。例えば薬剤投与に関連する誤った患者、誤った薬剤、
誤った用量、誤った経路、誤った時間など。
2. The system SHOULD provide the ability to link to reference 1088
information/knowledge resources at the time of immunization
administration.

CPS.6.3
Function
Support for Safe Blood
Administration
安全な血液管理サポート

3. The system SHALL determine and render potential adverse 1089
or allergic reactions (based on the patient's allergen history
and adverse reaction history) for all immunizations whenrendering immunization administration information.
システムは予防接種投与情報を表示する時に、全ての予防接種の潜在的な副作用やアレルギー反応（患者のアレルギー歴や副作用反応歴に基づくもの）を判定して提示しなければならない。
1092

Statement: Facilitate real-time checks for potential blood administration errors.
要求事項:潜在的な血液製剤の投与エラーのためのリアルタイムチェックを支援すること。
Description: To reduce errors at the time of blood product administration, the system assists inpositive patient identification, along with checks and alerts regarding the blood product to beadministered, including the identification of the blood product, the amount to be delivered, andthe route and time of the administration of the blood product.
機能説明：血液製剤投与エラーを減少するために、システムは患者識別 (PPID)に加え、血液製剤の識別を含む投与される血液製剤、運ばれる量、血液製剤投与の経路と時間に関するチェックと警告を支援する。
1. The system SHALL present, at the time of administration, 1093
information necessary to correctly identify the patient andaccurately administer blood products including patient name,blood product number, amount, route, product expiration date
and time of administration.
システムは投与時に、患者名、血液製剤番号、量、経路、製造有
効期限、投与時間などの正確な患者と精密な血液製剤同定への必要な情報を表示しなければならない。
2. The system SHALL provide the ability to capture validation 1094
of the correct matching of the patient to the blood product.
システムは血液製剤に対する患者の正確な適合検証を保存する機能を提供しなければならない。
3. The system SHALL provide the ability to capture the blood 1095
product number, amount, route and time of administration.
システムは血液製剤番号、量、経路、投与時間を保存する機能を提供しなければならない。
4. The system SHALL conform to function CP.3.2 (Manage 1096
Patient Clinical Measurements) and capture the bloodpressure, temperature, pulse and respiration rate of thepatient receiving the product.
システムは CP.3.2 （患者の臨床指標管理）の機能に適合し、血液製剤を投与される患者の血圧、体温、脈拍、呼吸数を記録しなければならない。
CPS.6.4
1097
Function
Support for Accurate
Specimen Collection
正確な検体採取サポート
Statement: Facilitate real-time checks to ensure accurate specimen collection.
要求事項：正確な検体収集を確実にするためのリアルタイムチェックを支援すること。
Description: To ensure specimen collection accuracy, the patient and specimen are positively
identified. The provider is notified in real-time of potential collection errors such as wrong patient,wrong specimen type, wrong means of collection, wrong site, and wrong date and time.
機能説明：正確な検体収集を確実にするために、患者と検体は明確に識別される（PPID）。医療関係
者は誤った患者、誤った検体、誤った収集手法、誤った部位、誤った日時のような潜在的エラーをリ
アルタイムに通知を受ける。
1. The system SHALL provide the ability to render information 1098
necessary to correctly identify the patient and accurately
identify the specimen to be collected including, but not limited
to, patient name, specimen type, specimen source, means ofcollection, date and time.
システムは患者名、検体種別、検体源、収集方法、日時などに限らず、正確な患者と精密な検体収集のために必要な情報を表示する機能を提供しなければならない。
2. The system SHALL provide the ability to determine and 1099
render variations between the type of specimen order placed
and actual specimen collected.
システムは配置された検体オーダの種類と実際に行われる検体収集の差を判定して提示する機能を提供しなければならない

3. The system SHALL provide the ability to capture the detailsof specimen collection.
システムは検体収集の詳細を保存する機能を提供しなければな
らない。
CPS.7
HeaderSupport Future Care
将来ケアサポート

1100

1102

Statement: Support for Future Care is necessary to enable the planning of future care according
to appropriate healthcare guidelines.
要求事項：将来の治療の支援は適切なヘルスケアガイドラインに関する将来の治療の計画を可能にするために必須である。
Description: Support for future care includes the provision of clinical decision support throughgiving access to healthcare guidelines from external sources.
機能説明：将来の治療の支援は、外部情報源のヘルスケアガイドラインへのアクセスを通じた臨床意
志決定支援(CDS)の提供を含む。
CPS.7.1
1103
Function
AccessHealthcare
Guidance
ヘルスケアガイダンスへのアクセス
Statement: Provide pertinent information from available evidence-based knowledge, at the pointof care, for use in healthcare decisions and care planning.
要求事項：医療上の決断と治療計画のために、治療の際に適切なエビデンスベースの知識から情報を提供すること。
Description: The information available regarding disease, disease processes, diagnostic testing,pharmaceuticals, treatment patterns and all aspects of healthcare is constantly changing. The
practitioner should be able to access a wide variety of sources that provide relevant, accurate
information about any given subject. Examples of resources include, but are not limited toevidence on treatment of specific medical conditions, maintenance of wellness, drug or device
trials, context-specific information available through online journals, printed resources such as
books and specialty organizations resources. For example, when a condition is diagnosed theprovider might be directed to relevant resources that give updated clinical research, usefulpharmaceutical combinations, surgical techniques, products or other information useful in the
management of the specific condition under consideration.
機能説明：疾病、疾患プロセス、診断テスト、医薬品、治療パターンとヘルスケアに関するあらゆる側面に関する利用可能な情報は常に変化している。医療関係者は、与えられた対象に関連する正確な情報を提供される様々な情報源にアクセスできなければならない。リソースの例としては、特定の医学的状況の治療に関するエビデンス、健康維持、薬品または機器の試験、オンラインジャーナルを通して入手できる文脈固有の情報、書籍や特定の専門機関の印刷物などを指すが、これに限らない。例
えば、病状が診断された時、医療関係者は最新の医学研究、有用な医薬品の組み合わせ、外科技術、製品、その他の検討中の特定疾患の管理に有用な情報などの関連リソースを指示してもよい。
1. The system SHALL provide the ability to render external 1104
evidence-based healthcare recommendations, including
documentation of sources.
システムは外部のドキュメントを含むエビデンスベースの提案の情報源を提示する機能を提供しなければならない。
2. The system SHALL conform to function CPS.3.3 (Support for 1107
Standard Care Plans, Guidelines, Protocols).
システムは CPS.3.3 （標準治療計画、ガイドライン、プロトコ
ル）に適合しなければならない。
CPS.8

1112

Header
SupportPatient
Education&
Communication
患者の教育とコミュニケーション支援Statement: Support for appropriate communication with the patient or the patient
representatives.
要求事項： 患者あるいは患者の代理人との適切なコミュニケーションの支援。
Description: Support for patient education and communication is critical to ensure that the patient
can appropriately participate in his care. This includes providing access to relevant patient
educational materials and reminders from internal, and/or external sources.
機能説明： 患者の教育とコミュニケーションンのサポートは患者が適切にケアに参加できることを確実にするために重要である。このサポートには内部および/あるいは外部の適切な患者教育資料やリマインダの利用を提供することを含む。
CPS.8.1
1113
Function
Patient
Knowledge
Access患者による知識へのアクセス
Statement: Provide the ability to access reliable information about wellness, disease management,
treatments, peer support groups, public health education materials, and related information thatis relevant for a specific patient.
要求事項： 健康維持活動（ウェルネス）、疾患管理（DM）、治療、ピアサポートグループ、公衆衛生
教育資料および特定の患者にとって関連する情報に関する信頼できる情報へアクセスできる機能の提供。
Description: An individual will be able to find reliable information to research a health question,
follow up from a clinical visit, identify treatment options, or other health information needs. The
information may be linked directly from entries in the health record, or may be accessed throughother means such as key word search. The information may be provided as part of the EHR system
but may also include patient information from external databases or specific websites.
機能説明： 各個人は健康に関する疑問の調査、受診後のフォローアップ、治療選択肢の確認あるいは他の健康情報ニーズのための信頼できる情報を見つけることができる。情報は健康記録中の入力データから直接リンクしても、あるいはキーワード検索のような他の方法でアクセスしてもよい。情報は EHR システムの一部として提供されることも可能であるが、外部データベースあるいは特定のウェブサイトからの患者情報を含むことも可能である。
1. The system SHALL provide the ability to determine and render 1114
information
about
wellness,diseasemanagement,
treatments, population level health measures and related
information that is relevant for a specific patient.
システムは健康維持活動（ウェルネス）、疾患管理、治療、地域レベルの健康基準値および特定の患者にとって関連する情報を決定および提示できる機能を提供できなければならない。
CPS.8.2
1118
Function
Patient
Education
Material Updates
患者教育資料のアップデートStatement: Receive and validate formatted inbound communications to facilitate, and/or perform
updating of patient education material.
要求事項： 患者教育資料のアップデートを促進および/あるいは実行するための書式化された情報の受信と検証。
Description: Materials may include information about a diagnosis, recommended diets, associatedpatient health organizations, or web links to similar educational information. These materials
may be provided electronically and may require validation prior to inclusion in the system.
機能説明： 資料には診断、推奨される食事、関連機関あるいは同様の教育情報へのウェブリンクに関する情報が含まれる。これらの資料は電子的に提供され、そしてシステムに取り込む前に検証が必要となる。
CPS.8.3
1121
Function
Patient
ReminderInformation Updates
患者へのリマインダ情報のアップデート
Statement: Receive and validate formatted inbound communications to facilitate updating ofpatient reminder information from external sources such as Cancer or Immunization Registries.
要求事項： 患者へのがんあるいは予防接種登録のような外部情報源からのリマンダ情報のアップデートを促進するための書式化された情報の受信と検証。
Description: Information from outside groups, such as immunization groups, public healthorganizations, etc. may periodically send updates to patient care providers. The system should becapable of generating patient reminders based on the recommendations of these organizations.
Patient reminders could be provided to patients by a number of means including phone calls, or
mail. A record of such reminders may become part of a patient’s record. Examples of reminders
could include a recommended immunization, prophylactic guidelines for MVP, patient self-testingfor disease, etc.
機能説明： 予防接種団体や公衆衛生組織のような外部団体化からの情報は定期的にケアプロバイダに更新情報が送られる。システムはこれらの組織からの勧告に基づいて患者へのリマインダを生成することができなければならない。患者へのリマインダは電話やメールを含む種々の方法で患者に連絡することが可能である。このようなリマインダの記録は患者情報の一部とすることができる。リマイ
ンダの例には推奨される予防接種、MVP に対する予防ガイドライン、患者の自己検査等が含まれる。
CPS.8.4
1128
Function
SupportforCommunications
Between Provider andPatient,
and/orthePatient Representative
プロバイダと患者および/または患者の代理人間のコミュニケーションのサポートStatement: Facilitate communications between providers and patients, and/or the patient
representatives.
要求事項： プロバイダと患者および/または患者の代理人間のコミュニケーションの促進。
Description: Providers are able to communicate with patients and others, capturing as specified
by the business rules the nature and content of electronic communication, or the time and detailsof other communication. Examples: - When test results arrive, the clinician may wish to email
the patient that test result was normal (details of this communication are captured).- A patient
may wish to request a refill of medication by emailing the physician.- Patients with asthma may
wish to communicate their peak flow logs/diaries to their provider.- Hospital may wish tocommunicate with selected patients about a new smoking cessation program.- Automatednotification regarding annual flu shots
機能説明： プロバイダは患者およびその他の人とビジネスルールに従って電子的コミュニケーショ
ンの性質および内容、あるいは他のコミュニケーションの時間と詳細を取り込みながら、コミュニケ

ートすることが可能である。
例：- 検査結果が到着した際、医師は患者に検査結果が正常であったとの電子メールを送ることを希望する（コミュニケーションの詳細は保存される）。
- 患者は医師に電子メールを送ることで処方箋の再発行依頼を行うことを希望する。
- ぜんそく患者は肺活量ログ/記録をケアプロバイダに連絡することを希望する。
- 病院は選ばれた患者と新しい禁煙プログラムに関してコミュニケートすることを希望する。
- インフルエンザ予防注射年報の自動通知。
1. The system SHALL provide the ability to capture and store 1129
documentation of communications between providers andpatients and/ or the patient representatives.
システムはプロバイダと患者および/または患者の代理人との間のコミュニケーション文書を取り込み保存できる機能を提供できなければならない。
2. The system SHALL provide the ability to capture scanned 1130
documents.
システムはスキャンした文書を取り込むことができる機能を提供できなければならない。
4. The system SHALL provide the ability to manage 1132
authorizations documentation for family member or patient
representative to receive patient related health information.
システムは患者に関する情報を受け取るために患者の家族ある
いは代理人に対する委任状を管理する機能を提供ことができなければならない。
11. The system SHALL provide the ability to render notifications, 1139
manually, and/or automatically, to patients for conditions andresults that require follow-up, according to scope of practice,organizational policy, and/or jurisdictional law, and to update
the patient record with the fact that this was done.
システムは業務範囲、組織ポリシーおよび/あるいは管轄区域における法律に従って、フォローアップに必要な条件や結果に対してマニュアルおよび/あるいは自動で患者に通知を出し、そして患者記録を更新して通知が出された事実を残す機能を提示することができなければならない。
12. The system SHALL provide the ability to render information 1140
(e.g., electronic, paper, CD-ROM) to patients and to update thepatient record with the fact that this was done.
システムは患者に情報（例えば、電子的、紙、CD-ROM）を提供し、そして患者記録を更新して情報が提示された事実を残す
機能を提供できなくてばならない。
CPS.8.5
1143
Function
Patient, Family andCare Giver Education
患者、家族およびケア提供者教育Statement: Facilitate access to educational or support resources pertinent to, and usable by, thepatient or patient representative.
要求事項： 患者あるいは患者の代理人に関するあるいは有益な教育あるいは支援リソースへのアクセス促進。
Description: The provider or patient is presented with a library of educational materials. Material
may be made available in the language or dialect understood by the patient or representative.
Material should be at the level of the patient or representative’s level of understanding andsensory capability. Special needs are documented. Material may be disseminated via a mode
available to and acceptable by the patient e.g., printed, electronically or otherwise. The review ofmaterial between the clinician and the patient, and the patient’s understanding of the review, isdocumented when desired by the clinician. The patient or patient’s representatives are able toobtain educational information independently without formal review with the clinician, if desired.

機能説明： ケアプロバイダあるいは患者は教育資料のライブラリーの提供を受ける。資料は患者あるいは代理人に理解できる言語や方言で利用可能である。資料は患者あるいは代理人が理解でき。認識可能なレベルでなければならない。特別なニーズは文書化されている。資料は患者が入手でき受け入れられる方法、たとえば印刷、電子的あるいはその他の方法を介して配布される。医師と患者の間での資料のレビューやレビューの患者の理解は医師が希望すれば文書化される。患者あるいは患者の代理人は希望すれば自主的に医師の正式なレビュー無しに教育情報を受け取ることができる。
1. The system SHALL provide the ability to render educational 1144
material for medication, health concerns, conditions, and/or
diagnoses.
システムは薬、健康に関する関心事・心配事、体調および/あるいは診断に対する教育資料を提示することができる機能を提供できなくてはならない。
2. The system SHALL provide the ability to render applicable 1145
educational materials to the patient, and/or patient
representative (e.g., the patient receives information aboutrisks associated with immunizations during pregnancy andthe possible side effects of the flu vaccine).
システムは患者および/あるいは患者の代理人に対して適切な教育資料を提示できる機能を提供できなくてはならない（例えば、患者が妊娠中の予防接種のリスクやインフルエンザワクチンの副作用の可能性についての情報を受け取ること）。
3. The system SHALL provide the ability to render multilingual 1146
educational material.
システムは多言語の教育資料を提示できる機能を提供できなけ
ればならない。
CPS.8.6
1155
Function
Communication
with
Personal Health Record
Systems
PHR システムとのコミュ
ニケーションStatement: Statement: Enable and manage communication between EHR Systems and PHR
Systems.
要求事項： EHR システムと PHR システム間のコミュニケーションの許可と管理。
Description: With the increasing use of Personal Health Record systems, it is necessary for the
EHR-S to appropriately communicate with the PHR to both capture patient information from the
PHR and transmit relevant portions of the EHR patient record to the PHR to support patient selfcare.
機能説明： PHR システムの利用増大に伴い、EHR システムは PHR システムから患者情報を取り込
み、また EHR の患者記録の関係する部分を PHR に転送することで患者自身によるケアを支援のた
め、PHR システムと適切にコミュニケーションすることが必要である。
1. The system SHALL provide the ability to capture and maintain 1156
documentationofcommunications
betweenproviders/providers EHR-S and the PHR-S.
システムはケアプロバイダ/プロバイダの所有する EHR システ
ムと PHR システムの間でのコミュニケーションに関する記録を取り込み、維持する機能を提供できなければならない。
3. The system SHALL provide the ability to capture 3rd party 1158
(e.g.,
familymember,authorized
representative)
authorization documentation for the receipt of healthinformation from the PHR-S.
システムは PHR システムからの健康情報の受領に対する第 3 者（例えば、家族、授権代理人）の授権確証を取り込む機能を提供できなければならない。

CPS.9HeaderSupportCare
Coordination&
Reporting
ケアの整備とレポートの
サポート

1162

Statement: Support exchange and reporting of information between participants in patientcentered care.
機能概要：患者を主体と捉える診療の中で、関係者間の情報交換と報告を支援する。
Description: Provide the support necessary to ensure that appropriate communication between
providers is possible to coordinate the patient's care including, clinical communication between
providers, standard and ad-hoc reporting and information views of the patient record.
機能説明：患者の記録における通常や特別な報告と情報の表示など、医療提供者の間での診療情報の交換を含め、医療提供者同士の適切なコミュニケーションが患者に対する診療の調整を確実に可能とするために必要となる支援を提供する。
CPS.9.1
1163
Function
Clinical Communication
Management
andSupport臨床の場でのコミュニケ
ーション管理とサポート
Statement: Support exchange of information between participants in patient-centered care asneeded, and the appropriate documentation of such exchanges. Support secure communication toprotect the privacy of information as required by jurisdictional law.
機能概要：患者を主体と捉える診療の中で、必要に応じて関係者間の情報交換と、そのための適切な文書化を支援する。管轄区域の法律の必要に応じて、プライバシー保護のために安全なやり取りを支援する。
Description: Healthcare requires secure communications among various participant in thepatient's circle of care: patients, doctors, nurses, chronic disease care managers, public healthauthorities, pharmacies, laboratories, payers, consultants etc. An effective EHRS supports
communication across all relevant participants, reduces the overhead and costs of healthcarerelated communications, and provides automatic tracking and reporting. The list ofcommunication participants is determined by the care setting and may change over time.Becauseof concerns about scalability of the specification over time, communication participants for all caresettings or across care settings are not enumerated here because it would limit the possibilities
available to each care setting and implementation. However, communication between providers
and between patients and providers will be supported in all appropriate care settings and acrosscare settings. Implementation of the EHRS enables new and more effective channels ofcommunication, significantly improving efficiency and patient care. The communication functionsof the EHRS changes the way participants collaborate and distribute the work of patient care.
機能説明：医療は、患者、医師、看護師、慢性疾患ケアマネージャー、公衆衛生当局、薬局、研究所、費用支払者（国）、コンサルタントなど様々な関係者の間で安全なやり取りを必要とする。効果的なEHR システムは、関連する全ての関係者における情報交換を支援し、諸経費や医療に関連する通信費を削減し、自動で進捗管理と報告を行う機能を提供する。関係者における情報交換の内容は、治療(中)により決定され時間とともに変わるかも知れない。規格は時間とともに変化する懸念があり、全ての治療における関係者や関連する関係者の情報交換には、それぞれの治療と（システムの）実装の可能性に限界があるため、本項で列挙はしない。しかし、医療提供者同士の情報交換や、患者と医療提供者における情報伝達は、全ての適切な治療または関連する治療を支援する。EHR システムの実
装は、新しくより効果のある情報伝達手段となり、（業務の）効率と患者への診療（の質）を大幅に向上させる。EHR システムにおける情報伝達機能は、関係者の連携手段を変更し診療業務を浸透させる。
CPS.9.2
1168

Function
SupportforInterProvider
Communication
医療提供者間コミュニケーションのサポート
Statement: Support exchange of information between providers as part of the patient care process,and the appropriate documentation of such exchanges. Support secure communication to protect
the privacy of information as required by jurisdictional law.
機能概要：患者への診療行為の一環として医療提供者同士の情報交換と、そのための適切な文書化を支援する。管轄区域の法律の必要に応じて、プライバシー保護のために安全なやり取りを支援する。
Description: Communication among providers involved in the care process can range from realtime communication (for example, communication between a therapist and nurse), to
asynchronous communication (e.g., consult reports between physicians). Some forms of interpractitioner communication will be paper based and the EHR-S must be able to produce
appropriate documents.The system should provide for both verbal and written communication.
These exchanges would include but not be limited to consults, and referrals as well as possible
exchanges within the office as part of the provision and administration of patient care (e.g., thecommunication of new information obtained within the office environment during the process ofadministration of a tetanus shot while the patient is in the exam room).The system should support
the creation and acceptance of paper artifacts where appropriate.
機能説明：診療行為に関係する医療提供者間の情報交換は、即時のやり取り（療法士と看護師のやり取りなど）から非同期のやり取り（医師間の診断報告など）に及ぶことができる。医師同士のやり取りの形式のうち、いくつかは書類に基づいており、EHR システムは適切な文書を作成できなくてはならない。システムは、口頭でのやり取りと書面でのやり取りの両方のために提供すべきである。こ
れらの情報交換は、診療行為の提供と管理の一環として、診察室内での情報交換が可能であるように診察や（データ）照会を含めるが、これらに制限はされない。
（診察室で患者が破傷風の予防接種投与
中に、診察室の周囲で得られる新たな情報の伝達など）システムは、必要に応じて書類の作成と承諾を支援すべきである。
1. The system SHALL provide the ability to capture and store in 1169
the patient record verbal/telephone communication(including verbal orders) between providers including theidentification of these providers.
システムは、医療提供者同士の識別を含め患者に関する口頭／
電話でのやり取り（口頭でのオーダ指示含む）を保存し記録する機能を提供しなければならない
2. The system SHALL provide the ability to integrate scanned 1170
documents from providers into the patient record.
システムは、医療提供者からのスキャン文書を患者記録にまとめる機能を提供しなければならない。
5. The system SHALL provide the ability to transmit (e.g., via e- 1173
mail) specific patient data (e.g.reports, results, documents) toalternate providers/facilities in an emergency care context.
システムは、救急治療の状況において、互いの医療提供者／施設に対し、特定の患者情報（報告書、検査結果、文書など）を伝達する（電子メール経由など）機能を提供しなければならない。
CPS.9.2.1
1182
FunctionManageConsultation
Requests and Responses
診療依頼と返答の管理
Statement: Provide a means to capture and manage requests for consultation and responses.
機能概要：診察依頼と返答の保存手段と管理手段を提供する
Description: EHR system should support the ability to document and note calls made tophysician/provider consultants, as well as their responses. This includes the time of the initial andany subsequent pages or calls, the time and method whereby the consultant responded, as well as
the final disposition of the consultation.
機能説明：EHR システムは、医師／専門医の返答だけでなく、文書やメモで要求する機能を支援すべきである。これは、診察の最終処置だけでなく、最初や以降の記録や要求の経過、専門医の返答の経過や手法を含める。
1. The system SHALL provide the ability to capture and 1183
maintain records of consultations by providers other than theattending provider.
システムは、担当の医療提供者以外による診察記録を保存や管理する機能を提供しなければならない。
CPS.9.2.2
1190
Function
Support for Provider toProfessional
Communication
医療提供者と専門家間コ
ミュニケーション管理
Statement: Manage communications to professionals (e.g., coroners, medical examiners, law
enforcement) for health care events.
機能概要：健康管理上の事象における専門家（検死官、監察医、警察など）とのやり取りを管理する
Description: Health care providers must be able to provide notifications and associatedadministrative, and/or clinical information to various professional individuals or organizations ofspecific health care events (e.g., patient deaths, births, gunshot wounds) in order to promote or
trigger a workflow.
機能説明：ワークフローの促進やきっかけのために、医療提供者は、届出と行政または特別な健康管理上の事象（患者の死亡、出生、銃創など）における様々な専門家や専門組織の診療情報を関連付けることが出来なければならない。
CPS.9.2.3
1196
Function
Support for Provider Pharmacy
Communication
医療提供者と薬局間コミュニケーションサポート
Statement: Provide features to enable secure bi-directional communication of informationelectronically between practitioners and pharmacies or between practitioner and intended
recipient of pharmacy orders.
機能概要：医師と薬局、または医師と薬局における依頼の受領者との間で、電子的な双方向の情報のやり取りを安全に実現する特徴を提供する。
Description: When a medication is prescribed, the order is routed to the pharmacy or otherintended recipient of pharmacy orders. This information is used to avoid transcription errors andfacilitate detection of potential adverse reactions. If there is a question from the pharmacy, that
communication can be presented to the provider with their other tasks. In certain environments,
medication order creation is a collaborative process involving the prescriber and facility staff.
Accordingly, this function applies to communication process between the prescriber, facility andthe pharmacy or other intended recipient of pharmacy orders. The transmission of prescription
data between systems should conform to realm acceptable messaging standards. Informative
examples:- HL7 Clinical Document Architecture Release 2- ISO/EN 13606 Electronic Health
Record Communication- CEN ENV 13607:2000. Health informatics. Messages for the exchange of
information on medicine prescriptions- X12N healthcare transactions- US realm: National Council
for Prescription Drug Programs (NCPDP)- Canadian realm: National Electronic Claims Standard(NeCST)
機能説明：投薬が処方されるとき、依頼は薬局または薬局における依頼の他の受領者に送られる。この情報は、転記誤りを回避し、起こり得る副作用の発見を促進するために用いられる。薬局からの疑義照会がある場合、その情報のやり取りは医療提供者に別な課題を示される。特定の環境では、投薬指示の作成は、処方者と施設の職員が関与する共同の処置である。従って、この機能は処方者、施設と薬局、または薬局における依頼の他の受領者の間の情報伝達方法に適用する。システム間の処方データの伝送は、認められた通信規格の範囲に従うべきである。参考例：- HL7 Clinical Document
Architecture Release 2- ISO/EN 13606 Electronic Health Record Communication- CEN ENV
13607:2000.Health informatics. Messages for the exchange of information on medicine
prescriptions- X12N healthcare transactions- US realm: National Council for Prescription Drug
Programs (NCPDP)- Canadian realm: National Electronic Claims Standard (NeCST)
1. The system SHALL conform to function CP.4.2 (Manage 1197
Medication Orders) and provide the ability to transmit
medication orders.
システムは、機能 CP.4.2（Manage Medication Orders）に従い、投薬指示を送る機能を提供しなければならない。
2. The system SHALL provide the prescriber/provider with the 1198
ability to electronically transmit orders, prescriptions,eligibility inquiries, acknowledgements and renewal
responses to the pharmacy, as necessary, to initiate, change,or renew a medication order.
システムは、必要に応じて投薬指示の新規、修正、差し替えのために指示内容、処方箋、保険加入資格照会、薬局への承認と更新の返答を電子的に送る機能がある処方者／医療提供者を提供しなければならない。
3. The system SHALL provide the ability to receive any 1199
acknowledgements, prior authorizations, renewals, inquiries
and fill notifications provided by the pharmacy or otherparticipants in the electronic prescription process.
システムは、薬局または電子的な投薬の過程における他の関係者により提供されるあらゆる承認、事前の認可、更新、照会と記載された通知を受け取る機能を提供しなければならない。
6. The system SHALL provide the ability to receive and transmit 1202
secure real-time messages or services.
システムは、安全な即時のメッセージまたはサービスを送受信する機能を提供しなければならない。
CPS.9.3
1207
Function
Health Record Output
健康記録の出力Statement: Support the definition of the formal health record, a partial record for referralpurposes, or sets of records for other necessary disclosure purposes.
機能概要：正式な診療録の定義、照会を目的とした部分的な記録、他に必要となる開示を目的とした記録の準備を支援する。
Description: Provide hardcopy and electronic output that fully chronicles the healthcare process,supports selection of specific sections of the health record, and allows healthcare organizations todefine the report, and/or documents that will comprise the formal health record for disclosure
purposes. A mechanism should be provided for both chronological and specified record element
output. This may include defined reporting groups (i.e. print sets). For example Print Set A =Patient Demographics, History & Physical, Consultation Reports, and Discharge Summaries.
Print Set B = all information created by one caregiver. Print Set C = all information from a
specified encounter. An auditable record of these requests and associated exports may be
maintained by the system. This record could be implemented in any way that would allow thewho, what, why and when of a request and export to be recoverable for review. The system has thecapability of providing a report or accounting of disclosures by patient that meets in accordancewith scope of practice, organizational policy, and jurisdictional law.
機能説明：診療経過の詳細な時系列としての記録、診療録の特定部分における選択の支援、そして報告書または開示を目的とした正式な診療録からなる文書を医療機関が定義することを可能とするハードコピーや電子的な出力を提供する。仕組みは、時系列で特定された記録項目の出力を提供すべきである。これは、定義された報告書群を含めても良い（すなわち印刷セット）例えば、 印刷セット

Ａ＝患者基本情報、病歴と診察歴、診断報告、そして退院サマリ 印刷セットＢ＝一人の介護者（担当者）により作成される全ての情報 印刷セットＣ＝特定の受療における全ての情報 これらの要求と関連する出力結果を監査できる記録は、システムによって管理されても良い。この記録は、監査のために要求と出力結果において、誰が、何を、なぜ、そしていつを考慮した様々な方法により実装される。システムは、業務範囲、組織ポリシー、そして管轄区域の法律に従った、患者に対する報告または開示説明を提供する能力がある。
1. The system SHALL provide the ability to render reports 1208
consisting of all and part of an individual patient's record
according to scope of practice, organizational policy, and/or
jurisdictional law.
システムは、業務範囲、組織ポリシー、または管轄区域の法律に準拠して個々の患者の全ての記録や一部の記録からなる報告書を提示する機能を提供しなければならない。
6. The system SHALL provide the ability to render patient 1213
identifying information on each page of reports (i.e., hard copy
and electronic) according to organizational policy, and/or
jurisdictional law.
システムは、組織ポリシー、または管轄区域の法律に準拠して報告書におけるそれぞれの記載（すなわちハードコピーと電子情報）について患者を識別する情報を提示する機能を提供しなければならない。
9. The system SHALL provide the ability to manage-data- 1216
visibility [hide or redact] (remove from view, and/or output)
data elements or portions of a report to prevent a given
recipient from seeing certain data according to organizational
policy, and/or jurisdictional law.
システムは、組織ポリシー、または管轄区域の法律に準拠して所定の受領者が特定のデータを閲覧することを防ぐために、データ項目または報告の一部の表示制御機能［非表示または編集］（表示対象外または出力対象外）を提供しなければならない。
CPS.9.4
1223
FunctionStandard
ReportGeneration
標準的なレポートの作成
Statement: Provide report generation features using tools internal or external to the system, forthe generation of standard reports.
機能概要：標準的な報告書作成のために、システム内またはシステム外のツールを用いた報告書作成機能を提供する。
Description: Providers and administrators need access to data in the EHR-S for clinical,
administrative, financial decision-making, audit trail and metadata reporting, as well as to create
reports for patients. Many systems may use internal or external reporting tools to accomplish this.
Reports may be based on structured data, and/or unstructured text from the patient's healthrecord.Users need to be able to sort, and/or filter reports. For example:-the user may wish to view
only the diabetic patients on a report listing patients and diagnoses-the user may wish to view
only male patients over 35 with a complaint of chest pain.
機能説明：医療提供者と管理者は、患者に対する報告書を作成するだけでなく、臨床、管理、財務上の決定、監査証跡とメタデータ（付加データ）報告のために、EHR システム内のデータを利用する必要がある。このことを達成するために、多くのシステムはシステム内またはシステム外の報告書ツールを使用するかも知れない。報告書は、患者の診療録における構造化されたデータ、または構造化されていないテキストに基づいても良い。ユーザは、報告の並び替えまたは選別が行えることが必要となる。例：ユーザは、患者と診断結果を一覧化した報告書において、糖尿病患者のみの参照を望むかも知れない。ユーザは、胸の痛みに対する症状がある 35 歳以上の男性患者のみの参照を望むかも知れない。
CPS.9.5
1233
Function
Ad Hoc Query andRendering
任意の問合せと返答
Statement: Provide support for ad hoc query and report generation using tools internal or external
to the system. Present customized views and summarized information from a patient's
comprehensive EHR subject to jurisdictional laws and organizational policies related to privacy
and confidentiality. The view may be arranged chronologically, by problem, or other parameters,
and may be filtered or sorted.
機能概要：システム内またはシステム外のツールを用いて任意の問合せやレポート生成の支援を提供する。プライバシーと機密保持に関連した管轄区域の法律と組織ポリシーを前提として患者の包括的な電子診療録よりカスタマイズされた表示と要約した情報を提供する。表示は問題点または他のパラメータにより時系列に並べられても良く、抽出または並び替えられても良い。
Description: Providers and administrators need to respond quickly to new requirements for datameasurement and analysis. This may be as a result of new regulatory requirements or internalrequirements. This requires that users be able to define their own query parameters and retain
them. The data may be found in both structured and unstructured data. Providers andadministrators also need to query for the absence of specific clinical or administrative data. For
example, the Quality Control department may be reviewing whether or not the protocol for
management of Diabetes Mellitus is being followed. If the protocol calls for fasting blood sugars
every 3 months at minimum, the investigator might need to run an across-patient query locating
patients with diabetes who do not show an FBS result within the last 3 months. Emergency
Department benchmarking reports - Key point of time include arrival time; treatment area
entrance time, MD contact time; decision to admit, discharge or transfer time; and departure (leftED) time. Important intervals include, but are not limited to the “door to doctor time”, “doctor todiction time”, “admission to bed availability or departure” as well as overall length of stayA key
feature of an electronic health record is its ability to support the delivery of care by enabling priorinformation to be found and meaningfully displayed. EHR systems should facilitate search,filtering (e.g., filtering by key word, tagged data, or diagnosis), summarization, and presentationof available data needed for patient care. Systems should enable views to be customized, forexample, specific data may be organized chronologically, by clinical category, by consultant,depending on need. The views may be arranged chronologically, by problem, or other parameters,
and may be filtered or sorted. Jurisdictional laws and organizational policies that prohibit certain
users from accessing certain patient information must be supported.
機能説明：医療提供者と管理者は、データの指標や分析のための新たな要求事項に対して迅速な応答を必要とする。これは、新たな規制の要求事項または内部の要求事項の結果としてあるかも知れない。
これは、ユーザが問合せパラメータの定義と保持することを必要とする。データは、構造化や非構造化の両方があっても良い。医療提供者と管理者においても、特定の臨床データまたは管理データの欠損のために問合せが必要となる。例えば、品質管理部門は糖尿病管理のためのプロトコルに準拠しているかどうかを監査するかも知れない。プロトコルが最低限３ヶ月ごとに空腹時血糖値（の測定）を求めていた場合、臨床研究者は過去３ヶ月以内で空腹時血糖値の結果のない糖尿病患者を特定するために全患者にわたり問合せを実行するかも知れない。救急部門のベンチマーク報告 － 時間の経過における重要点は、到着時間、処置室への入室時間や医師の診察時間、入院、退院または移入の確定
時間、退去（救急部門を去った）時間を含む重要な（時間の）間隔は含めるが、全体の（院内の）滞在期間だけでなく”到着から治療までの時間”、”治療から指示までの時間”、”有効なベッドへの入院
または退去”には限定されない。電子診療録の重要な特徴は、過去の情報を探して有意義な表示を可能とすることで、診療提供を支援することである。EHR システムは、検索、抽出（例えばキーワー
ド、タグ付データまたは診断結果による抽出）、要約そして患者の診療に必要となる入手可能なデー
タの提示を容易に行うべきである。例えば、特定のデータを時系列にまとめるように、診療部門によって、 専門医によってなど、必要に応じて表示をカスタマイズできるべきである。表示は問題点または他のパラメータにより時系列に並べられても良く、抽出または並び替えられても良い。特定ユーザ
が特定患者の情報を利用することを禁じる管轄区域の法律と組織ポリシーは、維持されなければならない。
11. The system SHALL support the ability for a provider to 1244
capture and maintain filters to search for previous events(e.g., encounters, reports, consults) meeting specified criteria.
システムは、指定された抽出条件を満たした以前の出来事（例
えば、受療、報告、診断）を検索するために、抽出結果を保存し管理する医療提供者のための機能を支援しなければならない
CPS.9.61245

Function
Information View
情報の表示Statement: Support user-defined information views.
機能概要：ユーザ定義の情報表示を支援する
Description: Views of the information can be tailored for or by the user (or department or "jobclassification”) for their presentation preferences, within local or facility established rules. For
example, a nursing supervisor may elect or prefer to see summary data on all patients as thedefault view.
機能説明：情報の表示は、地域または施設が定めた規則の範囲内で、ユーザ（または部門または”職種”）の示した優先度に従って、合わせることが出来る。例えば、看護師長は初期表示として全患者の一覧を見ることを選択または優先するかも知れない。
CPS.10FunctionManage User Help
ユーザヘルプの管理

1251

Statement: Support the ability to manage the configuration, and/or customization of appropriate
user help that is context sensitive and may include the exchange of live online chat.
要求事項： ライブのオンラインチャットによる情報交換を含む状況に応じた適切なユーザヘルプの設定および/またはカスタマイズを管理する機能のサポート。
Description: Throughout the system it is necessary to provide configurable, context sensitive,
and/or searchable user help to assist in the use of the system. User help levels should be
configurable based on user requirements, scope of practice, organizational policy, and/or
jurisdictional law. User Help may include the live online chat support.
機能説明： システム全体を通してシステムの利用を支援するための、設定可能で、状況に応じたそして/あるいは検索可能なユーザヘルプを提供することが必要である。ユーザヘルプのレベルはユー
ザの要望、業務範囲、組織ポリシーおよび/あるいは管轄区域における法律に従って設定可能でなければならない。ユーザヘルプにはライブのオンラインチャットによる情報交換を含むことができる。
4. Administration Support Section
Section/id#：
Type:
Name:
AS.1
HeaderManageProviderInformation
医療関係者情報の管理

Conformance Criteria

Row#
1388

Statement: Maintain, or provide access to, current provider information.
Description: Manage the information regarding providers within and external to an organizationthat is required to support care provision. This information includes a registry of providers(internal to the EHR-S or external), the provider's location, on-call information, and office
information. Information regarding teams or groups of providers as well as individual patient
relationships with providers is necessary to support care coordination and access to patient
information
機能概要：現行医療提供者の情報を提供し、維持すること。
機能説明：当該医療関係者に関する情報を管理すること。情報には、以下のものが含まれる。EHR シ

Section/id#：
Type:
Conformance Criteria
Row#
Name:
ステムに関連する（内部、外部関わらず）システム会社の記録、システム会社の所在地、オンコール情報、
および会社情報。患者情報へのアクセス、医療コーディネートのサポートのために必要とされる以下の情報。当該医療提供者と関係のある患者個人の情報、当該医療提供者の組織に関する情報。
AS.1.1
1389
Function
機能
ManageProviderRegistry or Directory
医療提供者の登録・記録情報の管理Statement: Provide a current registry or directory of practitioners that contains data needed todetermine levels of access required by the system.
Description: Provider information may include any credentials, certifications, or any otherinformation that may be used to verify that a practitioner is permitted to use or access authorized
data.
機能概要：当該システムにアクセスできる能力を有するか判断するために、技術担当者の直近の登録・ディレクトリを提供すること。
機能説明：医療提供者の情報には、認証資格等を含むこと、もしくは、機密データの使用・当該デー
タにアクセスする権限を持つに資するかを証明する情報を提供すること。
3. The system SHALL provide the ability to capture and 1392
maintain the role of each provider associated with a patient(e.g., encounter provider, primary care provider, attending,resident, or consultant).
3.当該システムは、患者に関係する各々のシステムの情報を取得
し、維持できるような機能を提供しなければならない（例えば、外来診療受療関係者、プライマリーケア医療提供者、主治医、研修医、コンサルタント）。
7. IF TI.3 (Registry and Directory Services) is implemented, 1396
THEN the system SHALL conform to function TI.3 andprovide the ability to use registries or directories to uniquely
identify provider for the provision of care.
7. TI.3（レジストリ及びディレクトリサービス）が実装されている場合、システムは TI.3 機能に当然に適合し、医療ケアのために、その他のシステムが T.I3 規格に準じたレジストリやディレクトリを使用できる機能を当然に適合しなければならない。
AS.1.2
1399
FunctionManageProvider'sLocation Within Facility
施設内医療提供者の管理Statement: Provide provider location or contact information on a facility's premises.
Description: The identification of provider’s location within a facility may facilitate the handlingof critical care situations. This may include the location of on site practitioners by name orimmediate required specialty. A real-time tracking system may provide automatic update of suchinformation.
機能概要：施設内医療提供者の場所、連絡方法を提供すること
機能説明：施設内に医療提供者が駐在していることは、緊急時の対応時に望ましい。これには、名前
または緊急専門の現場医師の場所も含む。リアルタイム追跡システムにすることで、情報の自動更新の提供が考えられる。
AS.1.31402

Section/id#：
Type:
Name:
Function
Provider'sOn
Call
Location
医療提供者のオンコール
時の所在地

Conformance Criteria

Row#

Statement: Provide provider location or contact information when on call.
Description: The provider immediate contact information. This may include on call practitioners
on a facility’s premises as well as on call contact information (e.g., phone number, pager, cell phone,etc.) after scheduled working hours.
機能概要：オンコール時の医療提供者の場所、もしくは、連絡先情報を提供すること。
機能説明：医療提供者の緊急連絡先情報。これは、施設内の待機中の医師だけでなく、所定労働時間後の待機連絡先情報（例えば、電話番号、ポケットベル、携帯電話など）が考えられる。
AS.1.41404
FunctionManageProvider'sLocation(s) or Office(s)医療提供者の所在地の管理Statement: Provide locations or facility contact information for the provider in order to direct
patients or queries.
Description: Providers may have multiple locations or offices where they practice. The systemshould maintain information on the primary location, any secondary locations, as well as thescheduled hours at each location. Information maintained may include web sites, maps, officelocations, etc.
機能概要：患者や問い合わせに対応する医療提供者の所在地や連絡先を提供すること。
機能説明：医療提供者が実務を行う場所は、複数事業所でもよい。一次対応、二次対応、または、どの事業所がどの時間に対応するのかといった情報を維持すべきである。その情報はウェブサイト、地図、会社所在地等を含むことが考えられる。
AS.1.51407
Function
Team/Group of Providers
Registry or Directory
医療提供者の登録もしくは記録Statement: Provide access to a current directory, registry or repository of information on teams orgroups of providers according to scope of practice, organizational policy, and/or jurisdictional law.
Description: An organization may assign caregivers to teams that need to be registered as such.
In another scenario, an organization might contract with a group of providers. The group would
be listed by the group name or individually or both. A caregiver might be part of more than one
team or group. All of these factors need to be supported. Information includes, but is not limited
to: full name, address or physical location, and a 24x7 telecommunications address (e.g., a phoneor pager access number).
機能概要：診療範囲、組織の方針、管轄法律に沿った医療提供者に関する詳細な情報へのアクセスを提供すること。
機能説明：医療提供者は、医療従事スタッフをシステム担当のチームに任命してもよい。または、医療機関は、複数の医療提供者グループと契約してもよい。その際は、個人名もしくは会社名をリスト化すること。医療従事スタッフは、複数のチームやグループを兼務する場合がある。上記のすべてがサポートされる必要がある。以下に限定されないが、そのための情報は以下の情報を含むものとする。

Section/id#：
Type:
Conformance Criteria
Row#
Name:
フルネーム、住所または物理的な位置、および 24 時間 365 日の電気通信アドレス（例えば、電話またはポケットベル）等。
4. The system SHALL provide the ability to tag the role of each 1411
provider associated with a patient (e.g., encounter provider,primary care provider, attending, resident, or consultant)
4. 当該システムは、患者に関連する各システムの情報にタグ付けする機能を当然に有しなければならない。（例えば、外来診療
受療関係者、プライマリーケア医療提供者、主治医、研修医、コンサルタント）
AS.1.61414
Function
Provider Caseload/Panel
医療提供者の実績/パネル
Statement: Provide access to a provider's caseload or panel information.
Description: An organization might employ the concept of caseload or panel of patients to facilitatecontinuity of care and distribution of work. A caregiver may have, or be accountable for, one ormore defined caseloads or panels of members/patient/clients within the organization. Information
about a caseload or panel may include an indication that an opening is available on a certain
caseload or an indication that a certain patient is not suitable for that caseload. A member/patient
may be provided access to a listing of caregivers with open caseloads or panels to select a provider.
機能概要：医療機関の実施件数、実績情報を提供すること
機能説明：治療の連続性、医療の機能分化を容易にするため、医療提供者においては、実施件数、実績の公開という考え方を採用することが考えられる。医療従事者は、医療機関内における定義された実施件数・実績を一つ以上有し、もしくは、説明できると考えられる。実施件数、実績情報には、あるケースにおいて有意義と示唆すること、もしくは、ある患者にとっては適切ではないと示唆することも含めてよい。会員/患者が医療提供者を選択できるように、医療従事スタッフの実施件数・実績の公開一覧を提供することも考えられる。
1. The system SHALL provide the ability to manage a provider's 1415
caseload or panel information according to scope of practice,organizational policy, and/or jurisdictional law.
1. 当該システムは、医療提供者の診療範囲、組織ポリシー、管轄区域法律に沿った実施件数・実績情報を管理する機能を当然に有しなければならない。
AS.1.71417
FunctionManagePractitioner/Patient
Relationships
開業医と患者の関係の管理Statement: Identify relationships among providers treating a single patient, and provide theability to manage patient lists assigned to a particular provider.
Description: This function addresses the ability to manage current information about therelationships between providers and the patients. This information should be able to flow
seamlessly between the different components of the system, and between the EHR system andother systems. Business rules may be reflected in the presentation of, and the access to thisinformation. The relationship among providers treating a single patient will include any necessary
chain of authority/responsibility. Example: -In a care setting with multiple providers, where thepatient can only see certain kinds of providers (or an individual provider); allow the selection of
only the appropriate providers.-The user is presented with a list of people assigned to a given
practitioner and may alter the assignment as required to a group, to another individual or bysharing the assignment.
機能概要：一人の患者を取り扱っている医療提供者同士の関係を明確にすること、当該医療提供者がSection/id#：
Type:
Conformance CriteriaName:
所管している患者のリストを管理する機能を有すること。

Row#

機能説明：この機能は、患者と医療提供者との関連についての直近情報を管理するものである。この情報は、ＥＨＲシステムと他のシステム間、システム内の異なるコンポーネント間でシームレスに流れるべきである。情報へのアクセス、情報公開には、業務ルールが反映されることが考えられる。患者を取り扱っている医療提供者同士は、必要な範囲での連鎖責任を含む。例えば、複数の医療提供者に関連があり治療中の場合、患者は特定の医療提供者（もしくは個人の医療提供者）しかわからない状態である。それを適切な医療提供者を選択できるようにするものである。患者は開業医のリストを閲覧でき、そのユーザは担当者を他の個人に変えたり、一部を他に任せるということをしてもよい。
1. The system SHALL provide the ability to extract the 1418
information needed to identify all providers by nameassociated with a specific patient encounter.
1. システムは、特定の患者の外来受療に関連付けられた名前によってすべての医療提供者を識別するために必要な情報を抽出する能力を提供しなければなりません。
2. The system SHALL provide the ability to tag the role of each 1419
provider associated with a patient (e.g., encounter provider,primary care provider, attending, resident, or consultant).
2. 当該システムは、患者に関連する各システムの情報にタグ付けする機能を当然に有しなければならない（例えば、外来診療受療関係者、プライマリーケア医療提供者、主治医、研修医、コンサルタント）4. The system SHALL provide the ability to identify providers 1421
who have been associated with any encounter for a specificpatient (i.e., all the providers who have had any encounter
with the patient over time).
4. システムは、特定の患者の外来受療と関連つけられている医療提供者を特定する機能を当然に有しなければならない（すなわ
ち、過去から現在までの期間に当該患者歴があるすべての受療機関）。
8. The system SHALL provide the ability to tag primary or 1425
principal provider(s) responsible for the care of a patient
within a care setting.
8. システムは、治療の範囲内で患者に責任を持つ受療機関に、優先タグもしくは主要タグ医療提供者をつける機能を当然に有しなければならない。
AS.1.8Function
Support for Provider
Credentialing
医療提供者の資格認定のサポート
Statement: Manage Provider Credentialing Information
Description: Maintaining credentials, certifications, and other information is relevant for records
management and evidentiary support because it establishes users and clinical personnel who are
involved in patient care/encounter and supports the access control process.
機能概要：医療提供者の資格認定情報の管理
機能説明：患者のケアを行っているユーザ、臨床士を保証し、かつ、アクセスコントロールの信頼性を確立するために、資格認定、証明書、その他関連の情報を受療記録管理や証明書等により明確にし、維持すること。
1. The system SHALL provide the ability to capture and render 1349
information on clinician credentialing and privileging
requirements, as defined by the applicable professional andgoverning organizations, according to scope of practice,organizational policy, and/or jurisdictional law.

Section/id#：
Type:
Name:

Conformance Criteria

Row#

1. 当該システムは、受療範囲、組織ポリシー、管轄区域法律に従って、適切な担当専門的な管理組織や政府機関によって定義された臨床家の認証、特権要件に関する情報を取得し、提示する機能を提供しなければならない。
AS.2
FunctionManagePatient
Demographics, Locationand Synchronization
患者基本情報、
場所と同期
の管理

1427

Statement: Capture and management of patient administrative information across locations inorder to support care, including directories, and/or registries.
機能概要：ディレクトリおよびまたはレジストリを含め、診療をサポートするために場所をまたがった患者の事務的情報の管理と保存
Description: A patient directory/registry may contain information including, but not limited to:full name, residence or physical location, alternate contact person, primary phone number, andrelevant health status information. Various views of Patient Registry or Directory information
may constructed to accommodate various user's needs. Examples of specific directory views arepresented in the following functions. The patient administrative information also includes patient
location information (within a facility as well as home care location(s)); as well as the patient's
registration in healthcare programs.
機能説明：患者のディレクトリ／レジストリは以下を含むが限定しなくても差支えない。：フルネー
ム、住居または在籍場所、代理の連絡先、主要な電話番号、そして関連した健康状態の情報。患者のレジストリまたはディレクトリの情報の様々な表示は、様々なユーザの要求をかなえるために作成されても差支えない。特定のディレクトリの表示例は、以下の機能で示されます。患者のヘルスケアプ
ログラム登録と同様に、患者の管理情報は患者の位置情報も含む（施設ならびに在宅ケア）
AS.2.1
1432
Function
Synchronize
Patient
Demographic Data
患者基本情報データの同期Statement: Support interactions with other systems, applications, and modules to enable themaintenance of updated demographic information in accordance with realm-specificrecordkeeping requirements.
機能概要：分野特有の記録要件に従い、更新された基本情報の維持管理を実現するための他システム、
アプリケーション、そしてモジュールとのやり取りを支援する
Description: The minimum demographic data set must include the data required by realm-specificlaws governing health care transactions and reporting. For example, this may include data input
of death status information, or may include support to identify multiple names, such as updatingfrom Baby Girl Doe, to neonate's given name.
機能説明：最低限の基本情報データとして、医療の処置と報告を定める分野特有の法律に要求されるデータを含めなくてはならない。例えば、死亡状態情報のデータ入力、または新生児の名前を仮名から更新するように複数の名前の識別を支援することを含む場合がある。
1. The system SHALL provide the ability to capture and 1433
harmonize patient demographic information throughinteraction with other systems, applications, and modules
according to scope of practice, organizational policy, and/or
jurisdictional law.

1. システムは、業務範囲、組織ポリシー、そして管轄区域の法律に準拠し、他システム、アプリケーション、そしてモジュールとのやり取りを通じて、患者基本情報を保存し一致させる機能を提供しなければならない。
AS.2.2FunctionManagePatient's
Location Within Facility
施設内の患者の位置情報
の管理

1440

Statement: Provide the patient's location information within a facility's premises.
機能概要：施設の構内における患者の位置情報を提供する
Description: It is important to maintain, and/or provide access to information regarding thepatient's location within a facility during an episode of care. This information can be as simple as
the identification of the patient's bed assignment (e.g., John Doe1, Bed 3, Ward 2). It is also
important to provide real-time information regarding the patient's location since they may receive
ancillary services in multiple parts of the facility (e.g., in the physical therapy or diagnostic
imaging departments). Note: The patient's location within a facility may also be revealed byviewing standard reports (such as an Emergency Department Log). The system should supportviewing a patient's specific location in terms that may include campus, building, wing, unit, room,
and/or bed. The system should support jurisdictional laws related to the patient's ability (or desire)to consent to disclose their location within a facility (e.g., it may be unlawful to require a minor
child to sign a consent form regarding their location in a facility). The patient's location
information within the facility should also be available even before the patient is ascribed to a
specific provider within that facility. As such, the system may need to provide a query feature
regarding the patient's location information. The system may also support the identification of thepatient by alternate identifying names (e.g., John Doe1 or "J. Doe1"). For example, the patient's
physical therapist may be permitted to view an elderly patient's location within a long term carefacility, but the patient's pharmacist may be restricted from viewing that information.
機能説明：治療の間、施設内における患者の位置に関する情報の公開を維持およびまたは提供することは重要である。この情報は患者のベッドの割り当てを証明するような簡易なもので良い。
（例：患者
太郎１ ２病棟ベッド３）。施設における複数の部門で補助的なサービスを受ける場合から患者の位置に関する即時の情報を提供することも重要である。
（例：理学療法部門または画像診断部門）。注釈：
標準的な報告を見ることにより、施設内の患者の位置が明らかになる場合もある。（救急部門の報告のように）システムは、構内、本棟、別棟、部署、病室おようびまたはベッドなどを含め、明確に患者の特定の位置を見ることを支援すべきである。システムは、施設内での位置を明らかにすることに同意した患者の能力（または要望）に関連した管轄区域の法律を支援すべきである。
（例：施設内の位置に関する同意書への署名を未成年に求めることは違法の場合がある）。施設内における患者の位置情報は、患者が施設内の特定の医療提供者に帰する以前に有効となるべきでもある。そのように、システムは患者の位置情報に関する問合せ機能を提供する必要があるかも知れない。システムは、別に確認している名前による患者の身元証明を支援する場合もある。
（例：患者太郎１または患太郎１）例
えば、患者の理学療法士は長期療養施設における高齢者の位置を見ることを許可されているかも知れないが、患者の薬剤師はその情報を見ることを制限されているかも知れない。
1. The system SHALL provide the ability to render information 1441
regarding the patient's assigned location when the patient
has an assigned location (e.g., specific bed).
1．システムは、患者の位置が割り当てられた際に、患者の位置に関する情報を提示する機能を提供しなければならない。
（例：特定
のベッド）
AS.2.31448
FunctionManagePatient's
ResidencefortheProvision
andAdministrationofServices
サービスの提供と管理のための患者居住地の管理
Statement: Provide the patient's residence information for the provision and administration ofservices to the patient, patient transport, and as required for public health reporting.
機能概要：患者、患者輸送の対するサービスの提供と管理や必要に応じた公衆衛生報告のために、患者の居住地情報を提供する
Description: This function is intended to support the provision of services to patients at their placeof residence. Examples include but are not limited to the following:-Visiting nurse may beproviding care to a new mother and baby at their place of residence.-A patient with a mobility
problem may require transport to and from a clinic appointment.-Support identification ofmultiple residences for a patient like a child with multiple guardians (divorced parents with joint
custody) or adults with Winter/Summer residences.
機能説明：本機能は患者の居住地におけるサービスの提供を支援することを目的としている。例として以下のものを含みうるが、これに限定されるものではない。
・訪問看護師が新生児とその母親に対して診療を提供する場合がある
・移動が困難な患者は予約した診療所を往復する輸送手段が必要となる場合がある。
・複数の後見人がいる子供（共同親権を持つ離婚した両親）や冬／夏の住居を持つ大人の患者のために複数の住居地の識別を支援する。
AS.2.41455
FunctionManage Patient Bed
Assignment
患者のベッド割り当て管理Statement: Support interactions with other systems, applications, and modules to ensure that thepatient's bed assignments within the facility optimize care and minimize risks e.g., of exposure tocontagious patients.
機能概要：施設内の患者のベッド割り当てが診療の最適化や伝染病患者の接触などのリスクを最小限とすることを確実にするため、他システム、アプリケーション、そしてモジュールとのやり取りを支援する
Description: Access to a list of available beds is important to safely manage the care of patients
whose bed requirements may change based on change in condition or risk factors. For example, apatient may need a room with special equipment or to be close to the nursing station or to be in a
private room.
機能説明：容態またはリスク要因に基づき必要とするベッドを変更する場合がある患者の診療を安全に管理するために、使用可能なベッド一覧の利用は重要である。例えば、患者が特別な設備を有する
病室またはナースステーションの近くまたは個室を求める場合がある。
9. The system SHALL provide the ability to separately manage 1464
multiple patients being simultaneously cared for in a single
room or identified space according to scope of practice,organizational policy, and/or jurisdictional law.
9. システムは、業務範囲、組織ポリシー、管轄区域の法律に準拠して一人部屋または特別な場所で同時に診療を受けている複数の患者を別々に管理する機能を提供しなければならない。
AS.2.51467
FunctionManage Patients in
Healthcare Programs
ヘルスケアプログラムによる患者の管理Statement: Capture and manage patient participation in healthcare programs.
機能概要：ヘルスケアプログラムへの患者の参加を保存し管理する
Description: The system can provide the ability to identify patients participating in health care

programs and to also manage information about those programs. The system can also support
managing an organization's defined healthcare programs. These directories may include
population based programs like an accountable care organization or patient-centered medical
homes or patient panels. (NOTE: These program may include a roster-based funding component
tied to patients in the programs.)
機能説明：システムは、ヘルスケアプログラムへ参加している患者の特定と、またそれらのプログラ
ムに関する情報を管理する機能を提供することが可能である。システムは、組織が定めるヘルスケア
プログラムの管理を支援することも可能である。これらのディレクトリは、責任医療組職（ACO）または患者中心のメディカルホーム（PCMH）または患者名簿のようなポピュレーションに基づくプロ
グラムを含む場合がある。
（注釈：これらのプログラムは、患者に結びつく登録制度の資金提供の一部を含む場合がある）
AS.2.61471
FunctionManage Patient Privacy
Consent Directives
患者のプライバシー同意
指示管理
Statement: Provide the ability to record and manage patient-specific privacy consent directive
consistent with privacy policies.
機能概要：プライバシーポリシーと一致した患者特有のプライバシー同意指示を記録して管理する機能を提供する。
Description: The system enables the management of information access to support privacy
policies. These policies allow patients to stipulate specific privacy preferences as a privacy consent
directive. The consent may be issued for a specific disclosure, for a period of time, or until it isexplicitly revoked. This function depends on infrastructure to enforce the privacy consent and any
associated privacy policies using a combination of access control, secure messaging, secure datarouting, and data segmentation.
機能説明：システムは、情報アクセスの管理がプライバシーポリシーを支えることを可能とする。これらのポリシーによりプライバシー同意指示として、患者が特定のプライバシー選択を明記することが出来る。同意は、一時期、特定の開示のために交付されるかも知れないか、それまでは明確に無効となる。本機能は、アクセス基盤、安全な通信、安全なデータ経路、データ分割の組合せを用いて実施されるプライバシー同意と関連するどんなプライバシーポリシーにおける基盤に依存する。
AS.3
1479
HeaderManage Personal Health
Record Interaction
個人健康記録のやり取り
管理Statement: Provide the system support in managing the interaction with a patient's PHR.
機能概要：患者の PHR のやり取りを管理する中でシステムの支援を提供する。
Description: The system can support interaction with the patient's PHR. It can also manage
documentation related to the PHR-S consent and access directives.
機能説明：システムは、患者の PHR のやり取りを支援することが可能である。また、PHR-S の同意に関連した文書を管理することと指示へのアクセスも可能である。
AS.3.11480
FunctionManageInformation
Exchange with Patient
PHR
患者 PHR との情報交換の管理Statement: Support the ability to capture, and/or have interactions with patient PHR systems toenable the creation and maintenance of demographic, clinical and administrative information.

機能概要：基本情報、診療や管理情報の作成と維持を可能とするために、患者の PHR システムとのやり取りを保存およびまたは所有する機能を支援する。
Description: The patient's PHR demographic, clinical and administrative data set is needed tosupport identification and to enhance the prospect for interoperability. The PHR Account Holder
should be able to request or make changes to their demographic data and allow for export of all orparts of the demographic data to other systems.
機能説明：患者の PHR 基本情報、診療や管理データセットは、識別の支援と相互運用性の将来性強化が必要である。PHR Account Holder は、基本情報データの更新や他システムへ全てまたは一部の基本情報データを移行することを要求または実施できなければならない。
AS.3.21486
HeaderManage Legal and Other
Related PHR files
法律やその他に関連する
PHR ファイルの管理
Statement: Manage legal and other related electronic documents that allow or restrict the use or
disclosure of the PHR Account Holder’s information.
機能概要：PHR Account Holder 情報の使用または開示を許可、制限する法律やその他に関連する電子的な文書を管理する。
Description: The system should support the capture and management of files, and/or related
electronic documents related to the use or disclosure of the patient's PHR information. These files,
and/or documents may include scanned images or electronic images sent via attachment. The
system does not judge the authenticity of the document. The system may allows for multiple
instances of the same document (e.g., multiple authorizations). The system may allow for retiring
but tracking of documents no long used. The system should support the removal of documents asrequest by the patient via their PHR system.
機能説明：システムはファイル、およびまたは患者の PHR 基本情報の使用または開示に関する電子的な文書の関係の保存と管理を支援すべきである。これらのファイルおよびまたは文書は、スキャン
画像または付属装置経由で送信された電子画像を含めても差支えない。システムは文書の審議を判断しない。システムは同一文書の複数インスタンスを許可しても差支えない。
（例：複数の認可）システ
ムは長く使用していない文書の追跡し廃棄することを許可しても差支えない。システムは PHR シス
テム経由による患者の要求で文書の移動を支援すべきである。
AS.3.2.1
1487
FunctionManage Consents andAuthorizations from a
PHR
PHR からの同意と認可の管理Statement: Maintain the Consents and Authorization directives/statements from the patient's
PHR.
機能概要：患者の PHR からの同意と認可、指示／声明を維持する
Description: Provide the ability to manage Consents and Authorizations from a Personal Health
Record including manage access control for individual elements of records to which the Consent
or Authorization applies
機能説明：同意または認可に当たる記録の個々の要素に対するアクセス制御を含む個人健康記録（PHR）からの同意と認可を管理する機能を提供する
AS.3.2.2
1495
FunctionManage PHR End-ofLife Documents andOther
AdvanceDirectives
PHR 終末期文書と他の意
思表示の管理Statement: Manage Personal Health Record electronic documents that provide the patients
direction for end-of-life care and manage other types of Advance Directives.
機能概要：終末期医療のため患者指示の提供や他の（治療方針に対する）意思表示（AD）の管理としての個人健康記録（PHR）の電子文書を管理する
Description: Advanced directives may need to be harmonized with external systems (e.g., Personal
Health record system).
機能説明：意思表示は外部システムと調和させる必要があるかも知れない（例：個人健康記録システム）
4. The system SHOULD maintain a list of the location of 1499
advanced directives, end-of-life care directives.
AS.4
HeaderManage Communication
通信の管理

1500

Statement: Support communication to enable the exchange of information internally and between
healthcare and non-healthcare organizations.
機能概要：医療機関と医療機関以外の間にて、内部通信の交換を可能とするための通信のサポート。
Description: Communication among providers involved in the care process can range from realtime communication (e.g., communication between a therapist and nurse), to asynchronous
communication (e.g., consult reports between physicians). Some forms of inter-practitioner
communication will be paper based and the EHR-S must be able to produce appropriate
documents. The system should provide for both verbal and written communication. Theseexchanges would include but not be limited to consults, and referrals as well as possible exchanges
within the office as part of the provision and administration of patient care (e.g., thecommunication of new information obtained within the office environment during the process ofadministration of a tetanus shot while the patient is in the exam room).
機能説明：ケアプロセスに含まれるプロバイダー間の通信は、同期通信（例えば、セラピストと看護師の間での通信）から非同期通信（例えば、医師間の紹介状）まで多岐に渡り可能となる。開業医間のいくつかの形式は紙媒体に基づいており、HER-S は適切な文書を作成する必要がある。システム
は口頭と書面の両方での通信を提供する必要がある。患者ケアの管理と提供の一部として組み込まれる可能性がある交換だけでなく、紹介患者や専門家の助言を制限してはならず、これらの交換は含まれる（例えば、破傷風の予防注射の処置をするために患者が診察室にいる間、職場環境の中で新しい情報の通信が得られる）。
AS.4.11501
FunctionManageRegistry
Communication
登録情報伝達管理
Statement: Enable the exchange of structured demographic and clinical information withregistries (e.g., local disease-specific, notifiable, patient, provider, organization, and healthservices registries) for patient monitoring and subsequent epidemiological analysis.
機能概要：患者モニタリングや付随する疫学分析のための、患者の属性情報や臨床上の登録情報（たとえば、局地的な特異疾患や、届出義務のある項目についての登録情報、患者、医療提供者、組織、
医療サービスの登録情報）の交換ができること。
Description: The system can provide for automated or user-initiated exchange of individuals'
health information to disease-specific registries or other notifiable registries (such as
immunization registries). These exchanges should use standard data transfer protocols or
messages. The systems should allow for updating and configuration of communication with newregistries.
機能説明：疾患特異的な登録情報あるいは他の届け出義務がある登録情報（たとえば免疫情報のような）といった個人的な健康情報について、システムによって自動的、あるいは利用者が開始する交換が行えること。こういった交換には、標準データ転送プロトコルあるいはメッセージが使用される。
システムは、新規登録情報伝達について、更新と設定を可能とすること。
1. The system SHALL provide the ability to exchange structured 1502
demographic and clinical information with registries (e.g.,
local, disease specific, notifiable, patient, provider,organization, or health services registries).
構造化された疫学調査や臨床情報のレジストリ（例えば、地域や特定の疾患、届出義務のある、患者、医療提供者、組織、医療
サービスレジストリ）と登録情報を交換する機能を提供すること。
AS.4.21507
Function
SupportforCommunications
コミュニケーションのサポートStatement: Facilitate communications regarding patient data and status within a health careorganization.
機能概要：医療組織内の患者データや状態に関する情報通信を容易に行えること。
Description: There needs to be an ability to communicate patient data and status (e.g., patient
history, patient physical examination), discrete clinical data (e.g., blood pressure, pulse,
temperature, pulse oximetry, laboratory data, microbiology data, radiology data), and orders
between clinical systems in the facility (e.g., ambulatory, inpatient and ED).
機能説明：そこで、患者データと状態（例、患者の病歴、患者身体検査）、個別の臨床データ（例、血圧、脈拍、体温、パルス酸素濃度計、検査データ、微生物学データ、放射線データ）、施設内の臨床シ
ステム間のオーダ（例、外来、入院、救急）を伝達する能力を必要とする。
AS.4.31511
Function
SupportforCommunications
Between Organizations
組織間での通信のサポートStatement: Facilitate communications regarding patient orders, data and status between
organizations.
機能概要：組織間で患者のオーダやデータ、状態に関する情報伝達を容易にすること。
Description: There needs to be an ability to communicate patient data and status (e.g., patient
history, patient physical examination), discrete clinical data (e.g., blood pressure, pulse,
temperature, pulse oximetry, laboratory data, microbiology data, radiology data), and orders(e.g.,
medications, tests) between health care organizations, particularly during patient transfers. This
information may include items such as outstanding patient requests, clinician carerecommendations, and outstanding treatment and workflow tasks for the patient. Organizations
can include both health care providing organizations (e.g., hospitals, nursing homes) and nonhealth care providing organizations (e.g., funeral homes, disaster operations, employers).
機能説明：患者転院時に健康管理機構間で患者情報や状態（例えば、患者病歴や健康診断）、各臨床データ（例えば、血圧や脈拍、体温、パルス酸素、検査値、細菌、放射線）、オーダ（例えば、処方や検査）といった情報を交換できることが求められている。この情報には未実施の請求や臨床ケア、治療、
ワークフロータスクといった項目が含まれているかもしれない。ここで組織とは、健康管理を行う組織（例えば、病院や老人ホーム）と健康管理を行わない組織（例えば、葬儀屋や災害対策部、企業）のどちらも含む。
AS.4.41514

Function
Support for ProviderEmployer
Communications
プロバイダーと企業間の通信サポートStatement: Provide support for capturing employment information, and/or special work related
requirements (e.g., flyers, divers, firemen, transportation workers) to assist in medical disposition
choices and notifications, and support communication to employers.
機能概要：治療の選択や通知を助けるために、就職情報や特殊な仕事（飛行機の操縦士、ドライバー、
翻訳など）の条件を取得することをサポートすること。また企業との通信をサポートすること。
Description: The ability to capture and maintain a patient's employment information, to include
contact information and job title, which is expected to be helpful to the clinician when a patient's
work environment may affect the assessment of alternative diagnoses, applicable to theindividual, as well as the potential treatment(s) that have been tailored to the individual basedon their occupation.
機能説明：患者の職場の問い合わせ先や職業名など就職情報の取得、保持ができること。これは患者の職場環境が病名のアセスメントに影響している可能性がある場合に医師の助けになると考えられる。またこれは個人の場合だけでなく、患者の業務に基づいた治療を考える場合にも役に立つ。
AS.5
HeaderManage Clinical Workflow
Tasking
診療ワークフロータスクの
管理

1518

Statement: Create, schedule, update and manage tasks with appropriate timeliness.
機能概要：適切なタイミングでタスクを作成、スケジュール、更新、および管理する。
Description: Since an electronic health record will replace the paper chart or other paper-based system,
tasks that were based on the paper artifact must be effectively managed in the electronic environment.
機能説明：EHR は、紙のカルテまたは他の紙ベースの運用に代わるものなので、紙で実現されていたタスク
は、電子化された環境においても効果的に管理されなければならない。
Functions must exist in the EHR-S that support electronically any workflow that previously depended on theexistence of a physical artifact (such as the paper chart, a phone message slip) in a paper based system.
紙ベースの運用で物理的なもの（紙のカルテ、電話のメモ書きなど）に依存していたワークフローを電子的な方法でサポートする機能が EHR システムに存在しなければならない。
Tasks differ from other more generic communication among participants in the care process because they
are a call to action and target completion of a specific workflow in the context of a patient's health record(including a specific component of the record).
タスクは、ケアプロセスに参加する人の一般的なコミュニケーションとは異なる。タスクは、患者の健康記録（特定のコンポーネントを含む）の一部であり、特定のワークフローの実行と目標の達成を呼びかけるものである。
Tasks also require disposition (final resolution). The initiator may optionally require a response.For example,
in a paper based system, physically placing charts in piles for review creates a physical queue of tasks related
to those charts.
タスクは実施（最終解決）されなければならない。タスクの発生源が返答を要求することもある。例えば紙ベースの運用では、レビューのために実際に紙カルテを重ねて配置することで、それらの紙カルテに関連するタスクの物理的な待ち行列を作成できる。
This queue of tasks (for example, a set of patient phone calls to be returned) must be supported electronicallyso that the list (of patients to be called) is visible to the appropriate user or role for disposition.
このタスクの待ち行列（例えば、返答すべき患者からの電話の一覧）は、適切なユーザまたは職種にリスト（電話をかける患者の一覧）を表示できるように電子的にサポートされなければならない。
The state transition (e.g., created, performed and resolved) may be managed by the user explicitly or
automatically based on rules.
状態遷移（作成、実行、および解決）は、ルールに基づいて自動的にまたはユーザによって明示的に管理されてもよい。
For example, if a user has a task to signoff on a test result, that task should automatically be marked
complete by the EHR when the test result linked to the task is signed in the system.
たとえば、ユーザが検査結果に確認サインするタスクを持っており、そのタスクにリンクされた検査結果がシステムで割り当てられている場合、そのタスクは EHR によって自動的にマークされる。
Patients will become more involved in the care process by receiving tasks related to their care.
患者は自分のケアに関連するタスクを受け取ることで、ケアプロセスにもっと関与するようになる。
AS.5.1
Function
Clinical Task Creation,
Assignment and Routing
診療タスクの生成、割り当て、およびルーティング

1519

Statement: Creation, assignment, delegation, and/or transmission of tasks to the appropriate parties.
機能概要：適切な担当者へのタスクの作成、割り当て、委任、および伝達。
Description: A "Task" is a specific piece of work or duty that is assigned to a person or entity. A task often
needs to be accomplished within a defined period of time or by a deadline. Tasks are often managed by anactivity (or project) tracking mechanism (e.g., as part of an automated business rule process).
機能説明：タスクは、個人またはグループに割り当てられた特定の仕事または義務である。タスクは、決められた期間内または締切までに完了する必要があることが多い。タスクは、アクティビティ（またはプロジェクト）の追跡メカニズム（自動的なビジネスルール管理の一部）によって管理されることが多い。
Tasks are determined by the specific needs of patients and practitioners in a care setting. Task creation
may be automated, where appropriate. An example of a system-triggered task is when laboratory results arereceived electronically; a task to review the result is automatically generated and assigned to a responsible
party.
タスクは、ケアの現場における患者および医師のニーズによって決定される。タスクの作成を必要に応じて自動化できる。システムによって起動されるタスクの例は、検査結果が電子的に受信される場合である。検
査結果をレビューするタスクが自動的に生成され担当者に割り当てられる。
Tasks are at all times assigned to at least one user or role for disposition. Whether the task is assignable
and to whom the task can be assigned will be determined by the specific needs of practitioners in a caresetting.Task-assignment lists help users prioritize and complete assigned tasks.
タスクはそれを処理するために、常に少なくとも 1 人のユーザまたは職種に割り当てられる。タスクが割り当て可能であるか、誰にタスクを割り当てられるかは、ケアの現場の医師のニーズによって決まる。タスク割り
当てリストは、タスクの優先順位付けと割り当てられたタスクの完了を支援する。
For example, after receiving communication (e.g., a phone call or e-mail) from a patient, the triage nurse
routes or assigns a task to return the patient's call to the physician who is on call physician.
例えば、患者からの通信（電話や電子メール）を受信した場合、トリアージを担当する看護師は、患者への折返し連絡のタスクを待機している医師にルーティングまたは割り当てる。
Another example is for a urinalysis, the nurse routes or assigns a task to clinical staff to collect a urine
specimen, and for the results to be routed to the responsible physician and person ordering the test. Task
creation and assignment may be automated, where appropriate. An example is when (International NormalizedRatio) INR results are received they should be automatically routed and assigned to the staff person in theclinic responsible for managing all of the patients that are having INR tests done.
もう一つの例は尿検査のためのもので、看護師は尿検査の検体採取を診療スタッフにルーティングまたは割り当てる、またその結果を責任ある医師と検査を依頼した医師にルーティングする。このタスクの作成と割り当ては必要に応じて自動化できる。たとえば、INR（プロトロンビン時間国際標準化比）の結果が受信された場合、INR 検査を受けているすべての患者の管理に責任を持つ診療スタッフに自動的にルーティングまたは割り当てられる。
Task assignment ensures that all tasks are disposed of by the appropriate person or role and allows efficientinteraction of entities in the care process. When a task is assigned to more than one individual or role, anindication is required to show whether the task must be completed by all individuals/roles or if only one
completion suffice.
タスクの割り当てにより、すべてのタスクが適切な人や職種によって実施されることで、ケアプロセスにおけるグループの効率的なやりとりが可能になる。タスクが複数の個人または職種に割り当てられている場合、タスクがすべての個人または職種によって完了される必要があるか、またはそれらのうち 1 つの完了で十分であるか、を示す必要がある。
1.The system SHALL provide the ability to capture new tasks.
1520
1..システムは新しいタスクを取得する機能を提供しなければならない。
3. The system SHALL provide the ability for the user to enter and update 1522
an assignment for a task to one or more individuals or roles.
3. システムはユーザが 1 つ以上の個人または職種にタスクを割り当て更新する機能を提供しなければならない。
5. The system SHALL provide the ability to determine and update an 1524
assignment for a task to one or more individuals or clinical roles,
based on workflow rules.
5. システムは業務フロールールに基づいて、1 つ以上の個人または職種に対しタスクを割り当て更新する機能を提供しなければならない。
12. The system SHALL provide the ability to update the priorities of 1531
clinical tasks (e.g., to ensure timely completion).
12. システムはタスクの優先順位を更新する機能を提供しなければならない（タイムリーな完了を確実にするため）
AS.5.2
1543
Function
Clinical Task Assignment
and Routing for Medication
Management&
Administration
医薬品管理のための臨床タスクの割り当てとルーティ
ング
Statement: Assignment, delegation, and/or transmission of tasks for Medication Orders and Prescription
Management.
機能概要：投薬指示および処方管理のタスクの割り当て、委任、および伝達。
Description: There are tasks that are specific to prescription management. An example of a system-triggered
task is when a medication defined as for continuous use runs out, a notification task should be initiated forevaluation of the need to renew or not.
機能説明：処方管理に特有のタスクがある。システムによって起動されるタスクの例は、継続使用している薬品がなくなった場合、処方せんの更新の必要性を評価するために通知タスクを開始することである。
Quality care implies consideration of medication continuation or renewal in light of various patient and visit
factors . This requires also that the relevant information is presented to the clinician in an effective manner.
The decision by the clinician must then be captured in an efficient manner and actioned by the systemthrough task assignment and communication.
ケアの質には、様々な患者および来院目的に照らして、薬物の継続または更新を考慮することが含まれる。
これを実現するためには、関連情報が効果的な方法で医師に提示されることが必要である。医師による決定は、効率的な方法で収集されシステムで管理された、タスク割り当てとコミュニケーションによって行われ

なければならない。
Presentation of tasks to be carried out needs to be in a manner that facilitates their execution andmanagement and needs to correspond to user preferences. For example, the list could be ordered by priority
or by pharmacy phone number for efficiency.
実行すべきタスクの提示は、実行と管理を容易にするとともに、ユーザの好みに対応する方法で行う必要があります。例えば、リストの表示順は効率化のために、重要度順や薬局の電話番号で順で表示できる。
4. The system SHALL provide the ability to determine the tasks to be 1547
performed in relation to medication continuation or renewal.
4. システムは、投薬の継続または更新に関連して実行されるタスクを管理する能力を提供しなければならない。
AS.5.31548
Function
Clinical Task Linking
診療タスクのリンク
Statement: Linkage of tasks to EHR components, patients, and/or a relevant part of the electronic healthrecord.
機能概要：EHR コンポーネント、患者、および EHR の関連部分へのタスクのリンク。
Description: Clinical tasks must include information or provide an electronic link to information that isrequired to complete the task. There is a need to create the appropriate links and, then, to have thesystem automatically present the information that was linked.
機能説明：診療タスクには、タスクを完了するために必要な情報への電子的なリンクが含まれる。さらに、適切なリンクを作成し、リンクされた情報をシステムが自動的に表示する必要がある。
For example, this may include a patient location in a facility, a patient’s, and/or family's contact information,
or a link to new laboratory results in the patient’s EHR.
例えば、施設内の患者の位置、患者および家族の連絡先情報、または EHR にある新しい検査結果へのリンクを含むことができる。
Other example: the linkage of prescription task to the appropriate patient care plan to facilitate follow-up
actions; a task to take weights links to the ‘Weights and Vitals’ screen to record the result; a task tocomplete a fall assessment links to the fall assessment form to be completed.
その他の例として、フォローアップを促進する適切なケアプランにおける処方タスクへの連携、体重計測のタ
スクから結果を記録するバイタル画面へのリンク、アセスメントを完了するタスクから完了すべきアセスメント
書式へのリンク。
An example of a well defined task is "Dr. Jones must review Mr. Smith's blood work results." Efficient
workflow is facilitated by navigating to the appropriate area of the record to ensure that the appropriate test
result for the correct patient is reviewed.
良く定義されたタスクの例は「ジョーンズ博士はスミス氏の血液検査結果を確認する必要がある」に対し、確認すべき適切な患者の適切な検査結果であることを保証するために、適切な記録にナビゲートすることにより、効率的なワークフローが容易になる。
1. The system SHALL provide the ability to link a clinical task to the 1549
component of the EHR system required to complete the task.
1. システムはタスクを完了させるために必要な EHR システムのコンポーネントに診療タスクを紐付ける機能が要求される。
4. The system SHALL provide the ability to link a clinical task to a 1552
patient.
4. システムは診療タスクを患者に紐付ける機能を要求される。
AS.5.41553
Function
Clinical
Task
StatusTracking
診療タスクの状態追跡
Statement: Track tasks to facilitate monitoring for timely and appropriate completion of each task.
機能概要：各タスクの適時かつ適切な完了を監視するのを容易にするためにタスクを追跡します。

Description: In order to reduce the risk of errors during the care process due to missed tasks, the provider
is able to view the status of each task (e.g., unassigned, on hold, started, performed, canceled, denied, andresolved) and current work lists, lists of unassigned tasks or undisposed tasks, or of other tasks where a riskof omission exists.
機能説明：不実施のタスクによるケアプロセスのエラーのリスクを低減するために、ケア提供者は各タスクの状態（未割り当て、保留中、開始済、実施済、取消、拒否、解決など）を表示でき、現在の作業リスト、割り当
てられていないタスクまたは未配置のタスクリスト、不実施のリスクがあるタスクリストなどを表示できる。
The timeliness of certain tasks can be tracked, or reports generated, in accordance with relevant law andaccreditation standards. For example, a provider is able to create a report that shows tests that have notyet been performed such as urine specimen obtained, blood work drawn, etc.
関連する法律および認定基準に従って、特定のタスクの適時性を追跡しレポートを生成することができる。
例えば、尿や血液など採取されたが実施されていない検査のレポートを作成できる。
Another example is that of an electronic prescribing system that would track when a refill request orprescription change is received, who it has been assigned to, the action performed, and when it wascompleted.
別の例は、いつ再処方が要求されたか、またはいつ処方変更が受信されたか、それが誰に割り当てられたか、いつ実行されいつ完了したか、を追跡する電子処方システムである。
1. The system SHALL provide the ability to update the status of tasks. 1554
1. システムは、タスクの状態を更新する機能を提供しなければならない。
3. The system SHALL provide the ability to render notices of the status 1556
of tasks to providers.
3. システムは、タスクの状態をプロバイダに通知する機能を提供しなけ
ればならない。
5. The system SHALL provide the ability to determine the order of 1558
clinical tasks based on status.
5. システムは、診療タスクの状態に基づいて順序を決定する機能を提供しなければならない。
12. IF the system provides the ability to determine when time limits for 1565
a particular task are exceeded;, THEN the system SHALL provide
the ability to render a list of these tasks.
12. システムが、時間制限を超えたタスクを検出する能力を提供する場
合、システムはこれらのタスクの状態を変更する機能を提供しなけ
ればならない。
14. The system SHALL provide the ability to update task status (e.g., 1567
unassigned, on hold, started, performed, canceled, denied, andresolved).
14. システムは、タスクの状態（未割り当て、保留中、開始済、実施済、取消、拒否、解決など）を更新する機能を提供しなければならない。
AS.6
1569
HeaderManageResource
Availability
資源可用性の管理Statement: Manage the availability of healthcare resources to support the provision of care.
機能概要：ケアの準備を支援するための医療資源の可用性を管理する。
Description: Resources may include human resources (e.g., providers, support personnel) as well as physicalresources (e.g., facilities, transportation, equipment, supplies).
機能説明：資源には人的資源（医療提供者、ケア支援者）と物理的資源（施設、輸送、機器、消耗品）が含まれる。
Managing resources includes managing the availability of necessary resources to support the provision ofcare including resource scheduling and managing information about the resources (e.g., availability,capabilities). The management of resources may also include supporting triage categorization, waiting rooms
and patient acuity and severity determination.
資源管理には、資源のスケジュールや資源に関する情報（可用性、数量など）の管理など、ケアの準備に必要な資源の可用性の管理が含まれる。また、リソースの管理には、トリアージの分類の補助、待合室、患者の緊急度および重症度判定が含まれる場合がある。
AS.6.1
1570
FunctionManageFacility
Demographics
施設の人基本情報管理Statement: Maintain facility demographic information.
機能概要：施設の基本情報を維持する。
Description: Demographic information is necessary to uniquely define a healthcare facility (e.g., hospital,
freestanding birthing center, clinic, doctor's office, hospice, or nursing home/long-term care facility,transportation/ambulance provider).
機能説明：基本情報は、医療施設（病院、産院、診療所、ホスピス、療養施設、救急搬送サービス）を個別に定義するために必要である。
Example of demographic information may include the facility name, physical location and unique facility
identifier (e.g., U.S. National Provider Identifier).
基本情報は例えば施設名、物理的な場所、および施設 ID（U.S. National Provider Identifier）を含む。
1. The system SHALL provide the ability to manage the facility's 1571
demographic information (e.g., the facility name, facility address,
facility type, and the registration number of the facility in accordancewith jurisdictional law).
1. システムは施設の人口動態情報を管理する機能を要求される。(例
えば、施設名、施設住所、施設タイプ、管轄法による施設登録番号など、管轄区域の法律に準じて)
AS.6.2
1573
FunctionManageHealthcare
Resource
Availability
Information
医療資源の可用性情報の管理
Statement: Support the collection and distribution of local healthcare resource information, throughinteractions with other systems, applications, and modules, to enable planning and response to extraordinary
events such as local or national emergencies.
機能概要：地元または全国的な緊急事態などの並外れたイベントへの計画や対応を可能にするために、他のシステム、アプリケーションやモジュールとの相互作用を通じて地元における医療資源情報の収集と分類をサポートする。
Description: In times of identified local or national emergencies and upon request from authorized bodies,
provide current status of healthcare resources including, but not limited to, available beds, providers, support
personnel, ancillary care areas and devices, operating theaters, medical supplies, vaccines, andpharmaceuticals. The intent is to enable the authorized body to distribute or redistribute either resources or
patient load to maximize efficient healthcare delivery. In addition, these functions may also be used forinternal assessment and planning purposes by facility administrators.
機能説明：特定の地元または全国的な緊急事態時や権限を持つ組織からの要請で、空きベッド、提供者、サポート人員、付随するケア場所と機器、手術室、医療備品、ワクチン、調剤、だけではないがそれらを含む医療資源の現状を提供する。意図は、効率的な医療提供を最大化するために、権限を持つ組織が資源または医師の受け持つ患者を配布または再配布することを可能にすることである。加えて、これらの機能は内部のアセスメントと計画目的のために施設の管理者によって使われる。
AS.6.31575

Function
ManageHealthcare
Resource Scheduling
医療資源のスケジュール管理Statement: Support interactions with other systems, applications, and modules to provide the necessary
data to a scheduling system for optimal efficiency in the scheduling of patient care, for either the patient or
a resource/device.
機能概要：他のシステム、アプリケーション、およびモジュールとの連携をサポートすることで、スケジューリ
ングシステムに必要なデータを提供し、ケアのために患者や医療機器などの資源を最適な効率でスケジューリングします。
Description: The system may support user access to scheduling systems as required. Relevant clinical or
demographic information required in the scheduling process could be linked to the task.
機能説明：システムは、必要に応じてスケジューリングシステムへのユーザクセスをサポートする。スケジュ
ーリングプロセスで必要とされ関連する臨床および基本情報は、タスクにリンクさせることができる。
AS.6.4
1584
Function
SupportTriageCategorization
トリアージ分類の支援
Statement: Provide support for prioritizing patients based upon acuity, wait time, and practitioner load.
機能概要：重症度、待ち時間、および医師の負荷を元に患者の優先度判定をサポートする。
Description: An EHR-S should support the management of patients waiting for care by displaying them andsupporting decisions by the clinicians who are caring for them.
機能説明：EHR システムは、ケアを待っている患者を表示することで患者の管理を支援し、ケアを担当する医師による決定を支援する。
The triage process not only collects data on arriving patients, but the categorization and prioritization ofpatients who are unable to be seen immediately. It is a dynamic process where patient priorities change overtime. Unless a care team has unlimited resources, some patients will invariably need to wait.
トリアージプロセスは到着した患者のデータを収集するだけでなく、即座には判断できない患者の分類と優先順位付けを行う。これは、患者の優先順位が時間とともに変化する動的なプロセスです。ケアチームに無限のリソースがない限り、一部の患者は常に待つ必要がある。
1. The system SHALL provide a means to manage a triage acuity rating 1585
for a patient.
1. システムは、患者の重症度のトリアージを管理する手段を提供しなけ
ればならない2. The system SHALL capture, maintain and render triage acuity ratings 1586
derived from standardized acuity scales.
2. システムは、標準化された重症度スケールから導かれたトリアージの重症度を取得し、維持し、再評価できなければならない。
AS.6.5
1590
Function
Support Waiting RoomManagement
待合室管理の支援
Statement: Provide support to waiting room management
機能概要：待合室管理を支援する
Description: An EHR-S should support the reporting, tracking and alerts needed to help manage thosepatients that need to wait and supporting prioritization decisions by the clinicians who are caring for them.
機能説明：EHR システムは、ケアを担当する医師による優先順位付けを待ち管理を必要としている患者をレポート、追跡、および警告することを支援する。
1. The system SHALL present a list of triaged patients.
1. システムは、トリアージされた患者リストを表示しなければならない。
AS.6.6Function
Support Patient Acuity andSeverity Determination
患者の重篤度および重症度判定のサポート

1591
1595

Statement: Provide the data necessary to support and manage patient acuity and severity determination for
illness/risk-based adjustment of resources.
機能概要：疾病やリスクを元にした資源調整のために、患者の重篤度および重症度判定を支援し管理するためのデータを提供する。
Description: Acuity data helps determine appropriate staffing – as modified by the nurses’ level ofexperience, the organization’s characteristics, and the quality of clinical interaction between and among
physicians, nurses, and administrators.
機能説明：看護師の経験レベル、組織の特性、および医師、看護師、管理者の間の連携の質によって調整された適切な人員配置を決定するために、重篤度のデータが役立つ。
Research has been done on nurse staffing and patient outcomes; the impact of organizational characteristics
on nurse staffing patterns, patient outcomes, and costs; and the impact of nurses’ experience on patient
outcomes.
看護職員の配置と患者アウトカムやコストの関係、看護職員の配置パターンに及ぼす組織の特性の影響、患者のアウトカムに対する看護師の経験の影響などに関する研究が行われている。
The research indicates that nurse staffing has a definite and measurable impact on patient outcomes, medical
errors, length of stay, nurse turnover, and patient mortality. Also, acuity and severity data is routinely theevidential basis most frequently cited by staff when recommending clinical staffing changes.
この調査によると、看護職員の配置は、患者のアウトカム、医療過誤、在院期間、看護師の離職率、患者の死亡率に明確かつ測定可能な影響を与えている。また、重篤度および重症度のデータは、診療スタッフの変更を検討する際に、一般的に最も頻繁に引用されるエビデンスである。
AS.7
HeaderSupport
Encounter/EpisodeofCare Management
受診や治療歴の管理サポ
ート

1600

Statement: Manage and document the health care needed and delivered during an
encounter/episode of care.
機能概要：受診や治療の間に必要かつ提供される診療文書の管理
Description: Using data standards and technologies that support interoperability, encounter
management promotes patient-centered/oriented care and enables real time, immediate point ofservice, point of care by facilitating efficient work flow and operations performance to ensure theintegrity of (1) the health record, (2) public health, financial and administrative reporting, and (3)the healthcare delivery process. This support is necessary for care provision functionality that
relies on providing user interaction and workflows. These interactions and workflows are
configured according to clinical protocols and business rules. These protocols and rules are basedon encounter specific values such as care setting, encounter type (inpatient, outpatient, homehealth, etc.), provider type, patient's EHR, health status, demographics, and the initial purpose of
the encounter.
機能説明：相互運用性をサポートするデータ標準と技術を使うことによって、患者中心・指向の治療

と即時性、すぐに役立つ観点、ワークフローを効率的に容易にするという治療の観点、(1) 健康情報、(2) 公衆衛生、財政と行政報告、(3) 医療提供プロセスの統合を確保するための操作性能により、診療情報の管理を促進する。このサポートは、ユーザインタラクションやワークフローを提供することに依存している治療提供機能に必要である。これらの相互作用とワークフローは、臨床プロトコル（臨床試験計画書）とビジネスルールによって構成される。これらのプロトコルとルールは、治療環境、受診形態（入院患者、外来患者、在宅患者など）、供給形態、患者の EHR、健康状態、人口統計、治療の初期の目的などの治療の具体的な価値に基づく。
AS.7.1
1601
FunctionManagePresentation
Filters
Statement: Present specialized views based on the encounter-specific values, clinical protocols andbusiness rules.
機能概要：診療の特定の値、臨床プロトコルとビジネスルールに基づく特定の観点の症状を見つける
Description: The system user is presented with a presentation view and system interaction
appropriate to the context with capture of encounter-specific values, clinical protocols andbusiness rules. This "user view" may be configurable by the user or system technicians. As an
example, a mobile home health care worker using wireless laptop at the patient's home would bepresented with a home health care specific workflow synchronized to the current patient's careplan and tailored to support the interventions appropriate for this patient, including chronic
disease management protocols.
機能説明：システムの利用者は、症状を見つける観点と診療上の特徴や臨床プロトコル、ビジネスル
ールを記録することによる背景に適したシステムの相互作用によって症状を見つける。この利用者観
点は、システムの利用者やシステム技術者によって変更を可能とする。例えば、患者の自宅にてワイ
ヤレスノートパソコンを使う移動する在宅医療者は、現在の患者の治療計画と患者にとって適切な介入支援と慢性的な行基を管理するためのプロトコルを同期する特徴的なワークフローである在宅医療の中で症状を見つける可能性がある。
AS.7.21605
Function
Support
Encounter
Documentation
診療文書管理のサポート
Statement: Provide assistance in assembling data, supporting data collection and processing
output from a specific encounter.
機能概要：データの組み立て、データ収集のサポート、および特定の診療行為から得られるデータを処理すること、これらの補助をおこなう。
Description: Workflows, based on the encounter management settings, will assist (with triggers
alerts and other means) in determining and supporting data collection, import, export, extraction,linkages and transformation. As an example, a pediatrician is presented with diagnostic andprocedure codes specific to pediatrics. Business rules enable automatic collection of data from thepatient's health record and patient registry. As the provider enters data, workflow processes are
triggered to populate transactions and documents. For example, data entry might populate aneligibility verification transaction or query the immunization registry.
機能説明：診療管理の背景に基づくワークフローは、意思決定やデータ収集のサポート時に、入出力、抽出、紐付け、変換、といった補助をおこなう（警告や、他の意味において）。例えば、小児科特有の病気の特徴、処置コードを小児科医に提供する。ビジネスルールは、患者の健康診断書や、患者レジストリからのデータの自動収集を可能にする。データ入力に従い、ワークフローの過程は、処置やドキュメント化を促す。例えば、データ入力することで、適任立証の処置を表すか予防接種登録の照会ができるだろう。
AS.7.31611
Function
SupportFinancial
Reporting
財務報告のサポートStatement: Provide clinical data to support administrative and financial reporting.
機能概要：財務報告をサポートするために臨床データを提供すること。
Description: The system may be able to generate or support the creation of a bill based on healthrecord data. Maximizing the extent to which administrative and financial data can be derived ordeveloped from clinical data by the system, will lessen provider reporting burdens and the time ittakes to complete administrative and financial processes such as claim reimbursement. This may
be implemented by mapping of clinical terminologies in use to administrative and financial
terminologies. Administrative and financial systems may be integrated or non-integrated.
機能説明：システムは健診記録データに基づく請求書の作成または支援し得る。システムによって臨
床データから財務データを引き出して開発する程度を最大化することで、請求償還のような財務のプ
ロセスを完了させるための、従業者の報告の負担とその時間を減少させることができるだろう。これは、財務で使用されている用語に対して臨床用語をマッピングすることで実装し得る。財務のシステ
ムは統合または非統合され得る。
AS.7.4
1614
Function
SupportRemoteHealthcare Services
遠隔医療サービスのサポートStatement: Support remote health care services such as tele-health and remote device monitoringby integrating records and data collected by these means into the patient's record for caremanagement, billing and public health reporting purposes.
機能概要：ケアマネジメントや医療費、公衆衛生報告書のための患者記録に、遠隔治療やリモートデバイスのモニタリングによって集積された患者情報を統合する事で、リモートヘルスケアサービスを支援する。
Description: Enables remote treatment of patients using monitoring devices, and two way
communications between provider and patient or provider and provider. Promotes patient
empowerment, self-determination and ability to maintain health status in the community.
Promotes personal health, wellness and preventative care. For example, a diabetic pregnant
mother can self-monitor her condition from her home and use web TV to report to her provider.
The same TV-internet connectivity allows her to get dietary and other health promoting
information to assist her with managing her high-risk pregnancy.
機能説明：モニタリング装置を使う事によって、患者への遠隔治療を可能とし、医療提供者と患者、または医療提供者同士のコミュニケーションといった、２つの方法も可能にする。患者の権威や自己決定権、生活の中で健康状態を保つことを促進する。個人での健康管理や高い健康意識、予防医療を促進する。例えば、糖尿病で妊娠中の女性が家で自分自身の体調を確認することができたり、彼女の医療提供者に報告するために WebTV を使うことができる。インターネットと連携したテレビによって、彼女は規定食を取れるようになり、また他の健康促進情報が彼女の高度で危険な妊娠状態を管理することを援助する。
AS.7.51617
FunctionManage Transitions ofCare and Discharged
Patients
ケアの推移と退院患者の管理Statement: Provide a means to manage outstanding patient issues after the encounter, for transits
of care and discharge.
機能概要：搬送や退院といった、診察後に解決できない患者の問題を管理する方法を提供する。
Description: After the completion of an encounter, a number of tasks may remain for dischargeplanning, patient instructions and transitions of care. There may be outstanding laboratory tests(i.e. blood cultures) radiology interpretations, or other tasks such as arrangement of home healthaids (VNA), transportation or calls to the patient's primary care provider during office hours toestablish follow-up. There must be a way to track and document these tasks after the conclusionof the encounter.
機能説明：診察が完了した後、退院計画や患者指導、ケアの移行といった、いくつかの課題が残り続
けるかもしれない。それらは、まだ結果の出ていない臨床検査（例えば血液培養など）や読影、または在宅ケアの準備（VNA）や搬送方法、または経過観察をするために業務時間中の医療提供者を呼ぶ
ことのような課題かもしれない。診察が完了した後、それらの課題を文書として残して辿る方法があ
るべきである。

AS.8
HeaderManageInformation
Access for Supplemental
Use
補足使用のための情報ア
クセスの管理1623

Statement: Support extraction, transformation and linkage of information from structured data
and unstructured text in the patient's health record for care management, financial,administrative, and public health purposes.
機能概要：ケアの管理、財務上、経営上および公衆衛生を目的とした患者のヘルスレコードに含まれる、構造化されたデータや構造化されていないテキストから情報の抽出、変換、リンケージのサポートDescription: Information in the patient's health record is used for administrative purposes (e.g.,care management, finance and public health services) that are supplemental to care provision andcare provision support. Using data standards and technologies that support interoperability,
information access functionalities serve primary and secondary record use and reporting. This
health record information may include internal and external sources of patient data.
機能説明：患者のヘルスレコードの情報は、ケア提供やケア提供サポートを補足する経営上の目的（例
えば、ケアマネージメント、会計上および公衆衛生サービス）で利用される。相互運用性をサポートするデータ標準とテクノロジーを使うことによって、情報アクセス機能は、プライマリ、セカンダリ
レコードの利用とレポートを実現する。このヘルスレコード情報は、内部および外部発生の患者デー
タを含むかもしれない。
AS.8.1
1624
Function
SupportRules-Driven
Clinical Coding
ルール駆動のクリニカル
コーディングのサポート
Statement: Make available all pertinent patient information needed to support coding of
diagnoses, procedures and outcomes.
機能概要：診断、過程、アウトカムのコーディングをサポートするのに必要なすべての有効な患者情報の作成
Description: The user is assisted in coding information for clinical reporting reasons. For example,
a professional coder may have to code the principal diagnosis in the current, applicable ICD as abasis for hospital funding. All diagnoses and procedures during the episode may be presented tothe coder, as well as the applicable ICD hierarchy containing these codes.
機能説明：ユーザは、レポート作成のためにコーディングする際に支援を受ける。例えば、コーダーの専門家は、主要な診断結果を、病院の資金提供の根拠として適用される ICD といったコードにコー
ディングしないといけないかもしれない。
1. The system SHALL provide the ability to render patient 1625
information needed to support coding of diagnosis, procedures
and outcomes.

システムは、診断、過程、アウトカムのコーディングをサポートするために必要とされる患者情報を提示する機能を提供しなけ
ればならない。
AS.8.2Function
SupportRules-Driven
Financial&
Administrative Coding
ルール駆動の財務上、経営上のコーディングのサポ
ート

1636

Statement: Provide financial and administrative coding assistance based on the structured data
and unstructured text available in the encounter documentation.
機能概要：受療文書の中の構造化データや非構造化テキストに基づいた、財務上、経営上のコーディ
ング支援の提供
Description: The user is assisted in coding information for billing or administrative reasons. For
example, in the US Domain, the HIPAA 837 Professional claim requires the date of the last
menstrual cycle for claims involving pregnancy. To support the generation of this transaction, theprovider would need to be prompted to enter this date when the patient is first determined to bepregnant, then making this information available for the billing process.
機能説明：ユーザは、会計、経営のためにコーディングする際に支援を受ける。例えばアメリカでは、
HIPAA 837 Professional claim は、妊娠に関する最終月経の日付を要求する。この処理を支援するため、患者が最初に妊娠を告げられた時や会計の過程で有効な情報を作成するときに、医療関係者はこの日の入力を促される必要がある。
1. The system SHALL provide the ability to maintain and render 1637
financial and administrative codes.
システムは、財務上、経営上のコードを管理や提示する機能を提供しなければならない。
AS.8.31644
Function
Support Integration of
Cost/Financial
information into PatientCare
患者ケアとコスト／財務
情報の統合サポート
Statement: Support interactions with other systems, applications, and modules to enable the useof cost management information required to guide users and workflows.
機能概要：他システム、アプリケーション、ユーザやワークフローをガイドするために必要なコスト
管理情報の利用を容易にするモジュールとのインタラクションのサポート
Description: The provider is alerted or presented with the most cost-effective services, referrals,
devices, etc., to recommend to the patient. This may be tailored to the patient's healthinsurance/plan coverage rules. Medications may be presented in order of cost, or the cost of specificinterventions may be presented at the time of ordering.
機能説明：医療関係者は、患者に紹介するために、最も費用効果があるサービス、紹介、デバイス等を提示されたり、警告されたりする。これは、患者の保険や保険プランの範囲によってテーラリング
されるかもしれない。投薬はコスト順に提示されるかもしれない。具体的な処置、治療のコストはオーダ時に提示されるかもしれない。
AS.8.41651
FunctionManageHealthcare
Facility
Performance
Information
施設のパフォーマンス情報の管理Statement: Support the import or retrieval of data necessary to review available quality,
performance, and cost measurements regarding healthcare facilities.
機能概要：施設に関する品質、パフォーマンス、コストを評価するために必要なデータのインポー
トや検索のサポートを提供する。
Description: The ability to access information to help facilities with the gathering, managing andusing data to assist in the assessment of quality, performance and cost measurements.
機能説明：品質、パフォーマンス、コスト指標のアセスメントを支援するためのデータの収集、管理、利用をサポートする情報へのアクセス機能
AS.8.51653
Function
Support for Provider
Training
医療関係者トレーニングのサポート
Statement: Provide the ability to clinician and staff training requirements and document
proficiency.
機能概要：資格やドキュメント力のトレーニングをする臨床家、スタッフへの機能の提供
Description: In order to deliver quality care, health care systems train their staff in the processes,
workflows, and tools required to deliver quality patient care. This training is necessary when staff
are initially hired, and also periodically as the evidence-based medical guidance or the tools
available to the health care systems change. The system can have a role to track and document
the training requirement, progress and proficiency. The system may control user access to system
functionality based on training.
機能説明：質の高いケアを提供するために、ヘルスケアシステムは、プロセス、ワークフロー、ツー
ルを利用するスタッフを訓練する。このトレーニングは、スタッフが雇用されたとき、および定期的に必要とされる。例えば、EBM のガイダンスやヘルスケアシステムの変更を入手するツール等がある。
そのシステムは、トレーニングの必要性や上達度を追跡し、記録する役割も担う。システムは、トレーニングに基づいて、システム機能へのユーザクセスをコントロールするかもしれない。
AS.9
1662
HeaderManage Administrative
Transaction Processing
経営上のトランザクショ
ン処理の管理Statement: Support the creation (including using external data sources, if necessary), electronicinterchange, and processing of transactions listed below that may be necessary for administrative
management during an episode of care.
機能概要：データ生成（外部のデータソース利用を含む）と、電子的な交換と、治療の期間中の経営上の管理に必要なトランザクション処理のサポート
Description: Support the creation (including using external data sources, if necessary), electronicinterchange, and processing of transactions listed below that may be necessary for administrative
management during an episode of care. The EHR system collects patient health-related
information needed for purpose of administrative and financial activities including
reimbursement. Captures the episode and encounter information to pass to administrative or
financial processes (e.g., triggers transmissions of charge transactions as by-product of on-line
interaction including order entry, order statusing, result entry, documentation entry, medication
administration charting).Automatically retrieves information needed to verify coverage andmedical necessity. As a byproduct of care delivery and documentation captures and presents all
patient information needed to support coding. Ideally performs coding based on documentation.
Clinically automated revenue cycle - examples of reduced denials and error rates in claims.
Clinical information needed for billing is available on the date of service. Physician and clinicalteams do not perform additional data entry / tasks exclusively to support administrative or
financial processes.
機能説明：データ生成（外部のデータソース利用を含む）と、電子的な交換と、治療の期間中の経営上の管理に必要なトランザクション処理をサポートする。EHR システムは、経営上の目的や払い戻しを含む財務上のアクティビティで必要とされる患者の健康関連情報を収集する。経営上あるいは財務上のプロセスのためのエピソードと受療情報を捕捉する（例えば、オーダエントリやオーダ進捗更新、
結果入力、文書入力、投薬管理チャートを含むオンライン処理の副産物としての請求トランザクショ
ンのトリガーとなる）。保険契約と医療必要度の証明に必要とされる情報は自動的に抽出される。ケ
ア提供とドキュメンテーションの副産物として、コーディングをサポートするために必要とされるすべての患者情報が補足、提供される。理想的には、ドキュメンテーションに基づいてコーディングは実行される。臨床の自動的な収益サイクル－請求の中で削減された拒否とエラー率の例。請求書のために必要とされる臨床上の情報は、サービス当日に利用可能である。医師とクリニカルチームは、経営上や財務上のプロセスの支援のために追加データの入力やタスクを実行しない。
AS.9.1
1663
Function
Support Financial Plan
Enrollment
財務上の計画登録のサポートStatement: Support interactions with other systems, applications, and modules to facilitate
enrollment of uninsured patients into subsidized and unsubsidized health plans, and enrollmentof patients who are eligible on the basis of health, and/or financial status in social service andother programs, including clinical trials.
機能概要：他のシステム、アプリケーション、保険未加入者の助成金の有無を考慮したヘルスプランの登録、ソーシャルサービスと治験を含むその他のプログラムにおける健康状態や財務状況に基づいた患者の登録を容易にするモジュールとのインタラクションのサポート。
Description: Expedites determination of health insurance coverage, thereby increasing patient
access to care. The provider may be alerted that uninsured patients may be eligible for subsidized
health insurance or other health programs because they meet eligibility criteria based on
demographics, and/or health status. For example a provider is notified that the uninsured parentsof a child enrolled in SCHIP may now be eligible for a new subsidized health insurance program;a provider of a pregnant patient who has recently immigrated is presented with information about
eligibility for subsidy. Links may be provided to online enrollment forms. When enrollment isdetermined, the health coverage information needed for processing administrative and financial
documentation, reports or transactions is captured.
機能説明：健康保険の範囲の決定を促進する。それによって、ケアのための患者のアクセスを増加させる。医療関係者は、保険未加入者が助成金を与えられる健康保険やその他のヘルスプログラムに適しているかもしれないことを警告されるかもしれない。なぜなら、それらは患者の基本情報や健康状
態に基づいた保険加入資格に合致するからである。例えば、医療関係者は SCHIP（The StateChildren's Health Insurance Program：児童健康保険プログラム）に登録されている子供の保険に未加入の親が、今、新しい助成金対象の健康保険プログラムに適格であるかもしれないということを通知されたり、最近移住した妊娠した患者の医療関係者が助成金の保険加入資格についての情報を受けとったりする。リンクは、オンライン登録フォームによって提供されるかもしれない。加入が決まった時、経営上の処理と財務上のドキュメンテーションやレポート、取引のために必要とされる医療保障の情報が捕捉される。
AS.9.2
1668
Function
SupportFinancial
Eligibility Verification
財務上の保険加入資格の証明のサポート
Statement: Support interactions with other systems, applications, and modules to enableeligibility verification for health insurance and special programs, including verification of benefits
and pre-determination of coverage.
機能概要：健康保険と特別なプログラムの保険加入資格を証明するための他のシステム、アプリケー

ション、モジュールとのインタラクションのサポート。 （利益の証明と補償範囲の仮決定を含む）
Description: Retrieves information needed to support verification of coverage at the appropriate
juncture in the encounter workflow. Improves patient access to covered care and reduces claim
denials. When eligibility is verified, the system could prompt a provider to capture eligibility
information needed for processing administrative and financial documentation, reports ortransactions; updating or flagging any inconsistent data. In addition to health insurance
eligibility, this function would support verification of registration in programs and registries, suchas chronic care case management and immunization registries. A system would likely verify healthinsurance eligibility prior to the encounter, but would verify registration in case management or
immunization registries during the encounter.
機能説明：受療ワークフローの中の適切な接合点における補償範囲の証明のサポートに必要な情報の取得。保証されるケアへの患者アクセスの改善と、請求拒否の削減。保険加入資格を証明するとき、システムは、経営上、財務上のドキュメンテーションとレポートおよび取引の処理のために必要となる保険加入資格情報を捕捉するよう医療関係者に促す（矛盾したデータを更新したり、フラグ付したりする）。健康保険の保険加入資格に加え、この機能は、慢性患者のケースマネージメントや予防接種のレジストリのように、プログラムとレジストリの中の登録の確認をサポートする。システムは、おそらく、受療より先に健康保険の保険加入資格を確認するが、受療の間にも、ケースマネージメント
や予防接種のレジストリの中の確認もする。
2. IF the system does not provide the ability to exchange 1670
electronic eligibility information (e.g., health plan coveragedates) with internal and external systems, THEN the system
SHALL provide the ability to enter and maintain patient
health plan coverage dates.
もし、システムが内部や外部システムから電子的な保険加入資格
情報（保険の有効期間等）を交換することができなかったら、シ
ステムは、患者の保険有効期間を入力し、維持する機能を提供しなければならない。
AS.9.31678
Function
SupportService
Authorizations
サービス認可のサポート
Statement: Support interactions with other systems, applications, and modules to enable thecreation of requests, responses and appeals related to service authorization, including priorauthorizations, referrals, and pre-certification.
機能概要：優先的な認可、照会、事前査定を含むサービスの認可に関係するリクエスト、レスポンス、
アピールの生成するための他のシステム、アプリケーション、モジュールとの対話のサポート。
Description: Retrieves information needed to support verification of medical necessity and priorauthorization of services at the appropriate juncture in the encounter workflow. Improves
timeliness of patient care and reduces claim denials.
機能説明：受療ワークフローの中の適切な接合点における医療必要度の確認とサービスの優先的な認
可のサポートに必要な情報の検索。患者ケアと拒否要求の削減の適時性を改善する。
AS.9.41685
Function
SupportServiceRequests and Claims
サービスリクエストとク
レームのサポート
Statement: Support interactions with other systems, applications, and modules to support thecreation of health care attachments for submitting additional clinical information in support ofservice requests and claims.
機能概要：サービスリクエストとクレームのサポートの中で追加の医療情報を提示するため、他のシ
ステム、アプリケーション、モジュールとのインタラクションを行い、ヘルスケア付加情報の生成をサポートする。

Description: Retrieves structured and unstructured data, including but not limited to laboratory
data, imaging data, device monitoring data, and text based data, based on rules or requests for
additional clinical information, in support of service requests or claims, at the appropriate
juncture in the encounter workflow.
機能説明：受療ワークフローの中の適切な接合点におけるサービスリクエストやクレームの中にある、追加の医療情報のためのルールやリクエストに基づいた構造化、非構造化データの取得。これら
は、検査データ、画像データ、デバイスモニタリングデータ、テキストベースのデータに限定されない。
1. The system SHALL provide the ability to render available, 1686
applicable clinical information to support service requests.
システムは、サービスリクエストをサポートするための有効で適切な医療情報を提示する機能を提供しなければならない。
2. The system SHALL provide the ability to render available, 1687
applicable clinical information to support claims.
システムは、請求をサポートするための有効で適切な医療情報を提示する機能を提供しなければならない。
AS.9.51690
Function
SupportFinancial
Claims & Encounter
Reports
財務上の請求と受療レポ
ートのサポート
Statement: Support interactions with other systems, applications, and modules to enable thecreation of claims and encounter reports for reimbursement.
機能概要：請求と払い戻しのための受療レポートの生成のための他のシステム、アプリケーションモ
ジュールとのインタラクションのサポート
Description: Retrieves information needed to support claims and encounter reporting. This
reporting occurs at the appropriate juncture in the encounter workflow in a manual or automatedfashion. For example this could occur at an initial, interim or final billing. The system may alsopresent the information that is provided for audit and review.
機能説明：請求と受療レポートのサポートで必要とされる情報の取得。このレポート作成は、手動あるいは自動で受療ワークフローの中での適切な接合点で発生する。例えば、これは、初め、途中、最後の請求時に発生する。システムは、監査やレビューのために提供される情報も提供するかもしれな
い。
1. The system SHALL provide the ability to render available 1691
information needed to enable the creation of claims andencounter reports for reimbursement.
システムは、請求と払い戻しのための受療レポートを生成するのに必要な有効な情報を提示する機能を提供しなければならない。
2. The system SHALL provide the ability to capture and render 1692
available data as required for audit and review according toscope of practice, organizational policy, and/or jurisdictionallaw.
システムは、診療の範囲や組織ポリシーや管轄区域の法律による監査やレビューのための要求として、有効なデータを捕捉し、提示する機能を提供しなければならない。

5. Population Health Support Section
ポピュレーション・ヘルス支援機能
Section/id#：
Type:
Conformance Criteria
Name:
POP.1
HeaderSupportfor
HealthMaintenance,
Preventative Care andWellness
健康維持、予防的ケアおよびウェルネスのための
支援

Row#
1256

Statement: Evaluate patient information to provide alerts, notifications and reminders regarding
health, preventative care and wellness.
機能概要：健康、予防的ケア、およびウェルネスに関わるアラート、通知、リマインダを提供するため、患者情報を評価する。
Description: The system assists in determining ongoing and pertinent communications from theprovider to patient to promote health, preventative care and wellness.
機能説明：システムは健康、予防的ケア、およびウェルネスを促進するため、医療提供者から患者に対する、進行中の適切なミュニケーションの決定を支援する。
POP.1.1
1257
Function
Present
AlertsforPreventative
Servicesand Wellness
予防的サービスおよびウェルネスのためのアラー
トの提示
Statement: Identify patient-specific suggestions/reminders, screening tests/exams, and otherpreventative services in support of routine preventative and wellness car
機能概要：日常的な予防的・ウェルネスケアを支えるため、患者個別の提案/リマインダ、スクリーニ
ングテスト/検査、およびその他の予防的サービスを特定する。
Description: At the time of an encounter, the provider or patient is presented with due or overdue
activities based on protocols for preventative care and wellness. Examples include routine
immunizations, adult and well child care, age and gender appropriate screening exams, such as
PAP smears.
機能説明：受診(受療)の際に、予防的ケア・ウェルネスのためのプロトコルに基づいて、医療提供者
または患者に対し、予定されている、あるいは予定日を過ぎた、実施すべき(受けるべき)行為を提示する。例えば、定期予防接種、成人や健康な小児のケア、子宮頸がん細胞診等、年齢や性別に応じた
適切なスクリーニング検査などである。
1. The system SHALL provide the ability to manage criteria for 1258
disease management, wellness, and preventative services
based on patient demographic data (minimally age andgender).
1. システムは、患者の基本情報(最低限、年齢と性別)に基づいて、
疾病管理、ウェルネス、および予防的サービスのための基準を管理する機能を提供しなければならない。
4. The system SHALL provide the ability to render alerts based 1261

Section/id#：
Type:
Name:

Conformance Criteria

Row#

on recognized-standard guidelines, and/or locally-defined
standard guidelines.
4. システムは、広く認められている標準ガイドラインおよび(または) 組織内で定義されたガイドラインに基づいて、アラートを出す機能を提供しなければならない。
POP.1.2
Function
Present
Notifications
andRemindersforPreventative
Servicesand Wellness
予防的サービスおよびウェルネスのための通知およびリマインダの提示

1270

Statement: Evaluate and notify patient, and/or provider of those preventative services, tests, or
behavioral actions that are due or overdue.
機能概要：患者および(または)医療提供者に、予定の、あるいは予定期日を過ぎた、予防的サービス、
検査、あるいは 行動的活動(behavioral actions)を評価し通知する。
Description: The system generates notifications to patients regarding activities that are due or
overdue. Examples include but are not limited to time sensitive patient and provider notificationof follow-up appointments, laboratory tests, immunizations or examinations. The notifications canbe customized in terms of timing, repetitions and administration reports. For example, a PAP test
reminder might be sent to the patient two months prior to the test being due, repeated at threemonth intervals, and then reported to the administrator or clinician when nine months overdue.
機能説明：システムは、予定された、あるいは予定期日をすぎた事項についての患者への通知を生成する。例えば、時間が重要である患者や医療提供者への通知で、フォローアップ予約、臨床検査、予防接種、あるいは診察等である。通知は、タイミングや、繰り返し回数、実施報告等のカスタマイズが可能であるものとする。例えば、子宮頸がん細胞診の場合は患者へのリマインダを予定の 2 カ月前に送り、その後 3 ヵ月ごとに繰り返し、9 カ月が過ぎたら管理者もしくは医師に報告する、等である。
1. The system SHALL capture, maintain, and render timely 1271
notifications to patients, and/or appropriate providers of
preventative services, tests or behavioral actions that are
due or overdue on an individual patient.
1. システムは、予定された、あるいは予定を過ぎた予防的サービ
ス、検査、あるいは行為(behavioral actions)についての患者および(または)適切な医療提供者に対する通知を、把握・維持し、タイムリーに生成できなければならない。
POP.2
1279
HeaderSupportPopulationBased Epidemiological
Investigation
ポピュレーションに基づいた疫学的研究の支援
Statement: Support for population-based internal and external epidemiological investigations ofclinical health of aggregate patient data for use in identifying health risks from the environment,
and/or population in accordance with jurisdictional law.
機能概要： 管轄区域の法律に準じて、環境および(または)ポピュレーションからの健康リスクを識別するために利用されるポピュレーション・ベースの患者データ集合について、臨床的な健康状態に関する内的および外的疫学的研究を支援する。
Description: A care provider, public health expert, or organization may wish to analyze data fromcohorts,(i.e., subpopulations defined by certain characteristics or conditions). For example, cohorts

Section/id#：
Type:
Conformance Criteria
Row#
Name:
can be described in terms of demographics; education and social status; health status, diseases, oroutcomes; industry and occupation; or injuries. Population health analysts, such as experts inpublic health departments, may compile individual, and/or population information reported orotherwise gathered from multiple EHRs within the jurisdictional area for surveillance andresearch. Populations of one or none also can be informative. By analyzing specified data for acohort, public health experts and care providers can monitor disease prevalence and healthrelated trends; evaluate behavioral, socioeconomical, occupational, and other impacts on health;and identify potential outbreaks and associated risk factors. Examples include:- examining acohort of patients with measles for a common (implied) exposure, such as attending the sameschool - following a cohort of diabetics with out-of-range markers, or analyze them from various
perspectives, such as by occupation, blood sugar range, drugs that are being used and not being
used. - examining a cohort of bakers for a higher-than-expected prevalence of asthma. - Upon
suspicion of a flu outbreak, reviewing a cohort of patients who have presented in the Emergency
Department in the last three days complaining of breathing difficulty. - Examining cohorts ofsmokers with lung disease, sand-blasters with breathing disorders, adults with asthma, etc. A
broad range of information is used for population health surveillance and analyses, including (butnot limited to) health status/disease/outcomes, completion/results of recommended health screens,current or previous medical treatment data, demographics, education, marital status, social
factors, family history of diseases, personal history (e.g., alcohol and tobacco use, reading
capability, hearing deficiency), and environmental factors (such as occupation and industry, shiftwork, hobby). The information may or may not be coded; the text may be structured or
unstructured. Person-level data is used to identify persons with specified characteristics such as
exposures, symptoms, risk factors, injuries, genetic markers, diseases or health outcomes that
may require further care. Person-level data also is required to evaluate groupings of injuries,
diseases or adverse health outcomes. Issues of access to person-level data while securing patient
privacy are relevant. Data also may be monitored and analyzed in “aggregate” (for example, by
age range, geographic location, socio-economic level, or education level), depicting the quantity ofrecords, and/or content within each aggregate. Aggregates may be used to report deidentified data
to public health, for example, cases of influenza-like-illness by age range. Case and population
information are subject to public health reporting. Care organizations may require population
health reports, for example, to measure quality of care based on health improvements for
populations under the care of their providers. Statistical analyses are a key component toanalyzing population health data, such as epidemiological investigations to identify relationships
between risks (such as exposures or behaviors) and health conditions. Individual clinicians or
healthcare organizations may employ limited capabilities in EHR systems to analyze population
health data. The EHR system also should be capable of interacting with, and leveraging, thecapabilities of specialized external analytical systems.The investigator may hide or mask certain
aspects of epidemiological investigation information, as necessary according to scope of practice,policy, and/or law. The investigator may desire to tag or remove patients from the cohort who haverelocated or died
機能説明：医療提供者、公衆衛生の専門家、あるいは組織は、コーホート(すなわち、何等かの特徴や条件で定義されるサブポピュレーション)から得られるデータを分析したい場合がある。例えば、コー
ホートは、個人の属性や、教育、社会的地位、健康状態、疾患、あるいはアウトカム、業種や職業、傷病などにより記述される。公衆衛生部門の専門家等によるポピュレーション・ヘルスの分析は、当該領域において、サーベイランスや研究のため、報告された、あるいは複数の EHR から収集された個々人および(または)ポピュレーションの情報を編纂する。一つのポピュレーションである、あるいはないということも(Populations of one or none)有益であり得る。あるコーホートの指定されたデータを分析することで、公衆衛生の専門家や医療提供者は、有病率に関する傾向をモニターし、行動学
的、社会経済学的、職業的、あるいは他のインパクトを評価し、潜在的なアウトブレイクや関連するリスク要因を特定し得る。例としては以下が挙げられる:- はしか患者のコーホートを、例えば同じ学校に通っているなどの共通の(含意される)曝露について調べる- マーカーが範囲外の糖尿病コーホートの追跡、あるいは職業、血糖値の範囲、医薬品を服用中もし
くは服用していない等、様々な観点から分析する- 喘息有病率が想定より高いパン製造業者のコーホートを検査する

Section/id#：
Type:
Name:

Conformance Criteria

Row#- インフルエンザのアウトブレイクの疑いに際し、過去 3 日の間に呼吸の困難を訴えて救急部門を訪れた患者コーホートを調べる- 肺疾患、呼吸障害を伴うサンドブラスター(sand-blasters)、喘息の成人の、喫煙者のコーホートを調べる
ポピュレーションのサーベイランスや分析には、広範囲に渡る情報が利用される。例えば、健康状態/疾患/アウトカム、推奨される健康スクリーニングの実施/結果、現在の投薬・投薬歴のデータ、基本
属性、教育、婚姻状態、社会的要因、疾患の家族歴、個人歴 (例えば、酒やたばこ、読解力、聴力障
害)、および環境要因(職業、業種、シフト勤務、趣味など)、であり、これに限るわけではない。情報はコード化されている場合、されていない場合がある。テキストは構造化されている場合、されていない場合がある。個人レベルのデータは、さらなるケアを必要とする曝露、症状、リスク要因、怪我、遺伝的マーカー、疾患あるいは健康アウトカム等の、特定の特徴を有する個人を識別するのに利用される。個人レベルのデータは、さらに怪我、疾患、有害な健康アウトカムの分類を評価するためにも必要とされる。患者のプライバシーを担保しつつ個人レベルのデータにアクセスするにあたっての課
題が関わる。
件数および(あるいは)個々の分類内での内容を表現する、(例えば、年齢層別、地域別、社会経済レベ
ル別、教育別などに)集約されたデータをモニターし、分析する場合もある。
データ集合は、例えばインフルエンザ様の疾病の年齢別例数など、公衆衛生に匿名化されたデータを報告するのに使われることがある。ケースとポピュレーションの情報は公衆衛生報告の対象となる。
ケアを提供する組織は、例えば、その組織の医療者のケアのもとにあるポピュレーションの健康向上に基づいたケアの質の測定など、公衆衛生の報告を求める場合がある。統計分析は、(曝露や行動等の)リスクと健康状態の関係を調べるための疫学的研究のようなポピュレーション・ヘルスのデータ分析
において、キーとなる要素である。臨床医あるいは医療施設は、ポピュレーション・ヘルスのデータを分析するため、システムの限定された機能を用いるかもしれない。EHR システムは、また外部の特化した分析システムと、やりとりし活用する機能を有するべきである。研究者は活動、方針、かつ/または法律に準じて、必要に応じて疫学的研究の情報のある観点を秘匿、あるいはマスクする場合もある。研究者は、移動、あるいは死亡した患者をタグ付けする、あるいはコーホートから除外することも必要かもしない。
POP.2.1
1280
Function
SupportforEpidemiological
Investigation
Data
Collection
疫学的研究データ収集の支援
Statement: Support for Person-Level and Aggregate-Level Queries to Generate Population
Cohorts, and/or Aggregates to be used in epidemiologic investigations and reports.
機能概要：疫学的研究や報告に利用される、ポピュレーション・コーホートおよび/または集合を生成するための、個人レベルおよび集合レベルのクエリーの生成を支援する。
Description: Population health analysts (investigators) examine health data for trends andconditions through the use of well-defined queries to create their data sets. Preparing such welldefined queries, i.e., selection criteria and parameters, used to generate a cohort can be a complex
and iterative process. The investigator may desire to use pre-defined or self-constructed queries(which may be saved for reuse). During the process of defining a query, the investigator may desire
to accumulate statistics regarding the results of interim queries (e.g., number of patients in thequery result) to determine the suitability of the queries, and subsequently modify the final query.
The investigator maintains sets of queries by constructing names that depict the cohorts, the fields
comprising the queries and, perhaps, values for those fields. The resultant data set generated
should be validated against the intended purpose of the query. Queries may need to be saved tosupport future analysis of the same (or a similar) cohort. For example, the investigator may
construct an "Insulin study for males age 65 and older" query that is used to review patients of a
specific age, gender and drug usage, then also construct an “Insulin study for females age 65 andSection/id#：
Type:
Conformance Criteria
Row#
Name:
older” query by modifying a copy of the first one. Queries may identify “static” or “dynamic”
cohorts. A “static cohort” query identifies and monitors certain patients within a given cohort overtime (e.g., pregnant patients who arrived in the Emergency Department in January, 2012 andfollowed throughout their pregnancies). A “dynamic cohort” query may identify new patients to be
added periodically to a cohort (e.g., the number of pregnant patients who arrived in the Emergency
Department during each month). Information compiled by using a query may need to be governed
by applicable policies and regulations. For example, psychiatric data may need to be excluded froma given epidemiological investigation. The query may need to specify that subjects are deidentified or aggregates are created according to the requirements of the analysis or privacy
restrictions. For example, queries may be made of de-identified aggregate subjects to evaluate
possible medical products safety issues quickly and securely. Data aggregation may be used to deidentify subjects, to condense the cohort, or to sub-divide a given cohort into various "aggregates"(for example, by age range, geographic location, socio-economic level, or education level), depicting
the quantity of records, and/or content within each aggregate. Aggregate data may need to be
integrated or linked d within or across cohorts. The criteria for data aggregation also may be
applied to different cohorts.
機能説明: ポピュレーション・ヘルスの解析者 (研究者)は、well-defined クエリーを用いてデータセットを作成し、健康データを傾向や条件の分析に利用する。そうした well-defined クエリーの準備、
すなわち、コーホートを生成するための選択基準やパラメータの準備は、複雑な繰り返しのプロセスである。研究者は、事前に定義された、あるいは self-constructed クエリーを利用したいと考え得る(再利用のため保存され得る)。
クエリーを定義するプロセスの間、研究者はクエリーの適合性を決定し、その後、最終的なクエリーを調整するため途中のクエリーの結果(例えばクエリーの結果における患者数)に関する統計を集約したいと考え得る。研究者はコーホートを表す名前、 クエリーを構成するフィールド、そして恐らく、それらのフィールドの値を設定し、クエリーの集合を維持する。生成されたデータセットは、クエリ
ーの意図する目的に鑑みてバリデートする必要がある。クエリーは、前と同じ、あるいは同様のコー
ホートの分析を支援するため、保存する必要があるかもしれない。例えば、研究者は特定の年齢、性別、薬剤の服用等の患者を調べるため、「65 歳以上の男性のインシュリンの研究」というクエリーを作り、また最初のクエリーをコピーして修正することで「65 歳以上の女性のインシュリンの研究」というクエリーを作る等である。 クエリーは静的な、あるいは動的なコーホートを識別するかもしれない。
「静的なコーホート」のクエリーは、長期に渡る、コーホート内における患者を識別し、モニターするかもしれない(例えば、2012 年 1 月に救急部門に搬送され、その後の妊娠期間中、追跡された
妊婦の患者)。
「動的コーホート」クエリーは、コーホートに定期的に追加される新規の患者を識別し得る。(例えば、毎月、救急部門に搬入された妊婦の患者数)。クエリーを用いて編集される情報は、適用される方針や法規により管理される必要が生じ得る。例えば、精神科のデータは、ある疫学的研究からは除外する必要があるであろう。クエリーは、対象者は匿名化されている、あるいは集合は分析の要件あるいはプライバシーの制約に準じて作成されていることを示す必要も生じ得る。例えば、クエリーは、医療安全の課題を迅速かつセキュアに評価するための匿名化された集合対象者に対するものである等。データ集合は、対象者の匿名化に、コーホートの凝縮(condense) に、あるいはコーホートを部分集合(例えば、年齢層、地理、社会経済レベル、教育レベルなど)に分割し、件数、および/
または、データ集合内の内容を把握するのに用いられることも考えられる。データ集約は、複数コー
ホートを統合化し、あるいはリンクするのに利用され得る。データ集合の基準は、他の異なるコーホートに適用されることも考えられる。
1. The system SHALL provide the ability to manage queries 1281
(e.g., criteria and parameters based on surveillanceparameters, demographic, and/or clinical information) for
use in extracting one or more cohorts, and/or aggregatesaccording to scope of practice, organizational policy, and/or
jurisdictional law.
1. システムは、業務範囲、組織ポリシー、管轄区域の法律に準じてコーホートを抽出し、かつ/または集約するため、クエリーを管理する機能(例えば、サーベイランスのパラメータに基づいた基準とパラメータ、患者属性、および/または臨床情報)を提供しなければならない。
2. The system SHALL provide the ability to capture and 1282
maintain pre-defined criteria and parameters (e.g., based onSection/id#：
Type:
Name:

POP.2.2
Function
SupportforEpidemiologic
DataAnalysis
疫学的データ分析の支援

Conformance CriteriaRow#demographic, and/or clinical information) for use in
extracting one or more cohorts, and/or aggregates.
2. システムは、コーホートを抽出し、かつ/または集約するため、事前に定義された基準とパラメータ(例えば、患者属性、および/または臨床情報)を把握、維持しなければならない。
3. The system SHALL provide the ability to capture and 12
maintain ad hoc criteria and parameters specified by theuser (e.g., based on demographic, and/or clinical information)
for use in extracting one or more cohorts, and/or aggregates
3. システムは、コーホートを抽出し、かつ/または集約するため、ユーザがその時点で指定する基準とパラメータ(例えば、患者
属性、および/または臨床情報)を把握、維持する機能を提供しなければならない。
4. The system SHALL provide the ability to capture and render 1284
the attributes (namely, the metadata) of a query (forexample, query name, description, fields, values, and/or
assumptions).
4. システムは、クエリーの属性(すなわち、メタデータ)を把握、維持する機能を提供しなければならない(例えば、クエリーの名
前、説明、フィールド、値、かつ/または前提)。
5. The system SHALL provide the ability to maintain new 1285
cohort or cohorts.
5. システムは、新たな(一つまたは複数の)コーホートを維持する機能を提供しなければならない。
8. The system SHALL provide the ability to manage data- 1288
visibility as a query component according to scope ofpractice, organizational policy, and/or jurisdictional law.
8. システムは、業務範囲、組織ポリシー、管轄区域の法律に準じてクエリーの要素として、データ明確化を維持する機能を提供しなければならない。
11. The system SHALL provide the ability to manage ad hoc 1291
inquiries from public health organizations (e.g., requests for
information related to demographic or clinical information)according to scope of practice, organizational policy, and/or
jurisdictional law.
11. システムは、業務範囲、組織ポリシー、管轄区域の法律に準じて公衆衛生組織からのアドホックな問い合わせ(例えば、属性
や臨床情報に関連した要求)を管理する機能を提供しなければならない。
12. The system SHALL provide the ability to manage case- 1292
reporting requirements defined by public healthorganizations as queries according to scope of practice,organizational policy, and/or jurisdictional law.
12. システムは、業務範囲、組織ポリシー、管轄区域の法律に準じて公衆衛生組織により定義されるケース・レポーティングの要求を管理する機能を提供しなければならない。
1293

Statement: Support for Cohort Person-Level and Aggregate-Level Data Content and Analysis
機能概要: コーホートの個人レベルおよび集約レベルのデータ内容と分析を支援する。
Description: The EHR system assists care providers, public health experts and others in assessing

Section/id#：
Type:
Conformance Criteria
Row#
Name:
patient and population health conditions. Healthcare can be improved if analyses are performed
on a population basis to evaluate care delivery, health status and disease trends, and identify
potential modifiable risk factors. The various ways of analyzing a population (cohort) can becomplex. Some population-based research examines relationships between events or exposuresand their corresponding outcomes. Other population based research may focus on healthcare
utilization, service availability and quality of care. Population-level surveillance, monitoring of
disease, and epidemiologic research involves analysis of data based on existing relationships
between pre-defined and well-known data elements. These analyses utilize various data elements
including demographics, education, marital status, social factors, family history of diseases,
personal history (e.g., alcohol and tobacco use, reading capability, hearing impairment),
environmental factors (such as proximity to toxic exposures), occupational factors (such as type ofoccupation and industry, shift-work, training, hobby), genomic and proteomic data elements,
resource utilization, problem lists, and other clinical information. The identification of new andpreviously unrecognized patterns of disease may require sophisticated pattern recognition
analysis. Early recognition of new patterns may require data available early in the disease
presentation. For example, an investigation of pneumococcal disease may involve a trend analysisof the causative serotype (laboratory data) over time, evaluated per age group of patientsdiagnosed with pneumonia (aggregates). Several aggregates may be identified (e.g., multiple agegroups). Each aggregate then is analyzed as a group for selected data pattern(s) using data
elements that include, but are not limited to, patient demographics, presenting symptoms, acutetreatment regimens, occupational information, and laboratory and imaging study orders andresults.
機能説明: EHR システムは、ケア提供者、公衆衛生の専門家、その他の人が、患者やポピュレーショ
ンの健康状態を評価するのを支援する。ケアの提供、健康状態、疾病の動向を評価するため、潜在的な修正可能なリスク要因の特定に、分析がポピュレーション・ベースでなされるならば、医療の向上が可能である。ポピュレーション(コーホート)を分析する様々な方法が混在し得る。あるポピュレー
ション・ベースの研究は、イベントと曝露の関係と関連するアウトカムについて分析するであろうし、また他のポピュレーション・ベースの研究は、医療の利用状況、 サービスの利用可能性、ケアの質に焦点を当てるであろう。ポピュレーション・ベースのサーベイランス、疾病モニタリング、疫学的研
究は、事前に定義された、あるいは、よく知られたデータ要素に基づいてデータの分析を行う。これ
らの分析は、属性、教育、婚姻状態、社会的要因、個人歴(飲酒、喫煙、読解力、聴覚障害)、環境因子(毒物曝露への近接度)、職業因子(職業・産業の種類、シフト業務、トレーニング、趣味)、ゲノムおよびプロテオーム・データ要素、リソース活用、プロブレムリスト、その他、臨床情報など様々なデー
タ要素を用いる。新たな、あるいは既に認識されている疾病のパターンの特定には、洗練されたパターン認識分析が必要となり得る。新たなパターンの早期の認識には病状発現の早期にデータが必要である。例えば、肺炎球菌に起因する疾患の研究には、傾向分析に、肺炎と診断された患者の年齢層別に評価された、原因となる血清型(検査データ)の時間軸にわたるデータ(集約)が必要である。複数のデータ集約が得られるかもしれない (例えば、複数の年齢層群など)。個々のデータ集約は患者属性、症状、急性期治療のレジメン、職業情報、検査・画像診断オーダ、結果、その他のデータ要素を用いて選択されたデータパターンについて、グループとして分析される。
3. The system SHALL provide the ability to manage person- 1296
level information in a cohort or aggregate using useridentified, and/or pre-defined criteria (e.g., demographic or
clinical information) according to scope of practice,organizational policy, and/or jurisdictional law.
3. システムは、業務範囲、組織ポリシー、管轄区域の法律に準じてコーホートあるいは集合における個人単位の情報を、ユーザが指定する、あるいは事前に設定された基準(属性や臨床情報等)を用いて管理する機能を提供しなければならない。
POP.2.3
1300
Function
Support for Cohort andAggregate Data Sharing
コーホート及び集約デー
タの共有の支援Statement: Support cohort and aggregate-level population data sharing within an organization,

Section/id#：
Type:
Conformance CriteriaName:and/or with other organizations.

Row#

機能概要: 組織内で、および/または他の組織との間で、コーホートおよび集合レベルのポピュレーションデータの共有を支援する。
Description: Population health data needs to be shared in a number of formats. The cohort andaggregate data (query results) may need to be shared within a facility or transmitted to otherorganizations on an ad hoc or periodic (namely, regularly scheduled) basis. For example, publichealth surveillance, monitoring and research often rely on analysis of data from multiple sources,
including EHR systems. The data may need to be prepared in user-defined formats or formats
defined by external parties. The care provider, public health expert, or organization may need totransmit individual or aggregate data in multiple formats (e.g., to an external statistical analytic
application or to public health agencies to meet reporting requirements). Query results may need
to be viewed, saved, and/or printed in pre-defined or ad hoc report formats, ( e.g., for quality
reporting within the care organization). Some or all members of a cohort or population may need
to be anonymized, depending on the rules governing the data sharing.
機能説明: ポピュレーション・ヘルスのデータは、様々な形式で共有される。コーホートおよび集合
データ (クエリーの結果) は、施設内での共有を必要とし、また他の組織にアドホックまたは(予定されているとおり)定期的に伝達される必要がある。例えば、公衆衛生のサーベイランス、モニタリン
グ、および研究は、EHR システムを含む複数のソースからのデータの分析に依拠する。データは、ユーザが定義する形式で、あるいは外部で定義される形式で準備する必要があり得る。医療提供者、公衆衛生専門家、あるいは組織は個々の、あるいは集合データを複数の形式で (外部の統計分析アプリ
ケーションに送る、あるいは公衆衛生当局に、要件に適う型式で送付するなど)伝送する必要があるかもしれない。クエリーの結果は、事前に定義された、あるいはアドホックの形式で、レビュー、保存され、また印字される(例えば、ケア提供組織内での質のモニタリングのため、等)。データ共有のルールによっては、コーホートやポピュレーションの一部あるいはすべてのメンバーを、匿名にする必要があり得る。
1. The system SHALL provide the ability to capture, maintain, 1301
and render a request for a populationbased query result
according to scope of practice, organizational policy, and/or
jurisdictional law.
1. システムは、業務範囲、組織ポリシー、管轄区域の法律に準じて、ポピュレーション・ベースのクエリー結果を、把握、維持、表示する機能を提供しなければならない。
2. The system SHALL provide the ability to capture, maintain, 1302
and render pre-defined report criteria (e.g, fields to be
included in the resulting report or dataset), parameters,
formats, and metadata that specify use, and/or reuse of thereported data according to scope of practice, organizational
policy, and/or jurisdictional law (e.g., the metadata may
indicate that the report is intended for initial, confirmatoryor other analyses).
2. システムは、業務範囲、組織ポリシー、管轄区域の法律に準じて、事前に定義されたレポートの基準(例えば、結果の報告やデータに含むべきフィールド、等)、パラメータ、フォーマット、
および使用を特定するメタデータ、および報告されたデータの再利用を把握、維持し、表示する機能を提供しなければならない。(例えばメタデータは、報告が初回であるとか、確認のためであるとか、あるいは他の分析を意図するなどを表し得る。)
4. The system SHALL provide the ability to maintain and 1304
render the results of a query (e.g., person-level lists, casereports, or aggregates) as specified by the requestors' report
criteria using a recognized or a locally-defined standard (e.g.,
via reporting formats that are specified by public healthguidelines).
4. システムは、一般に認められている標準、あるいは当該組織における標準を用いて、要求者の報告基準により指定されたクエ

Section/id#：
Type:
Name:

Conformance Criteria

Row#

リーの結果(例えば、人レベルのリスト、ケースレポート、デー
タ集合等)を維持し、表示する機能を提供しなければならない。
5. The system SHALL provide the ability to capture, maintain, 1305
and render with reports the metadata that specify use,
and/or reuse of the reported data according to scope ofpractice, organizational policy, and/or jurisdictional law (e.g.,
the metadata may indicate that the report is intended forpreliminary, confirmatory or other analyses; or the metadata
may also indicate that the data may only be used forsurveillance purposes).
5. システムは、レポートとともに、報告されたデータの用途および/または再利用のメタデータを業務範囲、組織ポリシー、管轄区域の法律に準じて把握、維持し、表示する機能を提供しなけ
ればならない。(例えばメタデータは、レポートが予備的、確認のため、あるいは他の分析を意図している、データはサーベイ
ランスの目的にのみ利用可能である、などを示し得る)。
6. IF standardized transmission of the results of a query are 1306
required to/from a registry or directory, THEN the system
SHALL conform to function TI.3 (Registry and Directory
Services).
6. もし、クエリーの結果の標準的な伝送が要求されるならば、システムは、機能 TI.3 (レジストリーとディレクトリ・サービス)に準じなければならない。
7. The system SHALL provide the ability to render the results 1307
of a query in the form of a dataset that can be used by otherprogram areas using analytical software (e.g., statisticalsoftware programs) according to scope of practice,organizational policy, and/or jurisdictional law.
7. システムは、クエリーの結果を、業務範囲、組織ポリシー、管轄区域の法律に準じて、他のプログラム領域による分析ソフト
ウェア(統計ソフトウェアプログラム等)を用いて利用可能なデータセットの形式で表示する機能を提供しなければならない。
8. The system SHALL provide the ability to render the results 1308
of a query according to applicable privacy and confidentiallyrules (to prevent identification of individuals by
unauthorized parties) according to scope of practice,organizational policy, and/or jurisdictional law.
8. システムは、業務範囲、組織ポリシー、管轄区域の法律に準じてクエリーの結果を、適用されるプライバシーと機密性のルールにしたがって(権限を有しない者による個人の識別を防ぐため)表示する機能を提供しなければならない。
9. The system SHALL provide the ability to transmit 1309
information related to individual case reports, including
clinical information (e.g., test results) from a care provider
to public health organizations (e.g., public health notifiable,
and/or reportable condition programs) according to scope ofpractice, organizational policy, and/or jurisdictional law (e.g.,
a care provider notifies the local public health authority of
an individual case of a sexually-transmitted disease that was
identified during the analysis of a related query).
9. システムは、業務範囲、組織ポリシー、管轄区域の法律に準じてケア提供者からの臨床情報(例えば検査結果)などの個々のケ
ースレポートに関する情報を、公衆衛生組織(例えば、公衆衛生
通知可能および/または報告可能条件プログラム)に伝達する機能を提供できなければならない。(例えば、ケア提供者は、関連するクエリーの分析において確認された性感染症の個々のケースを当該地域の公衆衛生当局に通知しければならない。)

Section/id#：
Type:
Name:
POP.3
Function
Support for Notification
and Response
通知と応答の支援

Conformance Criteria

Row#
1310

Statement: Upon notification by an external, authoritative source of a health risk within thecared-for population, alert relevant providers regarding specific potentially at-risk patients withthe appropriate level of notification.
機能概要: ケア対象とするポピュレーションにおいて外部の当局ソースより健康リスクの通知があった際には、 適切なレベルの通知とともに、特定の潜在的なリスクにある患者について、関係する医療提供者にアラートを出す。
Description: After receiving a notice of a health risk within a cared-for population from publichealth authorities or other external authoritative sources: *Identify and notify individual careproviders or care managers that a risk has been identified and requires attention; and *Provide
suggestions on the appropriate course of action. A care provider now has the ability to decide howpatients are notified, if necessary. For example, this function may be used after detection of a local
outbreak of hepatitis A, advising providers of the at-risk population and potential prophylactic
treatment. A second example might be the dissemination of new care guidelines for elderly
patients with a specific chronic disease. Notifications to clinicians or patients may occur by
telephone, email, FAX or other methods.
機能説明: ケアの対象とするポピュレーションにおける健康リスクを、公衆衛生当局あるいは、他の外部当局より通知を受けた後:*個々のケア提供者あるいはケアマネジャーを識別し、リスクが識別され、注意が求められている旨を通知する; また*適切な一連の行動に関する提案を提供する。医療提供者は、この時点で必要に応じて患者にどう通知すべきかを決定することが可能となる。
例えば、この機能は、地域の A 型肝炎のアウトブレイクの検出後に適用され、リスク状況にあるポピュレーションの医療提供者に知らせ、潜在的な予防的治療を助言し得る。二つ目の例としては、特定の慢性疾患を有する高齢患者に対する新規のケアガイドラインの配布かもしれない。臨床家あるいは患者への通知には、電話、Email、FAX、その他の手段を利用し得る。
1. The system SHALL provide the ability to capture, maintain 1311
and render the identity of individual care providers or caremanagers within a cared-for population according to scope ofpractice, organizational policy, and/or jurisdictional law.
1. システムは、業務範囲、組織ポリシー、管轄区域の法律に準じて、ケアの対象となるポピュレーション内において、個々のケ
ア提供者あるいはケアマネジャーの識別を取得し、維持する機能を提供しなければならない。
2. The system SHALL provide the ability to render a response 1312
notification to the care providers or care managers within acared-for population that a health risk notification wasreceived.
2. システムは、健康リスク通知が得られた対象ポピュレーション内における、ケア提供者あるいはケアマネジャーに対し、応答通知を作成する機能を提供しなければならない。
3. The system SHALL provide the ability to capture, maintain 1313
and render notification of a health risk within a cared-for
population from public health authorities or other external
authoritative sources.
3. システムは、ケアの対象とするポピュレーション内における、公衆衛生当局や外部の当局ソースからの健康リスクの通知を取得、維持し、作成する機能を提供しなければならない。

Section/id#：
Type:
Name:

POP.4
Function
Support for Monitoring
Response Notifications
Regarding a SpecificPatient’s Health
特定の患者の健康に関する応答通知のモニタリン
グ支援

Conformance CriteriaRow#

7. The system SHALL provide the ability to render
notifications/reports to public health authorities or otherexternal authorities regarding health risks within a caredfor population according to scope of practice, organizational
policy, and/or jurisdictional law.
7. システムは、業務範囲、組織ポリシー、管轄区域の法律に準じて、ケアの対象とするポピュレーションの健康リスクに関する通知/レポートを公衆衛生当局または外部の当局に対して提示する機能を提供しなければならない。

1317

1319

Statement: In the event of a health risk alert, evalate whether expected actions have been taken,
and execute follow-up notification otherwise.
機能概要: 健康リスクのアラートに対しては、期待される行動が既にとられたか評価し、さもなければフォローアップの通知を行う。
Description: The system assists in follow-up for a specific patient event that has failed to occur(e.g., follow up to a health alert or absence of an expected laboratory result) and communicate theomission to the appropriate care provider(s).
機能説明: システムは、実施できなかった患者イベント(例えば、健康アラートや予定される臨床検査が得られていないことの追跡)に対するフォローアップ、および適切な医療提供者に対する実施されていない旨の通知を支援する。
1. The system SHALL determine and render to the provider 1320
specific recommended actions that may be taken at thepatient level regarding a health risk alert.
1. システムは、ヘルス・リスクアラートに関する、患者レベルで取られる特定の推奨される行為を決定し、提示する機能を持たなければならない。
2. The system SHALL determine and render a notification to 1321
appropriate care providers of specific actions to be taken
regarding the set of patients who are the target of a healthrisk alert.
2. システムは、健康リスクアラートの対象である患者の集合に関して取るべき特定の行為について、適切なケア医療提供者への通知を決定し、表示する機能を持たなければならない。
3. The system SHALL determine and render a list of those 1322
patients who have not received appropriate action in
response to a health risk alert.
3. システムは、健康リスクアラートに対する適切な行為を受けていない患者のリストを決定し、提示する機能を持たなければならない。
4. The system SHALL provide the ability to determine and 1323
render a status report regarding the compliance of the set of
all patients who are the target of a health risk alert.
4. システムは、健康リスクアラートの対象である全ての患者の集合のコンプライアンスに関するステータスレポートを決定し、提示する機能を提供しなければならない。
POP.5
1324

Section/id#：
Type:
Name:
Function
DonorManagement
Supportドナーマネジメントの支援

Conformance Criteria

Row#

Statement: Manage population-based information regarding potential human-product donors,
and/or recipients.
機能概要: human-product のドナーおよび/またはレシピエントに関する潜在的なポピュレーション・
ベースの情報を管理する。
Description: Population-based health risks often require the identification of potential donors andrecipients (e.g., during a disaster, blood is often needed). Other population-based donors andrecipients may need to be identified for items such as organs, eggs, sperm, or stem cells. The user
can make this information available to internal and external donor matching agencies. A consent
or authorization includes patient authorization for redisclosure of sensitive information to third
parties (such as donor management).
機能説明: ポピュレーション・ベースの健康リスクは、潜在的なドナーおよびレシピエントの識別を必要とすることがある(例えば、災害時には血液が必要となる)。また、他のポピュレーション・ベー
スのドナーとレシピエントの場合、例えば、臓器、卵子、精子、あるいは幹細胞のため識別が必要となるかもしれない。ユーザは、この情報を、内部あるいは外部のドナーマッチング当局に提供することができる。同意あるいは承認には、患者の機微な情報(例えば、ドナーマネジメント)の第三者への開示に関する患者の承諾などがある。
POP.6
1330
HeaderMeasurement, Analysis,
Research and Reports
測定、分析、研究および報告Statement: Support the capture and subsequent export or retrieval of data necessary for themeasurement, analysis, research and reporting.
機能概要: 測定、分析、研究および報告に必要なデータの把握と、その後のエキスポートまたは検索を支援する。
Description: Information from the EHR-S may be used to support measurement, analysis,
research and reporting to improve the provision of care. Reporting may include:- reporting on
patient outcome of care by population, facility, provider or community;- providing quality,
performance, and accountability measurements for which providers, facilities, delivery systems,
and communities are held accountable;- support process improvement measures and related
initiatives; and- support health care organizational performance monitoring and improvement.
機能説明: EHR システムからの情報は、ケアの提供を向上させるため、測定、分析、研究、報告を支援するのに利用され得る。報告には、- 患者に対するケアのアウトカムに関する、ポピュレーション・ベース別、施設別、医療提供者別、
あるいはコミュニティ別の報告;- 医療提供者、医療施設、医療提供の制度、およびコミュニティが責任を負う、質、パーフォーマ
ンス、及び説明責任の測定;- プロセス改善の測定および関連するイニシャティブの支援;- 医療施設のパーフォーマンスモニタリングと向上の支援などが含まれる。
POP.6.1
Function
Outcome Measures and1331

Section/id#：
Type:
Name:
Analysis
アウトカムの測定と分析

Conformance Criteria

Row#

Statement: Support the capture and subsequent export or retrieval of data necessary for thereporting on patient outcome of care by population, facility, provider or community.
機能概要: ポピュレーション別、施設別、医療提供者別、あるいは地域別に患者アウトカムを報告するために必要なデータの把握、エキスポート、および検索を支援する。
Description: Many regions require regular reporting on the healthcare provided to individuals andpopulations. The system needs to provide the report-generating capability to easily create thesereports or provide for the export of data to external report-generating software. The system may
also provide the functionality to prompt for the collection of necessary information at theappropriate time in a patient encounter if such collection need can be properly defined in aworkflow (e.g., requesting specific information for reporting of emergency services such as drug
overdose, suspected abuse, communicable diseases, or for the collection of additional research data
for a specific diagnosis).
機能説明: 多くの地域において、個人およびポピュレーションに提供される医療に関する定期的な報告が必要とされる。システムは、これら報告書を作成するため、レポート生成の機能を提供するか、あるいは外部のレポート生成ソフトウェアにデータをエキスポートする機能を提供する必要がある。
システムは、患者の受療における適切な時点で、もし情報収集の必要性がワークフローで適切に定義されているならば、必要な情報の収集 (例えば、薬剤の過剰摂取、虐待疑惑、伝染病など、救急サービスの報告に必要な情報や、特定の診断に関する追加的な研究データの収集のための情報を要求する
等) を促す機能を提供し得る。
9. The system SHALL provide the ability to tag patients who 1340
have been identified as exempt from being included on
certain population-based reports (e.g., reports that would
exclude the identity of a very important person (e.g.,president of a country).
9. システムは、ポピュレーション・ベースの(義務としての)報告から適用除外されることが識別された患者をタグ付けする機能を提供しなければならない。(例えば、国の大統領といった、極めて重要な人物の識別を除く報告等。)
10. IF the system provides the ability to tag patients who have 1341
been identified as exempt from being included on certain
population-based reports, THEN the system SHALL provide
the ability to manage-data-visibility for those patients.
10. もし、システムがポピュレーション・ベースの(義務としての)報告から適用除外されることが識別された患者をタグ付けす
る機能を提供できるならば、システムは、それらの患者に対するデータ可視性を管理する機能を提供しなければならない。
POP.6.2
1342
Function
Quality,
PerformanceandAccountability
Measures
質、パーフォーマンスおよび説明責任のメジャー
Statement: Support the capture and subsequent export or retrieval of patient, and/or population
data necessary to provide quality, performance, and accountability measurements for which
providers, facilities, delivery systems, and communities are held accountable.
機能概要: 医療提供者、施設、提供制度、コミュニティが責任を負う、質、パーフォーマンス、説明責任の測定のための、患者および/またはポピュレーションデータの把握とエキスポートまたは取得を支援する。
Description: Many regions require regular reporting on the healthcare provided to individuals andSection/id#：
Type:
Conformance Criteria
Row#
Name:
populations. This reporting may include measures related to or addressing processes, outcomes,
costs of care, quality of care, adherence to best practice guidelines, and credentialing andprivileging monitoring. The system needs to provide the report-generating capability to easily
create these reports or provide for the export of data to external report-generating software.
機能説明: 多くの地域で、個人やポピュレーションに対して提供される医療に関する定期的な報告が求められる。この報告には、プロセス、アウトカム、ケアのコスト、ケアの有用性、ベストプラクティス・ガイドラインの順守率、信任状提出および秘匿の監視が含まれる。システムは容易に報告書を作成するため、あるいはシステム外のレポート生成システムにデータをエキスポートするため、レポート作成機能を提供する必要がある。
POP.6.3
1351
Function
Support for Process
Improvement
プロセス改善の支援
Statement: Support the capture and subsequent export or retrieval of data necessary to support
process improvement measures and related initiatives.
機能概要: プロセス改善の測定や関連する活動を支援するのに必要な、データの把握、エキスポート、あるいは抽出を支援する。
Description: Many organizations and institutions may require regular reporting of data necessary
to support improvement in the effectiveness and efficiency of care. These reports may include, but
is not limited to, specific data such as patient outcomes, patient safety, processes of care, workflow
and costs of care. The system needs to provide the report generating capability to easily create
these reports or provide for the export of data to external report generating software.
機能説明: 多くの組織や機関は、ケアの有効性、効率性を支援するのに必要なデータの報告を必要とする。これら報告には、例えば(これに限るわけではないが)、患者アウトカムなどの特定のデータ、
患者安全、ケアのプロセス、ケアのワークフロー、コスト等が挙げられる。システムは、容易に報告を作成する機能、あるいはシステム外のレポート生成ソフトウェアにエキスポートする機能を提供する必要がある。
POP.6.4
1357
Function
Support for Care System
Performance Indicators(Dashboards)
ケアシステム・パーフォ
ーマンス・インディケー
タの 支援 (ダッシュボ ード)Statement: Capture, determine and render data necessary to support health care organizational
performance monitoring and improvement.
機能概要: 医療機関のパーフォーマンスのモニタリングと改善を支援するために必要なデータを取得、決定、表示する。
Description: Health care organizations and institutions may seek to display summary information
to assist in care system performance, in the form of dashboards and graphic displays, to supportdelivery of care and improvement of processes. These dashboards should utilize all appropriate
data available in the system to address the healthcare system's process improvement and caredelivery issues and then display the results in appropriate role-based formats. These displays may
be in the form of routine daily, weekly or monthly graphics or real-time displays of selected metrics
to improve care delivery, and/or performance. Note: Even though the system may be capable ofautomatically managing certain data-driven feedback mechanisms, it is also necessary for theprovider to have the ability of manually managing certain feedback mechanisms (e.g., by
overriding the system's choices).

Section/id#：
Type:
Name:

Conformance Criteria

Row#

機能説明: 医療機関、組織は、ケアの提供およびプロセスの改善のため、ダッシュボードやグラフィックの形で、ケア体制のパーフォーマンスを支援するため、情報の要約の表示を求めるかもしれない。
これらのダッシュボードは、医療提供プロセスの改善とケア提供における問題を把握し、結果を適切なロールベースの形式で表示するため、システムにおける、すべての適切な利用可能なデータを利用すべきである。これらの表示は、ケア提供および/またはパーフォーマンスのための、日常的な、毎日、
毎週、あるいは毎月のグラフィックスであるか、あるいは選択されたメトリックスのリアルタイムの表示であるかもしれない。注意: システムは、自動的にデータ・駆動型のフィードバックを行う機能がある場合であっても、医療提供者が手作業で、(例えば、システムの選択を上書きするなどにより)何等かのフィードバックを管理するメカニズムが必要である。
1. The system SHALL provide the ability to manage data-driven 1358
feedback mechanisms that assist in patient management
and healthcare delivery.
1. システムは、データ駆動型のフィードバックメカニズムを管理する機能を提供しなければならない。
POP.7
1361
Function
Public Health Related
Updates
公衆衛生関連の更新
Statement: Receive and validate formatted inbound communications to facilitate updates to thesystem's public health reporting guidelines.
機能概要:システムの公衆衛生報告ガイドラインの更新を促進するため、フォーマットされた、外から入ってくるコミュニケーションを受信し、バリデートする。
Description: Information and reporting requirements from outside groups, such as public healthorganizations, may be made available to care providers. Examples may include requirements toreport on new disease types, or changes to reporting guidelines. The information in these publichealth updates may be applied to the system so that appropriate data can be collected and reported
to comply with requirements.
機能説明: 公衆衛生機関など、外部からの情報とレポーティングの要求は、ケアの提供者が利用できるようにする場合がある。例えば、新たな疾患のタイプや、報告ガイドラインの変更に関する要求などである。公衆衛生における変更等の情報は、要求に応じて適切なデータが収集され、報告され得るようシステムに適用されるかもしれない。
POP.8
1364
Function 機能
De-Identified
Data
Request Management
匿名化されたデータの要
求マネジメントStatement: Provide patient data in a manner that meets applicable requirements for deidentification.
機能概要: 匿名化に際して適用される要件に適うように、患者データを提供する。
Description: When an internal or external party requests patient data and that party requests deidentified data (or is not entitled to identified patient information, either by law or custom), theuser can export the data in a fashion that meets the requirements for deidentification in that
locale or realm. An auditable record of these requests and associated exports may be maintainedby the system. This record could be implemented in any way that would allow the who, what, why
and when of a request and export to be recoverable for review. A random re-identification key may
be added to the data, to support re-identification for the purpose of alerting providers of potential
patient safety issues. For example, if it is discovered that a patient is at risk for a major cardiac
event, the provider could be notified of this risk, allowing the provider to identify the patient fromthe random key.

Section/id#：
Type:
Name:

Conformance Criteria

Row#

機能説明: 内部あるいは外部から患者データのリクエストがあり、匿名化されたデータをリクエストされた場合(あるいは、法律や慣例により識別可能な患者情報を利用する権限がない場合)、利用者はデータを、その場所や領域における匿名化の要件に適う形でデータをエキスポートする。システムは、
それら要求と関連するエキスポートの監査可能な記録を維持することができる。この記録はリクエス
トとエキスポートが、誰が、何を、なぜ、いつなされたかのレビューのためリカバー可能であるような、いかなる方法でも実装し得る。医療提供者に、潜在的な患者安全の問題をアラートするための再特定化を支援する、ランダムな、再識別キーをデータに追加することができる。例えば、患者が主要な循環器のイベントのリスクにあることが発見されたとき、医療提供者がランダムキーから患者を特定することができるよう、医療提供者に、そのリスクを知らせる。
1. The system SHALL conform to function TI.1.8 (Patient 1365
Privacy and Confidentiality) when managing de-identified
views of data according to scope of practice, organizational
policy, and/or juri1sdictional law.
1. システムは、業務範囲、組織ポリシー、管轄区域の法律に準じて、匿名化されたデータのビューを管理するにあたり機能
TI.1.8 (患者のプライバシーと機密性)に準じなければならない
POP.9
1371
Function 機能
SupportConsistent
Healthcare
Management of PatientGroups or Populations
患者グループまたはポピュレーションの一貫性ある医療マネジメントの支援Statement: Provide the ability to identify and consistently manage healthcare over time andacross populations or groups of patients that share diagnoses, problems, functional limitations,
treatment, medications, and demographic characteristics that may impact care ( e.g., population
management, disease management, wellness management or care management).
機能概要: 診断、プロブレム、機能的制約、治療、投薬、属性等、ケアに影響し得る共通の特徴を有するポピュレーションや患者グループに対して、長期に渡る医療を識別し、一貫性をもって管理する機能を提供する(例えば、ポピュレーション・マネジメント、疾病管理、ウェルネスあるいはケアマネ
ジメント)。
Description: Populations or groups of patients that share diagnoses (such as diabetes or
hypertension), problems, functional limitations, treatment, d, and demographic characteristics
such as race, ethnicity, religion, socio-economic status that may impact care are identified for theclinician. The clinician is advised and assisted with management of these patients to optimize theclinician’s ability to provide appropriate care. For example, a clinician is alerted to information
regarding racial, cultural, religious, socio-economic, living situation and functional limitations of
the patient that are required to provide appropriate care. among other examples are notificationof the patients' eligibility for a particular test, therapy, or follow-up; availability of supportive
resources in the community; or results from audits of compliance of these populations with disease
management protocols. The system may also Include the ability to identify groups of patients
based on clinical observations or laboratory test results and assist in initiating a follow-up or recall
for selected patients. The system may also provide the ability to create and render configurable
reports for specific populations/or topics of interest, (e.g., chronic conditions, suicidal risk, or posttraumatic stress syndrome, traumatic brain injury, etc.)
機能説明: ケアに影響し得る、診断(糖尿病、高血圧等)、プロブレム、機能的制約、治療、投薬、人種や民族性、宗教、社会経済的状態等が共通のポピュレーションあるいは患者グループを、医師に対して識別する。医師が適切なケアの提供を最適化し得るよう、医師に対してこれら患者のマネジメントを助言し支援する。例えば、医師に対して適切なケアを提供するために必要な、患者の人種的、文化的、宗教的、社会経済的、住環境、機能的制約に関する情報に注意を促す。例としては、以下が挙げられる。特定の検査や、治療、あるいはフォローアップに対する患者の適性についての通知; 地域に

Section/id#：
Type:
Conformance Criteria
Row#
Name:
おける支援リソースの利用可能性; これらポピュレーションの疾病管理プロトコルへの適合性に関する監査から得られた結果、など。システムは、さらに臨床的観察や臨床検査の結果に基づいて患者グループを識別し、選択された患者に対するフォローアップやリコールの開始を支援する機能を提供する場合もある。システムは、さらに、特定のポピュレーションあるいは特定の関心事(例えば、慢性的状態、自殺のリスク、心的外傷後ストレス障害、外傷性脳損傷、他)に関する構造化可能な報告を作成し、表示する機能を提供することもできる。
1. The system SHALL conform to function CPS.3.4 (Support for 1372
Context-Sensitive Care Plans, Guidelines, Protocols).
1. システムは、機能 CPS.3.4 (文脈-依存ケアプラン、ガイドライン、プロトコルの支援)に準じなければならない。
2. The system SHALL provide the ability to identify patients 1373
eligible for healthcare management protocols based on
criteria identified within the protocol.
2. システムは、ヘルスケア管理プロトコルのため、プロトコルで定める基準に基づいて患者を識別する機能を提供しなければならない。
6. The system SHALL conform to function CPS.9.4 (Standard 1377
Report Generation).
6. システムは機能 CPS.9.4 (標準報告書生成) に準じなければならない。
8. The system SHALL capture, maintain, and render the 1379
information necessary for patient follow-ups or recalls.
8. システムは、患者の追跡あるいはリコールのために必要な情報を、把握、維持し、表示する機能を提供しなければならない。
9. The system SHALL capture, maintain, and render protocols 1380
and guidelines for follow-ups or recalls.
9. システムはフォローアップやリコールのため、プロトコルやガイドラインを把握、維持し、表示する機能を提供しなければならない。
POP.10FunctionManagePopulation
Health Study-Related
Identifiers
ポピュレーション・ヘル
ス研究関連の識別子の管理Statement: Manage information that identifies key elements of a research or population study.
機能概要: 研究やポピュレーション調査のキー要素を識別する情報を管理する。
Description: Research or population studies can be distinguished from each other through theproper use of identifiers for key elements. Study key elements may include identifying the study,
location where the study is being performed, patient subject of study, and investigator. Identifiers
are managed through their lifecycle including capture, maintenance and rendering.
機能説明: 研究やポピュレーション調査は、キーとなる要素の識別子を適切に用いることで相互に識別できる。研究のキー要素には、研究調査、実施場所、 患者対象者、および研究者などがある。識別
子は、そのライフサイクルを通じて、取得、維持、表示等の管理がなされる。
2. The system SHALL provide the ability to manage the site 1385
identification number(s) as assigned by the Sponsor.
2. システムはスポンサーが割り当てた、サイト識別番号を管理する機能を提供しなければならない。
3. (e.g., these identifiers could be used as a screening number 1386
prior to the subject qualifying for the clinical trial). Note: A
given patient may have multiple research subject identifiers
if the patient has been on multiple research studies.

Section/id#：
Type:
Name:

Conformance CriteriaRow#

3. システムは、ユニークな研究対象識別子(例えば、これら識別子
は治験への参加基準にスクリーニング番号として使用されるかもしれない)を管理する機能を提供しなければならない。留意事項: 患者は、複数の研究に参加していると複数の研究対象
者識別子をもっている可能性がある。

6. Record Infrastructure Section
Section/id#：
Type:
Name:
RI.1
HeaderRecord Lifecycle andLifespan
記録のライフサイクルとライフスパン

Conformance Criteria

Row#
1695

Statement: Manage Record Lifecycle and Lifespan
機能概要：記録のライフサイクルとライフスパンの管理
Description: Actions are taken to support patient health. Actions are taken in provision ofhealthcare to individuals. Actions are taken as the result of rules-based EHR System algorithms.
Actors (i.e., patients, providers, users, systems) take Actions. (Actions broadly encompass tasks,
acts, procedures or services performed or provided.) The EHR System captures Actions taken andcreates corresponding Record Entries. Record Entries provide persistent evidence of Action
occurrence, context, disposition, facts, findings and observations. From the point of Record Entry
origination to the end of its lifespan, the EHR System manages each Entry consistent with andaccording to scope of practice, organizational policy, and jurisdictional law. In support of individual
health and in provision of healthcare to individuals, Actors perform Actions and Actions havecorresponding Entries in the EHR Record, (i.e., Action instances are documented by Record Entry
instances). Record Entries may be captured during the course of the Action or sometime thereafter.
The Actor (author/source) of the Record Entry may be the same as an Actor performing the Action
or not. The EHRS Functional Model does not specify a particular relationship of Actions andcorresponding Record Entries. It may be one to one, many to one or even one to many. Actions
have associated metadata (e.g., who, what, when, where, why, how, under what conditions, in what
context). The corresponding Record Entry captures this metadata along with other Action andRecord Entry related information.
機能説明：患者の健康をサポートするためにアクションが起こされる。個人に対して健康管理を提供
するアクションが起こされる。規則に基づいた EHR システムのアルゴリズムの結果としてアクションが起こされる。アクター（即ち、患者、医療供給者、ユーザ、システム）がアクションを起こす。
（アクションは広義には実行あるいは提供されるタスク、行動、手順あるいはサービスを包含している。
）EHR システムは起こされたアクションを保存し、対応する記録入力を生成する。記録入力はアクションの生成、コンテキスト、性質、現状、所見および観察の永続的な証跡を提供する。記録入力の開始時点からそのライフスパンの終了まで、EHR システムは各入力を業務の範囲、組織ポリシー
および管轄法律に矛盾せずかつ準拠して管理する。個人の健康のサポートおよび個人への健康管理の提供において、アクターはアクションを起こし、アクションは対応する EHR システムの記録入力を持つ（つまり、アクションのインスタンスは記録入力のインスタンスによってドキュメント化される）。記録入力はアクションの実行途中か少し後で保存される。記録入力のアクター（創始者/発生源）
はアクションを実行しているアクターと同じであっても違っていてもよい。EHR システム機能モデ
ルはアクションと対応する記録入力の個々の関係を指定することはない。その関係は 1 対 1、多対 1あるいは 1 対多であるかも知れない。アクションは関連するメタデータを持つ（例えば、だれが、なにを、いつ、どこで、なぜ、どのように、どのような条件で、どのような流れの中で）。対応する記録

Section/id#：
Type:
Conformance Criteria
Row#
Name:
入力は他のアクションと関連する情報の記録入力と合わせてこのメタデータを保存する。
Each Record Entry also includes its own provenance metadata such as who (authoring Actor) andwhen (documented). Record Entries may be encapsulated to bind Actor (individual, organization,
and/or system) signatures to data and metadata content and data/time of occurrence. Actions andrelated Record Entries capture a chronology of patient health and healthcare and also achronology of operations and services provided in/by a healthcare enterprise. Record Entries
reflect changes in health information from the time it was created, to the time it was amended,
sent, received, etc. In this manner, each Record Entry serves as persistent evidence of an Action
taken, enabling providers to maintain comprehensive information that may be needed for legal,business, and disclosure purposes. To satisfy these purposes, Record Entries must also be retained
and persisted without alteration. Record Entries have both a lifecycle and a lifespan. Lifecycle
Events include originate, retain, amend, verify, attest, access/view, de-identify, transmit/receive,and more. Lifecycle Events occur at various points in a Record Entry lifespan, always startingwith a point of origination and retention (i.e., when the Entry is first created and stored). A Record
Entry may have a pre and post Event state if content is modified. In this case, the original Record
Entry is preserved (with signature binding) and a new Entry is created (with new signaturebinding). A Record Entry contains data and metadata, in multiple formats, following various
conventions and standards. Included data may be tagged, and/or delimited, structured (concise,encoded, computable), or unstructured (free form, non-computable). Data may be encoded as text,
document, images, audio, waveforms, in ASCII, binary or other encoding. Structured data may becharacterized as being concise, encoded, computable, and may be divided into discrete fields.
Examples of structured health information include:- patient residence (non-codified, but discrete field)- diastolic blood pressure (numeric)- coded laboratory result or observation- coded diagnosis- patient risk assessment questionnaire with multiple-choice answers.
それぞれの記録入力は、だれが（創始アクター）やいつ（ドキュメント化）といった自分自身に由来するメタデータも含んでいる。記録入力はアクター（個人、組織および/またはシステム）のデータおよびメタデータの内容に対する署名とアクションの生成日時を結びつけるためにカプセル化されることもある。アクションと対応する記録入力は患者の健康状態と健康管理の年表となり、また健康管理提供者による作業とサービスの年表ともなる。記録入力は健康情報の中で、記録入力が作成された時点からそれが修正され、転送され、受信される等の時点までの変更を反映している。これにより、各々の記録入力は起こされたアクションの永続的な証跡としての役を果たし、法的、業務的そして開示目的に必要な提供者による包括的な情報の維持を可能とする。これらの目的を満足するために、記録入力は改変されることなく保存、持続されなければならない。記録入力はライフサイクルとライフ
スパンの両方を持つ。ライフサイクルイベントには生成、保存、修正、確認、認証、アクセス/閲覧、
無名化、転送/受信などが含まれる。ライフサイクルイベントは記録入力のライフスパンの様々なポイントで発生するが、常に生成と保存の時点から始まる（つまり、入力が最初に作られ保存された時）。
記録入力は内容が修正された場合、その前後のイベント状態を持つことがある。この場合、オリジナ
ルの記録入力は保存され（署名付きで）、新しい入力が作成される（新しい署名を付けて）。記録入力には種々の慣習や標準に従った異なるフォーマットのデータおよびメタデータが含まれる。含まれるデータはタグ付け、そして/あるいはデリミタ挿入、構造化（簡単化、コード化、可算化）、あるいは非構造化（自由形式、非可算）されている。データはテキスト、ドキュメント、画像、音、波形、ASCII
形式、バイナリ形式、あるいは他のコードシステムにコード化されている。構造化データは簡単化、コード化、可算化と特徴付けられ、個別のフィールドに分割可能である。
構造化された健康情報の例には以下のものが含まれる:- 患者住所（体系化されていないが、個別フィールド）- 拡張期血圧（数値）- コード化された検査結果あるいは所見- コード化された診断- 複数の回答選択肢を持つ患者リスクアセスメント質問事項.
Unstructured data may be characterized as being free form, and/or non-computable. Unstructured
health record information is information that is not divided into discrete fields AND not
represented as numeric, enumerated or codified data.

Section/id#：
Type:
Conformance Criteria
Name:
Examples of unstructured health record information include:- text (text message to physician)- word processing document (a letter from a family member)- image (photograph of a patient or a scanned image of insurance card)- multimedia (dictated report or a voice recording).

Row#

非構造化データは自由形式および/あるいは非可算と特徴付けられる。非構造化健康記録情報は個別
フィールドに分割不可能でありかつ数値、可算化、体系化されない情報である。
非構造健康情報の例には以下のものが含まれる:- テキスト（医師に対するテキストメッセージ）- ワープロ文書（家族からの手紙）- 画像（患者の写真や社会保障カードのスキャン画像）- マルチメディア（口述レポートや音声録音）
Context may determine whether data are structured or unstructured. For example, a progress
note
might
be
standardized
andstructuredinsomesystems(e.g.,
Subjective/Objective/Assessment/Plan) but unstructured in other systems. The EHR Systemmanages Record Lifecycle Events for each Record Entry, including pre and post Event record
states, continuity, persistence and related Record Audit Logs.
コンテキストはデータが構造化されているか構造化されていないかで決定される。例えば、プログレ
スノートが標準化され構造化されているシステムもあるが（例：SOAP）構造化されていない他のシステムもある。EHR システムは個々の記録入力に対してその前後のイベント記録状態、継続性、持続性および関係する記録の監査ログを含めて、記録のライフサイクルイベントを管理している。
RI.1.1
1696
Function
Record Lifecycle
記録のライフサイクル
Statement: Manage Record Lifecycle
機能概要：記録のライフサイクル管理
Description: As above References:- ISO 21089: Health Informatics - Trusted End-to-End Information Flows- HL7 EHR Interoperability Model DSTU
- HL7 Electronic Health Record Lifecycle Model DSTU
機能説明：上述の通り。下記参照。
- ISO 21089: Health Informatics - Trusted End-to-End Information Flows- HL7 EHR Interoperability Model DSTU
- HL7 Electronic Health Record Lifecycle Model DSTU
1. The system SHALL conform to function RI.1.2.1 (Manage
Record Entries) as the final step to conclude each Record
Lifecycle Event in RI.1.1 (Record Lifecycle) and all childfunctions.
1. システムは RI.1.1 (記録のライフサイクル)における各記録のライフサイクルイベントを終了させるための最終ステップとして RI.1.2.1 (記録入力の管理)機能とその全ての子
機能を満たさなければならない。
RI.1.1.1
Function
Originate and Retain
Record Entry
記録入力の生成と保存
Statement: Originate and Retain a Record Entry (1 instance)
機能概要：記録入力の生成と保存（1 インスタンス）

1697

1698

Section/id#：
Type:
Name:

Conformance Criteria

Row#

Description: Occurs when Record Entry is originated typically during the course of an Action itself,
to document the Action and context. Record Entry is persistent evidence of Action occurrence andincludes an identified Author or Source is responsible for Record Entry content. Record Entry
contains Metadata about the Action and its circumstances, e.g., who, what, when, where, facts,
findings, observations, etc. An Audit Trigger is initiated to track Record Entry origination andretention. Reference: ISO 21089, Section 12.2.2.
機能説明：このイベントは通常アクション自体が進行している間に記録入力が生成された時に、アクションとコンテキストをドキュメント化するために生じる。記録入力はアクション発生の永続的な証跡であり、記録入力の内容に責任を持つ明確な創始者あるいは発生源を含んでいる。記録入力の内容
はアクションについてのメタデータとその詳細を含んでいる、例：だれが、なにを、いつ、どこで、
事実、所見、観察等。記録入力の生成および保存を追跡するために監査が開始される。参照：ISO 21089,
Section 12.2.2.
1. The system SHALL provide the ability to capture 1699
(originate) a Record Entry instance corresponding to an
Action instance and context.
1. システムはアクションインスタンスとコンテキストに対応
する記録入力インスタンスを取り込む機能を提供しなけ
ればならない。
2. The system SHALL capture a unique instance identifier 1700
for each Record Entry.
2. システムは各記録入力に対しユニークなインスタンス識別
子を保存しなければならない。
3. The system SHALL capture the signature event (e.g., 1701
digital signature) of the origination entry Author,
binding signature to Record Entry content.
3. システムは記録入力への署名と合わせて入力創始者の署名イベント（例：ディジタル署名）を採り込まなければならない。
4. The system SHALL provide the ability to capture both 1702
structured and unstructured content in Record Entries.
4. システムは記録入力内に構造化および非構造化データの両方を取り込む機能を提供しなければならない。
5. The system SHALL provide the ability to capture Record 1703
Entries from information recorded during system
downtime.
5. システムはシステムのダウンタイム期間中に記録された情報から記録入力を取り込む機能を提供しなければならない。
7. The system SHALL provide the ability to capture the 1705
date/time an Action was taken or data was collected if
different than date/time of the Record Entry.
7. システムはアクションが起こされたか記録入力の日時と異なる場合はデータが採取された日時を取り込む機能を提供しなければならない。
RI.1.1.1.1
1710
Function
Evidence of Record
Entry Originate/Retain
Event
記録入力の生成/保存イ
ベントの証跡Statement: Maintain Evidence of Record Entry Originate/Retain Event
機能概要：記録入力の生成/保存イベントの証跡の維持。
Description: Evidence of Record Entry Originate/Retain Event includes key metadata, ensuresSection/id#：
Type:
Conformance CriteriaName:health record integrity (and trust) and enables record audit.

Row#

機能説明：記録入力の生成/保存イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when a Record 1711
Entry is originated and retained.
1. システムは記録入力が生成、保存される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 1712
where Record Entry content is originated.
2. システムは記録入力内容を生成した組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who is 1713
subject of Record Entry content.
3. システムは記録入力内容の主体である患者の ID を採り込
まなければならない。
4. The system SHALL capture identity of the individual(s) 1714
who performed the Action documented in Record Entry
content.
4. システムは記録入力内容中にドキュメント化されたアクションを実行した個人（達）の ID を採り込まなければならない。
5. The system SHALL capture identity of the user who 1715
entered/authored Record Entry content.
5. システムは記録入力内容を入力/作成したユーザの ID を採
り込まなければならない。
6. The system SHALL capture identity of the system 1716
application which originated Record Entry content.
6. システムは記録入力内容を生成したシステムアプリケーシ
ョンの ID を採り込まなければならない。
7. IF the source of Record Entry content is a device, THEN 1717
the system SHALL capture identity of the device.
7. 記録入力の生成源が装置の場合、システムはその装置の IDを採り込まなければならない。
8. The system SHALL capture the Action as evidenced by 1718
Record Entry content.
8. システムは記録入力内容によって証明されるようにアクションを採り込まなければならない。
9. The system SHALL capture the type of Record Event 1719
trigger (i.e., originate/retain).
9. システムは記録イベントトリガのタイプ（つまり生成/保存）を採り込まなければならない。
10. The system SHALL capture the date and time of Action 1720
occurrence as evidenced by Record Entry content.
10. システムは記録入力内容によって証明されるようにアクションが起こった日時を採り込まなければならない。
11. The system SHALL capture the date and time Record 1721
Entry content is originated.
11. システムは記録入力内容が生成された日時を採り込まなければならない。
RI.1.1.2
1728
Function
Amend Record Entry
Content
記録入力内容の修正
Statement: Amend content of a Record Entry (1 instance)

Section/id#：
Type:
Name:

Conformance Criteria

Row#

機能概要：記録入力内容の修正（1 インスタンス）
Description: Occurs when Record Entry content is modified (from its original or previously
retained state) – typically upon conclusion of an Action, to correct, update or complete content.Amended Record Entry content is the responsibility of authorized amendment Author(s).- The
amendment becomes part of the Act Record revision history, where the original content and any
previous amendments are retained without alteration.- After amendment, the System is
responsible for retention of the Record Entry and its revision history.- An Audit Trigger is initiatedto track Record Entry amendment. Reference: ISO 21089, Section 12.3.2
機能説明：このイベントは記録入力が修正された時（そのオリジナルあるいはその前の保存状態から）に生じる。－通常はアクションの結果として訂正、更新あるいは内容を確定させるため。- 修正された記録入力内容は権限のある修正者の責任である。- 修正は記録の改訂履歴の一部となり、改訂履歴
においてはオリジナルの内容と過去のどの修正内容も置換なく保存される。- 修正後は、システムは記録入力の保存と改訂履歴に対して責任を持つ。- 記録入力の修正を追跡するための監査が開始される。参照：ISO 21089, Section 12.3.2
1. The system SHALL provide the ability to update (amend) 1729
Record Entry content.
1. システムは記録入力内容を更新（修正）する機能を提供しなければならない。
2. The system SHALL maintain the original and all 1730
previously amended versions of the Record Entry,
retaining each version instance without alteration.
2. システムはオリジナルと全ての過去の修正内容を各々の更新インスタンスを置換することなく保存することで維持しなければならない。
3. The system SHALL capture a new uniquely identifiable 1731
version of the Record Entry, incorporating amended
content.
3. システムは新たにユニークに識別可能なバージョンの記録
入力を修正された内容とともに採り込まなければならない。
4. The system SHALL capture the signature event (e.g., 1732
digital signature) of the amendment Author, binding
signature to Record Entry content.
4. システムは修正者の署名イベント（例：ディジタル署名）を記録入力内容に署名を付けて採り込まなければならな
い。
RI.1.1.2.1
1733
Function
Evidence of Record
Entry
Amendment
Event
記録入力の修正イベントの証跡
Statement: Maintain Evidence of Record Entry Amendment Event
機能概要：記録入力の修正イベントの証跡の維持。
Description: Evidence of Record Entry Amendment Event includes key metadata, ensures healthrecord integrity (and trust) and enables record audit.
機能説明：記録入力修正イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when a Record 1734
Entry is amended.
1. システムは記録入力が修正される都度それを監査しなけれSection/id#：
Type:
Name:

Conformance Criteria
ばならない。
2. The system SHALL capture identity of the organization
where Record Entry content is amended.
2. システムは記録入力内容を修正した組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who issubject of amended Record Entry content.
3. システムは修正された記録入力内容の主体である患者のID を採り込まなければならない。
4. The system SHALL capture identity of the user who
entered/authored Record Entry content amendment.
4. システムは記録入力内容の修正を入力/作成したユーザのID を採り込まなければならない。
5. The system SHALL capture identity of the systemapplication which amended Record Entry content.
5. システムは記録入力内容を修正したシステムアプリケーシ
ョンの ID を採り込まなければならない。
6. The system SHALL capture the type of Record Event
trigger (i.e., amendment).
6. システムは記録イベントトリガのタイプ（つまり修正）を採り込まなければならない。
7. The system SHALL capture the date and time Record
Entry content is amended.
7. システムは記録入力内容が修正された日時を採り込まなけ
ればならない。
10. The system SHALL capture a sequence identifier for
amended Record Entry content.
10. システムは修正された記録入力内容に対してシーケンス
ID を採り込まなければならない。

RI.1.1.3
FunctionTranslate Record Entry
Content
記録入力内容の変換

Row#

1735

1736

1737

1738

1739

1740

1743

1745

Statement: Translate content of Record Entries (1 or more instances)
機能概要：記録入力内容の変換（1 以上のインスタンス）
Description: Occurs when Record Entries are amended to include translation of content – typicallyto transform coded data from one coding/classification scheme to another, also from one humanlanguage to another.- Translated (amended) Record Entry content is the responsibility oftranslating System – which invokes mapping/translation rules for each relevant record attribute.The translation amendment becomes part of the Record Entry revision history, where originalcontent and any previous amendments are retained without alteration.- After translation
amendment, the System is responsible for retention of the Record Entry and its revision history(including the translation event).- An Audit Trigger is initiated to track Record Entry translation.
Reference: ISO 21089, Sections 12.3.2 and 12.4.
機能説明：このイベントは記録入力が内容の変換を採り込むために修正された時に発生する。－通常はコードデータをあるコード/分類体系から別の体系に、あるいはまたある言語から別の言語に変換するため。- 変換（修正）された記録入力内容は変換システムの責任である－変換システムは各該当する記録のアトリビュートに対してマッピング/変換ルールを適用する。- 変換修正は記録の改訂履歴の一部となり、改訂履歴においてはオリジナルの内容と過去のどの修正内容も置換なく保存される。
- 変換修正後は、システムは記録入力の保存と改訂履歴（変換イベントを含む）に対して責任を持つ。
- 記録入力の変換を追跡するための監査が開始される。参照：ISO 21089, Sections 12.3.2 and 12.4.
1. The system SHALL provide the ability to render coded 1746
RecordEntrycontenttranslated
from
one

Section/id#：
Type:
Name:

Conformance Criteria

Row#

coding/classification system to another.
1. システムはあるコード/分類体系から他の体系へ変換されたコード化記録入力内容を表示する機能を提供しなければならない。
2. The system SHALL provide the ability to render coded
Record Entry content translated from one value set toanother.
2. システムはある値セットから他のセットへ変換されたコー
ド化記録入力内容を表示する機能を提供しなければなら
ない。

1747

RI.1.1.3.1
Function
Evidence of Record
Entry Translate Event
記録入力の変換イベント
の証跡

1751

Statement: Maintain Evidence of Record Entry Translate Event
機能概要：記録入力の変換イベントの証跡の維持。
Description: Evidence of Record Entry Translate Event includes key metadata, ensures healthrecord integrity (and trust) and enables record audit.
機能説明：記録入力変換イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when Record 1752
Entry content is translated.
1. システムは記録入力が変換される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 1753
where Record Entry content is translated.
2. システムは記録入力内容を変換した組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who is 1754
subject of translated Record Entry content.
3. システムは変換された記録入力内容の主体である患者のID を採り込まなければならない。
4. IF a user initiated a Record Entry content translation, 1755
THEN the system SHALL capture identity of the user
initiating Record Entry content translation.
4. ユーザが記録入力内容の変換を行った場合、システムは記録入力内容の変換を行ったユーザの ID を採り込まなければならない。
5. The system SHALL capture identity of the system 1756
application which translated Record Entry content.
5. システムは記録入力内容を変換したシステムアプリケーシ
ョンの ID を採り込まなければならない。
6. The system SHALL capture the type of Record Event 1757
trigger (i.e., translation).
6. システムは記録イベントトリガのタイプ（つまり変換）を採り込まなければならない。
7. The system SHALL capture the date and time Record 1758
Entry content is translated.
7. システムは記録入力内容が変換された日時を採り込まなけ
ればならない。
10. The system SHALL capture a sequence identifier for 1761
translated Record Entry content.

Section/id#：
Type:
Name:

Conformance Criteria
10. システムは変換された記録入力内容に対してシーケンス
ID を採り込まなければならない。
11. The system SHALL capture the identifier and version ofTranslation Tools used for each translated Record Entry.
11. システムは各記録入力の変換に使用された変換ツールのID とバージョンを採り込まなければならない。
12. The system SHALL capture a reference (e.g., link,pointer) to pre-translation data for each Record Entry
translation.
12. システムは各記録入力の変換に対してプリ変換データへの参照（例：リンクポインタ）を採り込まなければならな
い。

RI.1.1.4
Function
Attest Record Entry
Content
記録入力内容の認証

Row#

1762

1763

1764

Statement: Attest to content of Record Entry (1 instance)
機能概要：記録入力内容の認証（1 インスタンス）
Description: Occurs when Record Entry content is attested for accuracy and completeness –typically during/after conclusion of an Action. - Attested Record Entry content is the responsibilityof Attesting Author. The Attesting Author may be someone other than the originating Author, i.e.,a supervisor, proctor, preceptor or other designated individual. - An Audit Trigger is initiated to
track Record Entry attestation. The purpose of attestation is to show authorship and assign
responsibility for an act, event, condition, opinion, or diagnosis. Every Record Entry must be
identified with the author and should not be made or signed by someone other than the author
unless they have authority to do so. For example, a resident may author Record Entry content but
the person taking legal authority for the content is the “attester” – both individuals should be
identified. (Note: A transcriptionist may transcribe an author's notes and a senior clinician may
attest to the accuracy of another's statement of events.)- Author: All users who create or contributecontent and have a role in the development of a Record Entry. Some entries may be created by anauthor whose role is a student, transcriber or scribe. - Attester: A user who takes legal authority
for Record Entry content. The attester is often the same as the author, but they may also be anindividual with authority to take responsibility for Record Entry content created in whole or inpart by another author(s) (e.g., student, scribe, transcriptionist).Reference: ISO 21089, Section
12.2.2.
機能説明：このイベントは記録入力内容の正確性、完全性が認証される場合に発生する。－通常はアクションの終了時/終了後。- 認証された記録入力内容は認証者の責任である。認証者は記録入力内容の原作者以外でもよい、つまり、指導者、監督者、教官あるいは他の指定された個人等。-記録入力の認証を追跡するための監査が開始される。認証の目的は作成者を明確にし、行為、イベント、状況、所見、診断に対する責任を与えることである。各記録入力は作成者が同定されなければならず、権限がない限り作成者以外の他者によって作成あるいは署名されてはならない。例えば、研修医が記録入力内容を作成することがあるが、その内容に対して法的に作成責任を持つのは認証者である。－ そして両者は識別されなければならない。
（注：トランスクライバは作成者の原稿を清書し、上級医師が作成者の記述内容の正確さを認証できる。）- 作成者：内容の作成あるいは支援をし、記録入力の制作に役割を果たした全てのユーザ。なかには学生、トランスクライバあるいは筆記人が作成者として作られた入力もある。- 認証者：法的に記録入力内容に作成責任を持つユーザ。認証者は作成者自身であることも多いが、全てあるいは部分的に他の作成者（学生、筆記人、トランスクライバ）によって作成された記録入力内容に対して責任をとる職権を持った個人でもある。参照：ISO 21089, Section
12.2.2.
1. The system SHALL conform to function TI.1.1 (Entity 1765
Authentication).
1. システムは TI.1.1(Entity Authentication)機能を満たさなければならない。

Section/id#：
Type:
Name:

Conformance CriteriaRow#

2. The system SHALL conform to function TI.1.2 (Entity
Authorization).
2. システムは TI.1.2(Entity Authorization)機能を満たさなければならない。
3. The system SHALL provide the ability to attest (approveand apply signature to) Record Entry content by theauthor.
3. システムは作成者によって記録入力内容を認証する（承認し署名を付ける）機能を提供しなければならない。
4. The system SHALL capture the signature event (e.g.,
digital signature) of the Attesting Author, binding
signature to Record Entry content.
4. システムは認証作成者の署名イベント（例：ディジタル署名）を記録入力内容への署名と合わせて採り込まなければならない。
5. The system SHALL provide the ability to maintain any
attestable Record Entry content added or changed withthe content's author.
5. システムは記録入力内容の作成者によって追加、変更された全ての認証可能な記録入力内容を維持する機能を提供しなければならない。
6. The system SHALL present the status of attestable
Record Entry content which has not been attested,
conforming to function RI.1.3.1 (Record Pending State).
6. システムは RI.1.3.1（記録のペンディング状態）機能に従って、まだ認証されていない認証可能な記録入力内容の状態を表示しなければならない。
7. IF the attester is different than the author(s), THEN thesystem SHALL provide the ability to maintain Record
Entry content by properly authenticated and authorizedusers different from the author (e.g., counter-signature)according to scope of practice, organizational policy,
and/or jurisdictional law.
7. 認証者が作成者と異なる場合、システムは業務の範囲、組織ポリシーおよび管轄法律に従って、作成者とは異なる適
切に認証、権限を付与されたユーザ（例：副署名）によって記録入力内容を維持する機能を提供しなければならない。
9. IF more than one author contributed to the Record Entry
content, THEN the system SHALL provide the ability tomaintain all authors/contributors associated with theircontent.
9. 記録入力内容に対して複数人の作成者がいる場合、システ
ムはその内容の全ての作成者/貢献者を維持する機能を提供しなければならない。
10. IF Record Entry content is attested by someone otherthan the author, THEN the system SHALL maintain anddisplay the author(s) and attester.
10. 記録入力内容が作成者以外によって認証された場合、システムは作成者と認証者を維持、表示する機能を提供しなけ
ればならない。
11. The system SHALL provide the ability to define andpresent a minimum data set of author information to be
displayed with Record Entry content or as outputs
according to scope of practice, organizational policy,
and/or jurisdictional law (e.g., name, credential, and/or
position such as K. Smith, RN).

1766

1767

1768

1769

1770

1771

1773

1774

1775

Section/id#：
Type:
Name:

RI.1.1.4.1
Function
Evidence of Record
Entry Attestation Event
記録入力認証イベントの証跡

Conformance CriteriaRow#

11. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、記録入力内容と合わせてあるいは出力として表示されるべき作成者情報の最低限のデータセットを定義、提示する機能を提供しなければならない（例：名前、資格証明、および/あるいは K. Smith, RN（Registered
Nurse）のような地位）。
12. The system SHALL capture the signature type of the 1776
entity (individual, EHR or other system, or organization)
sending Record Entry content.
12. システムは記録入力内容を送信するエンティティ（個人、EHR あるいは他のシステム、あるいは組織）の署名タイプを採り込まなければならない。
13. The system SHALL capture the signature type of the 1777
entity (individual, EHR or other system, or organization)
receiving Record Entry content.
13. システムは記録入力内容を受信するエンティティ（個人、EHR あるいは他のシステム、あるいは組織）の署名タイプを採り込まなければならない。
14. The system SHALL capture all signature types of the 1778
entities through which Record Entry content has passed.
14. システムは記録入力内容が渡った全てのエンティティの署名タイプを採り込まなければならない。
1779

Statement: Maintain Evidence of Record Entry Attestation Event
機能概要：記録入力認証イベントの証跡の維持
Description: Evidence of Record Entry Attestation Event includes key metadata, ensures healthrecord integrity (and trust) and enables record audit.
機能説明：：記録入力認証イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence of Record 1780
Entry attestation (signature event).
1. システムは記録入力が認証（署名イベント）される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 1781
where Record Entry content attestation (signature
event) occurred.
2. システムは記録入力内容を認証（署名イベント）した組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who is 1782
subject of attested Record Entry content.
3. システムは認証された記録入力内容の主体である患者のID を採り込まなければならない。
4. The system SHALL capture identity of the user attesting 1783
to Record Entry content (signature event).
4. システムは記録入力内容の認証（署名イベント）を行った
ユーザの ID を採り込まなければならない。
5. The system SHALL capture identity of the system 1784
application in which Record Entry content attestation(signature event) occurred.

Section/id#：
Type:
Name:

RI.1.1.5
Function
View/Access
RecordEntry Content
記録入力内容の閲覧/ア
クセス

Conformance CriteriaRow#

5. システムは記録入力内容を認証（署名イベント）したシス
テムアプリケーションの ID を採り込まなければならない。
6. The system SHALL capture the type of Record Event 1785
trigger (i.e., attestation/signature event).
6. システムは記録イベントトリガのタイプ（つまり認証/署名イベント）を採り込まなければならない。
7. The system SHALL capture the date and time of Record 1786
Entry content attestation (signature event).
7. システムは記録入力内容が認証（署名イベント）された日
時を採り込まなければならない。
9. The system SHALL capture the data, document or other 1788
identifier for attested Record Entry content.
9. システムは認証された記録入力内容に対するデータ、ドキュメントあるいは他の ID を採り込まなければならない。
1789

Statement: View/Access content of Record Entries (1 or more instances)
機能概要：記録入力内容の閲覧/アクセス（1 以上のインスタンス）
Description: Occurs when Record Entry content is viewed or accessed. - Viewed Record Entry
content is the responsibility of authorized User(s). - An Audit Trigger is initiated to track Record
Entry views and access. Reference: ISO 21089, Section 12.5.
機能説明：このイベントは記録入力内容が閲覧されたりアクセスされたりした場合に発生する。- 閲
覧された記録入力内容は権限を与えられたユーザの責任である。-記録入力の閲覧やアクセスを追跡するための監査が開始される。参照：ISO 21089, Section 12.5.
2. The system SHALL provide the ability to render Record 1791
Entry content, including original version and any
subsequent amendments.
2. システムはオリジナルのバージョンおよびその後の修正を含め記録入力内容を表示する機能を提供しなければならない。
3. The system SHALL provide the ability to render Record 1792
Entry content down to the discrete element or item,
including encoded fields.
3. システムは記録入力内容を個々の要素あるいは項目に至る
まで、コード化されたフィールドを含めて表示する機能を提供しなければならない。
RI.1.1.5.1
1793
Function
Evidence of Record
Entry
View/Access
Event
記録入力の閲覧/アクセ
スイベントの証跡
Statement: Maintain Evidence of Record Entry View/Access Event
機能概要：記録入力閲覧/アクセスイベントの証跡の維持
Description: Evidence of Record Entry View/Access Event includes key metadata, ensures healthrecord integrity (and trust) and enables record audit.

Section/id#：
Type:
Name:

Conformance Criteria

Row#

機能説明：記録入力の閲覧/アクセスイベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when Record 1794
Entry content is viewed/accessed.
1. システムは記録入力が閲覧/アクセスされる都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 1795
where Record Entry content is viewed/accessed.
2. システムは記録入力内容を閲覧/アクセスした組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who is 1796
subject of the viewed/accessed Record Entry content.
3. システムは閲覧/アクセスされた記録入力内容の主体である患者の ID を採り込まなければならない。
4. The system SHALL capture identity of the user who 1797
viewed/accessed Record Entry content.
4. システムは記録入力内容の閲覧/アクセスを行ったユーザの ID を採り込まなければならない。
5. The system SHALL capture identity of the system 1798
application in which Record Entry content isviewed/accessed.
5. システムは記録入力内容を閲覧/アクセスしたシステムア
プリケーションの ID を採り込まなければならない。
6. The system SHALL capture the type of Record Event 1799
trigger (i.e., view/access).
6. システムは記録イベントトリガのタイプ（つまり閲覧/アクセス）を採り込まなければならない。
7. The system SHALL capture the date and time Record 1800
Entry content is viewed/accessed.
7. システムは記録入力内容が閲覧/アクセスされた日時を採り込まなければならない。
10. The system SHALL capture the data, document or other 1803
identifier for the viewed/accessed Record Entry content.
10. システムは閲覧/アクセスされた記録入力内容に対するデータ、ドキュメントあるいは他の ID を採り込まなければならない。
12. The system SHALL capture when a Record Entry 1805
content view/access occurrence a disclosure, according toscope of practice, organizational policy, and/or
jurisdictional law.
12.システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、記録入力内容の閲覧/アクセスの発生が開示のためであると分かっている場合採り込まなければならな
い。
RI.1.1.6
1807
Function
Output/Report Record
Entry Content
記録入力内容の出力/報告Statement: Output/Report content of Record Entries (1 or more instances)
機能概要：記録入力内容の出力/報告（1 以上のインスタンス）
Description: Occurs when Record Entry content is output or reported.
- Output/reported Record Entry content is the responsibility of authorized User(s).

Section/id#：
Type:
Conformance Criteria
Name:- An Audit Trigger is initiated to track Record Entry content outputs and reports.
Reference: ISO 21089, Section 12.5.

Row#

機能説明：このイベントは記録入力内容が出力されたり報告されたりした場合に発生する。- 出力/報
告された記録入力内容は権限を与えられたユーザの責任である。-記録入力の出力や報告を追跡するための監査が開始される。参照：ISO 21089, Section 12.5.
2. The system SHALL provide the ability to output/report 1809
Record Entry extracts, including content, context,
provenance and metadata.
2. システムは内容、コンテキスト、出所、メタデータを含む
記録入力内容を出力/報告する機能を提供しなければならない。
3. The system SHALL identify the patient or individual 1810
subject of output/reported Record Entry content.
3. システムは出力/報告対象の記録入力内容の主体である患者あるいは個人を識別しなければならない。
6. The system SHALL conform to function TI.1.6 (Secure 1813
Data Exchange).
6. システムは TI.1.6（セキュアなデータ交換）機能を満たさなければならない。
7. The system SHALL provide the ability to extract Record 1814
Entry content prior to output/report, conforming tofunction RI.1.1.13 (Extract Record Entry Content).
7. システムは RI.1.1.13（記録入力内容の抽出）機能に従って、
出力/報告に先立って記録入力内容を抽出する機能を提供しなければならない。
8. The system SHALL provide the ability to de-identify 1815
Record Entry content prior to output/report, conforming
to function RI.1.1.10 (De-Identify Record Entries).
8. システムは RI.1.1.10（記録入力の無名化）機能に従って、
出力/報告に先立って記録入力内容を無名化する機能を提供しなければならない。
9. The system SHALL provide the ability to output/report 1816
updates (new versions) of Record Entry Content toknown recipients of prior versions according to scope ofpractice, organizational policy, and/or jurisdictional law.
9．システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、既知の以前のバージョンの受領者に記録入力
内容の更新（新バージョン）を出力/報告する機能を提供しなければならない。
RI.1.1.6.1
1817
Function
Evidence of Record
Entry
Output/Report
Event
記録入力内容の出力/報告イベントの証跡
Statement: Maintain Evidence of Record Entry Output/Report Event
機能概要：記録入力内容の出力/報告イベントの証跡の維持
Description: Evidence of Record Entry Output/Report Event includes key metadata, ensures
health record integrity (and trust) and enables record audit.
機能説明：記録入力内容の出力/報告イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when an 1818

Section/id#：
Type:
Name:

Conformance Criteria
output (e.g., report, screen shot) is generated from
Record Entry content.
1. システムは記録入力内容から出力（例：報告、スクリーンショット）が生成される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization
where output/report is generated from Record Entry
content.
2. システムは記録入力内容から出力/報告を生成した組織のID を採り込まなければならない。
3. The system SHALL capture identity of the patient who issubject of the Record Entry(ies) populating theoutput/report generated.
3. システムは生成された出力/報告に収められた記録入力内容の主体である患者の ID を採り込まなければならない。
4. The system SHALL capture identity of the user who
generated the output/report of Record Entry content.
4. システムは記録入力内容の出力/報告の生成を行ったユー
ザの ID を採り込まなければならない。
5. The system SHALL capture identity of the systemapplication from which the output/report is generated.
5. システムは記録入力内容の出力/報告を生成したシステム
アプリケーションの ID を採り込まなければならない。
6. The system SHALL capture the type of Record Event
trigger (i.e., output/report).
6. システムは記録イベントトリガのタイプ（つまり出力/報告）を採り込まなければならない。
7. The system SHALL capture the date and time theoutput/report is generated.
7. システムは記録入力内容の出力/報告が生成された日時を採り込まなければならない。
11. The system SHALL capture when a Record Entry
content output/report occurrence is known to be adisclosure, according to scope of practice, organizational
policy, and/or jurisdictional law.
11. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、記録入力内容の出力/報告の発生が開示のためであると分かっている場合採り込まなければならない。

RI.1.1.7
Function
Disclose Record Entry
Content
記録入力内容の開示

Row#

1819

1820

1821

1822

1823

1824

1828

1830

Statement: Disclose content of Record Entries.
機能概要：記録入力内容の開示
Description: Occurs when Record Entry content is disclosed according to scope of practice,organizational policy or jurisdictional law.- Disclosed Record Entry content is the responsibility ofauthorized User(s).- An Audit Trigger is initiated to track Record Entry content disclosures.
Reference: ISO 21089, Section 12.5.
機能説明：このイベントは業務の範囲、組織ポリシーおよび/または管轄法律に従って、記録入力内容が開示された場合に発生する。- 開示された記録入力内容は権限を与えられたユーザの責任である。
-記録入力の開示を追跡するための監査が開始される。参照：ISO 21089, Section 12.5.
1. The system SHALL identify the patient or individual 1831
subject of transmitted/disclosed Record Entry content.

Section/id#：
Type:
Name:

RI.1.1.7.1
Function
Evidence of Record
Entry Disclosure Event
記録入力開示イベントの証跡

Conformance CriteriaRow#

1．システムは転送/開示された記録入力内容の主体である患者
あるいは個人を識別しなければならない。
2. The system SHALL capture a log entry for disclosure of 1832
protected Record Entry content, according to scope ofpractice, organizational policy, and/or jurisdictional law.
2. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、保護された記録入力内容の開示に対してのロ
グ入力を採り込まなければならない。
5. The system SHALL conform to function TI.1.6 (Secure 1835
Data Exchange).
5. システムは TI.1.6(Secure Data Exchange)機能を満たさなければならない。
6. The system SHALL provide the ability to extract Record 1836
Entry content prior to disclosure, conforming to function
RI.1.1.13 (Extract Record Entry Content).
6. システムは RI.1.1.13 (記録入力内容の抽出).機能に従って、開示に先立って記録入力内容を抽出する機能を提供しなければならない。
7. The system SHALL provide the ability to de-identify 1837
Record Entry content prior to disclosure, conforming tofunction RI.1.1.10 (De-Identify Record Entries).
7. システムは RI.1.1.10（記録入力の無名化）機能に従って、開示に先立って記録入力内容を無名化する機能を提供しなければならない。
1838

Statement: Maintain Evidence of Record Entry Disclosure Event.
機能概要：記録入力開示イベントの証跡の維持
Description: Evidence of Record Entry Disclosure Event includes key metadata, ensures healthrecord integrity (and trust) and enables record audit.
機能説明：記録入力内容の開示イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when Record 1839
Entry content is disclosed according to scope of practice,organizational policy, and/or jurisdictional law.
1. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、記録入力内容が開示される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 1840
from which Record Entry content is disclosed.
2. システムは記録入力内容を開示した組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who is 1841
subject of Record Entry content disclosed.
3. システムは開示された記録入力内容の主体である患者のID を採り込まなければならない。
4. The system SHALL capture identity of the user initiating 1842
disclosure of Record Entry content.
4. システムは記録入力内容の開示を行ったユーザの ID を採
り込まなければならない。

Section/id#：
Type:
Name:

Conformance CriteriaRow#

5. The system SHALL capture identity of the systemapplication from which Record Entry content is disclosed.
5. システムは記録入力内容の開示を行ったシステムアプリケーションの ID を採り込まなければならない。
6. The system SHALL capture the type of Record Event
trigger (i.e., disclose).
6. システムは記録イベントトリガのタイプ（つまり開示）を採り込まなければならない。
7. The system SHALL capture the date and time Record
Entry content is disclosed.
7. システムは記録入力内容が開示された日時を採り込まなけ
ればならない。
11. The system SHALL capture that this is an occurrence
when Record Entry content is known to be disclosed,
according to scope of practice, organizational policy, and/or
jurisdictional law.
11. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、記録入力内容が開示されると分かっている場
合の開示であるということを採り込まなければならない。

1843

RI.1.1.8
FunctionTransmit Record Entry
Content
記録入力内容の転送

1844

1845

1849

1851

Statement: Transmit content of Record Entries (1 or more instances)
機能概要：記録入力内容の転送（1 以上のインスタンス）
Description: Occurs when Record Entry content is transmitted – typically to an external entity orsystem. - Transmittal may include original Record Entry content with subsequent amendment(s),if any. - Transmittal of Record Entries is the responsibility of the System – which invokes relevant
rules. - An Audit Trigger is initiated to track Record Entry transmittal. Reference: ISO 21089,
Section 12.8.1.
機能説明：このイベントは記録入力内容が転送された場合に発生する。－通常は外部のエンティティ
やシステムへ。- 転送処理はオリジナルの記録入力内容とその後の修正内容があればそれを含む。記
録入力内容の転送処理はシステムの責任である － システムは関連するルールに従う。-記録入力の転送処理を追跡するための監査が開始される。参照：ISO 21089, Section 12.8.1.
2. The system SHALL provide the ability to transmit Record 1853
Entry extracts to external systems, including content,
context, provenance and metadata.
2. システムは内容、コンテキスト、出所、メタデータを含む
記録入力内容を外部システムに転送する機能を提供しなければならない。
3. The system SHALL identify the patient or individual 1854
subject of transmitted Record Entry content.
3. システムは転送された記録入力内容の主体である患者ある
いは個人を識別しなければならない。
6. The system SHALL conform to function TI.1.6 (Secure 1857
Data Exchange).
6. システムは TI.1.6(Secure Data Exchange)機能を満たさなければならない。
7. The system SHALL provide the ability to extract Record 1858
Entry content prior to transmittal, conforming tofunction RI.1.1.13 (Extract Record Entry Content).
7. システムは RI.1.1.13 (記録入力内容の抽出).機能に従って、転送処理に先立って記録入力内容を抽出する機能を提供

Section/id#：
Type:
Name:

RI.1.1.8.1
Function
Evidence of Record
Entry Transmit Event
記録入力内容の転送イベ
ントの証跡

Conformance Criteria

Row#

しなければならない。
8. The system SHALL provide the ability to de-identify 1859
Record Entry content prior to transmittal, conforming tofunction RI.1.1.10 (De-Identify Record Entries).
8. システムは RI.1.1.10（記録入力の無名化）機能に従って、転送処理に先立って記録入力内容を無名化する機能を提供しなければならない。
9. The system SHALL provide the ability to transmit 1860
updates (new versions) of Record Entry Content toknown recipients of prior versions according to scope ofpractice, organizational policy, and/or jurisdictional law.
9. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、既知の以前のバージョンの受領者に記録入力
内容の更新（新バージョン）を転送する機能を提供しなけ
ればならない。
10. The system SHALL provide the ability to transmit with 1861
each exchange the most recent or all versions of Record
Entry Content according to scope of practice,organizational policy, and/or jurisdictional law.
10. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、転送ごとに最新かあるいは全てのバージョンの記録入力内容を転送する機能を提供しなければなら
ない。
1862

Statement: Maintain Evidence of Record Entry Transmit Event
機能概要：記録入力内容の転送イベントの証跡の維持
Description: Evidence of Record Entry Transmit Event includes key metadata, ensures healthrecord integrity (and trust) and enables record audit.
機能説明：記録入力内容の転送イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when Record 1863
Entry content is transmitted.
1．システムは記録入力内容が転送される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 1864
from which Record Entry content is transmitted.
2. システムは記録入力内容を転送した組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who is 1865
subject of Record Entry content transmitted.
3. システムは転送された記録入力内容の主体である患者のID を採り込まなければならない。
4. The system SHALL capture identity of the user initiating 1866
transmission of Record Entry content.
4. システムは記録入力内容の転送を行ったユーザの ID を採
り込まなければならない。
5. The system SHALL capture identity of the system 1867
application which transmitted Record Entry content.
5. システムは記録入力内容の転送を行ったシステムアプリケ

Section/id#：
Type:
Name:

Conformance Criteriaーションの ID を採り込まなければならない。
6. The system SHALL capture identity of the systemapplication which received Record Entry content.
6. システムは記録入力内容を受信したシステムアプリケーシ
ョンの ID を採り込まなければならない。
7. The system SHALL capture the type of Record Event
trigger (i.e., transmit).
7. システムは記録イベントトリガのタイプ（つまり転送）を採り込まなければならない。
8. The system SHALL capture the date and time Record
Entry content is transmitted.
8. システムは記録入力内容が転送された日時を採り込まなけ
ればならない。
10. The system SHALL capture the location (network
address)
to
which
the
RecordEntryistransmitted/disclosed.
10. システムは記録入力が転送/開示された先のロケーション（ネットワークアドレス）を採り込まなければならない。
12. The system SHALL capture the type of Record Entry
content transmitted/disclosed (e.g., original, amended,
updated data).
12. システムは転送/開示された記録入力内容のタイプ（例：オリジナルデータ、修正データ、更新データ）を採り込まなければならない。
15. The system SHALL capture when a Record Entry
transmit occurrence is known to be a disclosure,according to scope of practice, organizational policy,
and/or jurisdictional law.
15. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、記録入力内容が開示されると分かっている
場合の転送であるということを採り込まなければならな
い。

RI.1.1.9
Function
Receive and Retain
Record Entries
記録入力の受信と保存

Row#

1868

1869

1870

1872

1874

1877

1879

Statement: Receive and retain/persist content of Record Entries (1 or more instances)
機能概要：記録入力内容の受信と保存/持続（1 以上のインスタンス）
Description: Occurs when Record Entry content is received – typically from an external system. Receipt of Record Entries is the responsibility of the System – which invokes relevant rules. - An
Audit Trigger is initiated to track Record Entry receipt and retention. Reference: ISO 21089,
Section 12.8.1.
機能説明：このイベントは記録入力内容が受信された場合に発生する。－通常は外部のシステムから。
-記録入力内容の受信はシステムの責任である － システムは関連するルールに従う。-記録入力の受信を追跡するための監査が開始される。参照：ISO 21089, Section 12.8.1.
2. The system SHALL provide the ability to capture and 1881
maintain Record Entry extracts from external systems,
retaining and persisting source, identity, record content,
corresponding provenance and metadata.
2. システムは情報源、ID、記録内容、関連する出所およびメ
タデータを保存/持続することで、内容、コンテキスト、出所、メタデータを含む外部システムから抽出されてきた記録入力を採り込みそして維持する機能を提供しなければSection/id#：
Type:
Name:

Conformance Criteria
ならない。
3. The system SHALL identify the patient or individual
subject of received Record Entry content.
3. システムは受信した記録入力内容の主体である患者あるいは個人を識別しなければならない。

RI.1.1.9.1
Function
Evidence of Record
Entry
Receive/Retain
Event
記録入力の受信/保存イ
ベントの証跡

Row#

1882

1884

Statement: Maintain Evidence of Record Entry Receive/Retain Event
機能概要：記録入力の受信/保存イベントの証跡の維持
Description: Evidence of Record Entry Receive/Retain Event includes key metadata, ensures
health record integrity (and trust) and enables record audit.
機能説明：記録入力内容の受信/保存イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when 1885
externally-sourced Record Entry content is received andretained.
1. システムは外部ソースから記録入力内容が受信/保存される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 1886
transmitting Record Entry content received andretained.
2. システムは受信/保存した記録入力内容の転送元組織の IDを採り込まなければならない。
3. The system SHALL capture identity of the organization 1887
receiving transmitted Record Entry content.
3. システムは記録入力内容を受信/保存した組織の ID を採り込まなければならない。
4. The system SHALL capture identity of the patient who is 1888
subject of received Record Entry content.
4. システムは受信された記録入力内容の主体である患者のID を採り込まなければならない。
5. IF the system supports user verification of receipt of 1889
externally-sourced Record Entry content, THEN thesystem SHALL capture identity of the user accepting
receipt of the transmitted Record Entry content.
5. システムが外部ソースからの記録入力内容の受信のユーザ
検証をサポートしている場合、システムは転送された記録
入力内容の受信を認めたユーザの ID を採り込まなければならない。
6. The system SHALL capture identity of the system 1890
application which transmitted Record Entry content.
6. システムは記録入力内容の転送を行ったシステムアプリケーションの ID を採り込まなければならない。
7. The system SHALL capture identity of the system 1891
application which received Record Entry content.
7. システムは記録入力内容の受信を行ったシステムアプリケーションの ID を採り込まなければならない。
8. The system SHALL capture the type of Record Event 1892
trigger (i.e., receive).

Section/id#：
Type:
Name:

Conformance Criteria
8. システムは記録イベントトリガのタイプ（つまり受信）を採り込まなければならない。
9. The system SHALL capture the date and time Record
Entry content is received.
9. システムは記録入力内容が受信された日時を採り込まなけ
ればならない。
12. The system SHALL capture the type of Record Entry
content received (e.g., original, amended, updated data).
12. システムは受信された記録入力内容のタイプ（例：オリジナルデータ、修正データ、更新データ）を採り込まなければならない。

RI.1.1.10
Function
De-identify
RecordEntries
記録入力の無名化

Row#

1893

1896

1899

Statement: De-identify content of Record Entries (1 or more instances)
機能概要：記録入力内容の無名化（1 以上のインスタンス）
Description: Occurs when Record Entry content is transformed into de-identified version. - Deidentification of Record Entries may be initiated by User command. - De-identification of Record
Entries is the responsibility of the System – which invokes relevant rules. - An Audit Trigger is
initiated to track Record Entry de-identification. Reference: ISO 21089, Section 12.6.1.
機能説明：このイベントは記録入力内容が無名バージョンに変換された場合に発生する。- 記録入力の無名化はユーザコマンドにより開始される。- 記録入力内容の無名化はシステムの責任である －システムは関連するルールに従う。-記録入力の無名化を追跡するための監査が開始される。参照：
ISO 21089, Section 12.6.1.
1. The system SHALL provide the ability to de-identify 1900
Record Entry content according to scope of practice,organizational policy, and/or jurisdictional law.
1. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、記録入力内容の無名化をする機能を提供しなければならない。
RI.1.1.10.1
1901
Function
Evidence of Record
Entry De-Identification
Event
記録入力の無名化イベン
トの証跡Statement: Maintain Evidence of Record Entry De-Identification Event
機能概要：記録入力の無名化イベントの証跡の維持
Description: Evidence of Record Entry De-Identification Event includes key metadata, ensures
health record integrity (and trust) and enables record audit.
機能説明：記録入力内容の無名化イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when Record 1902
Entry content is de-identified.
1. システムは記録入力内容が無名化される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 1903
where Record Entry content is de-identified.

Section/id#：
Type:
Name:

Conformance Criteria
2. システムは記録入力内容を無名化した組織の ID を採り込
まなければならない。
3. The system SHALL capture identity of the patient who issubject of de-identified Record Entry content.
3. システムは無名化された記録入力内容の主体である患者のID を採り込まなければならない。
4. The system SHALL capture identity of the user deidentifying Record Entry content.
4. システムは記録入力内容の無名化を行ったユーザの ID を採り込まなければならない。
5. The system SHALL capture identity of the systemapplication which de-identified Record Entry content.
5. システムは記録入力内容の無名化を行ったシステムアプリ
ケーションの ID を採り込まなければならない。
6. The system SHALL capture the type of Record Event
trigger (i.e., de-identify).
6. システムは記録イベントトリガのタイプ（つまり無名化）を採り込まなければならない。
7. The system SHALL capture the date and time Record
Entry content is de-identified.
7. システムは記録入力内容が無名化された日時を採り込まなければならない。

RI.1.1.11
Function
Pseudomynize Record
Entries
記録入力の仮名化

Row#

1904

1905

1906

1907

1908

1912

Statement: Provide pseudomynized identity for Record Entries (1 or more instances)
機能概要：記録入力の仮名化の提供（1 以上のインスタンス）
Description: Occurs when Record Entry is transformed into an pseudomynized version.Pseudomynization allows records to be later re-identified.- Pseudomynization of Record Entries
may be initiated by User command.- Pseudomynization of Record Entries is the responsibility of
the System – which invokes relevant rules.- An Audit Trigger is initiated to track Record Entry
pseudomynization. Reference: ISO 21089, Section 12.6.1.
機能説明：このイベントは記録入力内容が仮名バージョンに変換された場合に発生する。- 記録入力の仮名化ではあとで実名化が可能である。- 記録入力の仮名化はユーザコマンドにより開始される。
- 記録入力内容の仮名化はシステムの責任である － システムは関連するルールに従う。-記録入力の仮名化を追跡するための監査が開始される。参照：ISO 21089, Section 12.6.1.
1. The system SHALL provide the ability to pseudomynize 1913
(or associate new identity with) patient Record Entries
according to scope of practice, organizational policy,
and/or jurisdictional law.
1. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、記録入力内容の仮名化（あるいは新しい ID に関連付ける）をする機能を提供しなければならない。
RI.1.1.11.1
1914
Function
Evidence of Record
Entry
Pseudomynization
Event
記録入力の仮名化イベン
トの証跡Section/id#：
Type:
Name:

Conformance Criteria

Row#

Statement: Maintain Evidence of Record Entry Pseudomynization Event
機能概要：記録入力の仮名化イベントの証跡の維持
Description: Evidence of Record Entry Pseudomynization Event includes key metadata, ensures
health record integrity (and trust) and enables record audit.
記録入力内容の仮名化イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when a Record 1915
Entry content is pseudomynized.
1．システムは記録入力内容が仮名化される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 1916
where Record Entry content is pseudomynized.
2. システムは記録入力内容を仮名化した組織の ID を採り込
まなければならない。
3. The system SHALL capture identity of the patient who is 1917
subject of pseudomynized Record Entry content.
3. システムは仮名化された記録入力内容の主体である患者のID を採り込まなければならない。
4. The system SHALL capture identity of the user 1918
pseudomynizing Record Entry content.
4. システムは記録入力内容の仮名化を行ったユーザの ID を採り込まなければならない。
5. The system SHALL capture identity of the system 1919
application which pseudomynized Record Entry content.
5. システムは記録入力内容の仮名化を行ったシステムアプリ
ケーションの ID を採り込まなければならない。
6. The system SHALL capture the type of Record Event 1920
trigger (i.e., pseudomynize).
6. システムは記録イベントトリガのタイプ（つまり仮名化）を採り込まなければならない。
7. The system SHALL capture the date and time Record 1921
Entry content is pseudomynized.
7. システムは記録入力内容が仮名化された日時を採り込まなければならない。
RI.1.1.12
1924
Function
Re-identify
RecordEntries
記録入力の実名化
Statement: Re-identify previously aliased identity for content of Record Entries (1 or moreinstances)
機能概要：過去に仮名化された記録入力内容の実名化（1 以上のインスタンス）
Description: Occurs when Record Entries are re-identified from a previously aliased version.- Reidentification of Record Entries is the responsibility of the System – which invokes relevant rules.An Audit Trigger is initiated to track Record Entry re-identification. Reference: ISO 21089, Section
12.6.2.
機能説明：このイベントは過去の仮名化バージョンの記録入力内容が実名化された場合に発生する。
- 記録入力の実名化はユーザコマンドにより開始される。- 記録入力内容の仮名化はシステムの責任である － システムは関連するルールに従う。-記録入力の実名化を追跡するための監査が開始される。参照：ISO 21089, Section 12.6.2.
1. The system SHALL provide the ability to re-identify (or 1925

Section/id#：
Type:
Name:

Conformance CriteriaRow#associate original identity with) Record Entry content
according to scope of practice, organizational policy,
and/or jurisdictional law.
1. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、記録入力内容の実名化（あるいは元の ID に関連付ける）をする機能を提供しなければならない。
RI.1.1.12.1
Function
Evidence of Record
Entry Re-Identification
Event
記録入力の実名化イベン
トの証跡

1926

Statement: Maintain Evidence of Record Entry Re-Identification Event
機能概要：記録入力の実名化イベントの証跡の維持
Description: Evidence of Record Entry Re-Identification Event includes key metadata, ensures
health record integrity (and trust) and enables record audit.
機能説明：記録入力内容の実名化イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when Record 1927
Entry content is re-identified.
1. システムは記録入力内容が実名化される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 1928
where Record Entry content is re-identified.
2. システムは記録入力内容を実名化した組織の ID を採り込
まなければならない。
3. The system SHALL capture identity of the patient who is 1929
subject of re-identified Record Entry content.
3. システムは実名化された記録入力内容の主体である患者のID を採り込まなければならない。
4. The system SHALL capture identity of the user re- 1930
identifying Record Entry content.
4. システムは記録入力内容の実名化を行ったユーザの ID を採り込まなければならない。
5. The system SHALL capture identity of the system 1931
application which re-identified Record Entry content.
5. システムは記録入力内容の実名化を行ったシステムアプリ
ケーションの ID を採り込まなければならない。
6. The system SHALL capture the type of Record Event 1932
trigger (i.e., re-identify).
6. システムは記録イベントトリガのタイプ（つまり実名化）を採り込まなければならない。
7. The system SHALL capture the date and time Record 1933
Entry content is re-identified.
7. システムは記録入力内容が実名化された日時を採り込まなければならない。
RI.1.1.13
1936
Function
Extract Record Entry
Content
記録入力内容の抽出Statement: Extract Record Entry content to produce subsets, derivations, summaries orSection/id#：
Type:
Conformance Criteria
Name:aggregations (Multiple instances)

Row#

機能概要：サブセット、派生物、サマリあるいは集約作成のために記録入力内容を抽出する（複数インスタンス）
Description: Occurs when Record Entry content is extracted to render subsets, derivations,summaries or aggregations. - Extraction of Record Entry content may be initiated by User
command, and/or rules-based algorithm. - Extraction of Record Entry content is the responsibilityof the System – which invokes relevant rules. - An Audit Trigger is initiated to track Record Entry
content extraction. Reference: ISO 21089, Section 12.7. An EHR-S enables an authorized user,
such as a clinician, to access and aggregate the distributed information, which corresponds to thehealth record or records that are needed for viewing, reporting, disclosure, etc. An EHR-S must
support data extraction operations across the complete data set that constitutes the health recordof an individual and provide an output that fully chronicles the healthcare process. Data
extractions are used as input to patient care coordination between facilities, organizations andsettings. In addition, data extractions can be used for administrative, financial, research, quality
analysis, public health purposes, and to enable re-creation of copies for importing into different
EHR applications and enable the archiving of patients' data. Data may be extracted in order tomeet analysis and reporting requirements. The extracted data may require use of more than one
application and it may be pre-processed (for example, by being de-identified) before transmission.
Data extractions may be used to exchange data and provide reports for primary and ancillary
purposes.
機能説明：このイベントはサブセット、派生物、サマリあるいは集約を作成するために記録入力内容が抽出された場合に発生する。記録入力の抽出はユーザコマンド、および/あるいはルールに基づいた
アルゴリズムにより開始される。- 記録入力内容の抽出はシステムの責任である － システムは関連するルールに従う。-記録入力の抽出を追跡するための監査が開始される。参照：ISO 21089, Section
12.7. EHR-S は医師のような権限のあるユーザに対し閲覧したり、レポートしたり開示したり等をするために必要な健康記録である分散した情報にアクセスし集約することを可能にする。EHR-S は個
人の健康記録を構成する全データセットに渡ってデータ抽出操作をサポートし、またヘルスケアプロ
セスの完全な時系列的出力を提供しなければならない。データ抽出は施設、組織、現場の間での患者のケアコーディネーションへの入力として使用される。さらに、データ抽出は経営、財務、研究、品質分析、公衆衛生目的でも利用可能であり、異なる EHR アプリケーションへ採り込むためのコピーの再作成を可能にしたり患者データの保管を可能にしたりするためにも利用できる。データは分析やレポート要求に合致するように抽出される。抽出されたデータは 1 つ以上のアプリケーションで使用されることもあり、転送前に前処理（例えば無名化）されることもある。データ抽出はデータ交換に使用したり、初期あるいは補助的なレポートを提供するために使用されることがある。
1. The system SHALL provide the ability to extract Record 1937
Entry content to produce subsets, derivations,summaries or aggregations according to scope ofpractice, organizational policy, and/or jurisdictional law.
1. システムは業務の範囲、組織ポリシーおよび/または管轄区
域の法律に従って、サブセット、派生物、サマリあるいは集約を作成するために記録入力内容を抽出する機能を提供しなければならない。
2. The system SHALL provide the ability to de-identify 1938
Record Entries during extraction in accordance withfunction RI.1.1.10 (De-Identify Record Entries).
2. システムは RI.1.1.10(記録入力の無名化)機能に従って、抽出中に記録入力の無名化をする機能を提供しなければならない。
3. The system SHALL provide the ability to extract Record 1939
Entry content based on queries with selection criteria,
for example, key words, date/time range, full text search.
3. システムは例えば、キーワード、日付/時間範囲、全文検索
等の抽出条件のクエリに基づき記録入力内容を抽出する機能を提供しなければならない。
4. The system SHALL provide the ability to extract 1940

Section/id#：
Type:
Name:

Conformance Criteria
metadata associated with Record Entry content.
4. システムは記録入力内容に関連するメタデータを抽出する機能を提供しなければならない。
8. The system SHALL provide the ability to extract Record
Entry content for various purposes, including
administrative, financial, research, quality analysis andpublic health.
8. システムは経営、財務、研究、品質分析、公衆衛生を含む種々の目的のために記録入力内容を抽出する機能を提供しなければならない。

RI.1.1.13.1
Function
Evidence of Record
Entry Extraction Event
記録入力内容の抽出イベ
ントの証跡

Row#

1944

1948

Statement: Maintain Evidence of Record Entry Extraction Event
機能概要：記録入力の抽出イベントの証跡の維持
Description: Evidence of Record Entry Extraction Events includes key metadata, ensures healthrecord integrity (and trust) and enables record audit.
機能説明：記録入力内容の抽出イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when Record 1949
Entry content is extracted.
1. システムは記録入力内容が抽出される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 1950
where Record Entry content is extracted.
2. システムは記録入力内容を抽出した組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who is 1951
subject of extracted Record Entry content.
3. システムは抽出された記録入力内容の主体である患者のID を採り込まなければならない。
4. The system SHALL capture identity of the user 1952
extracting Record Entry content.
4. システムは記録入力内容の抽出を行ったユーザの ID を採
り込まなければならない。
5. The system SHALL capture identity of the system 1953
application which extracted Record Entry content.
5. システムは記録入力内容の抽出を行ったシステムアプリケーションの ID を採り込まなければならない。
6. The system SHALL capture the type of Record Event 1954
trigger (i.e., extract).
6. システムは記録イベントトリガのタイプ（つまり抽出）を採り込まなければならない。
7. The system SHALL capture the date and time Record 1955
Entry content is extracted.
7. システムは記録入力内容が抽出された日時を採り込まなけ
ればならない。
RI.1.1.14
1958
Function
Archive Record Entries
記録入力の保管Section/id#：
Type:
Name:

Conformance Criteria

Row#

Statement: Archive Record Entries (1 or more instances)
機能概要：記録入力の保管（1 以上のインスタンス）
Description: Occurs when Record Entries are archived – typically to off-line (less readily available)
storage media.- Archival of Record Entries may be initiated by User command.- Archival of Record
Entries is the responsibility of the System – which invokes relevant rules.- An Audit Trigger is
initiated to track Record Entry archival. Reference: ISO 21089, Section 12.10.
機能説明：このイベントは記録入力内容が保管された場合に発生する。－ 通常はオフライン（容易に利用しづらい）ストレージ媒体に - 記録入力の保管はユーザコマンドにより開始される。- 記録入力
内容の保管はシステムの責任である － システムは関連するルールに従う。-記録入力の保管を追跡するための監査が開始される。参照：ISO 21089, Section 12.10.
1. The system SHALL archive Record Entries according to 1961
function RI.3 (Manage Record Archive and Restore).
1. システムは RI.3(記録の保管と復元)機能に従って、記録入力の保管をする機能を提供しなければならない。
RI.1.1.14.1
1962
Function
Evidence of Record
Entry Archive Event
記録入力の保管イベントの証跡Statement: Maintain Evidence of Record Entry Archive Event
機能概要：記録入力の保管イベントの証跡の維持
Description: Evidence of Record Entry Archive Event includes key metadata, ensures healthrecord integrity (and trust) and enables record audit.
機能説明：記録入力内容の保管イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when Record 1963
Entry content is archived.
1. システムは記録入力内容が保管される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 1964
where Record Entry content is archived.
2. システムは記録入力内容を保管した組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who is 1965
subject of archived Record Entry content.
3. システムは保管された記録入力内容の主体である患者のID を採り込まなければならない。
4. The system SHALL capture an archive identifier for 1966
archived Record Entry content (e.g., nursing home
inpatient stay from 3/15/2000 thru 6/10/2000).
4. システムは保管された記録入力内容の保管 ID を採り込まなければならない（例：3/15/2000 から 6/10/2000 まで特別養護老人ホーム入院患者の滞在）。
5. The system SHALL capture identity of the user archiving 1967
Record Entry content.
5. システムは記録入力内容の保管を行ったユーザの ID を採
り込まなければならない。
6. The system SHALL capture identity of the system 1968
application which archived Record Entry content.
6. システムは記録入力内容の保管を行ったシステムアプリケ

Section/id#：
Type:
Name:

Conformance Criteriaーションの ID を採り込まなければならない。
7. The system SHALL capture the type of Record Event
trigger (i.e., archive).
7. システムは記録イベントトリガのタイプ（つまり保管）を採り込まなければならない。
8. The system SHALL capture the date and time Record
Entry content is archived.
8. システムは記録入力内容が保管された日時を採り込まなけ
ればならない。
11. The system SHALL capture the set of Record Entry
content to be archived.
11. システムは保管されるべき記録入力内容のセットを採り込まなければならない。

RI.1.1.15
Function
Restore(previously
archived)
RecordEntries（過去に保管された）記録入力の復元

Row#

1969

1970

1973

1976

Statement: Restore previously archived Record Entries (1 or more instances)
機能概要：過去に保管された記録入力の復元（1 以上のインスタンス）
Description: Occurs when Record Entries are restored from archive. - Restore of Record Entries
may be initiated by User command. - Restoration of Record Entries is the responsibility of the
System – which invokes relevant rules. - An Audit Trigger is initiated to track Record Entry
restoration. Reference: ISO 21089, Section 12.10.
機能説明：このイベントは記録入力内容が復元された場合に発生する。 - 記録入力の復元はユーザコ
マンドにより開始される。- 記録入力内容の復元はシステムの責任である － システムは関連するルールに従う。-記録入力の復元を追跡するための監査が開始される。参照：ISO 21089, Section 12.10.
1. The system SHALL provide the ability to restore 1977
(previously archived) Record Entries according to scopeof practice, organizational policy, and/or jurisdictionallaw.
1. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、（過去に保管された）記録入力の復元をする機能を提供しなければならない。
RI.1.1.15.1
1978
Function
Evidence of Record
Entry Restore Event
記録入力の復元イベントの証跡Statement: Maintain Evidence of Record Entry Restore Event
機能概要：記録入力の復元イベントの証跡の維持
Description: Evidence of Record Entry Restore Event includes key metadata, ensures healthrecord integrity (and trust) and enables record audit.
機能説明：記録入力内容の復元イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when archived 1979
Record Entry content is restored.
1. システムは記録入力内容が復元される都度それを監査しなSection/id#：
Type:
Name:

Conformance Criteria
ければならない。
2. The system SHALL capture identity of the organization
where Record Entry content is restored.
2. システムは記録入力内容を復元した組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who issubject of restored Record Entry content.
3. システムは復元された記録入力内容の主体である患者のID を採り込まなければならない。
4. The system SHALL capture an archive identifier for
restored Record Entry content (e.g., nursing home
inpatient stay from 3/15/2000 thru 6/10/2000).
システムは復元された記録入力内容の保管 ID を採り込まなければならない（例：3/15/2000 から 6/10/2000 まで特別養護老人ホーム入院患者の滞在）。
5. The system SHALL capture identity of the user restoring
Record Entry content.
5. システムは記録入力内容の復元を行ったユーザの ID を採
り込まなければならない。
6. The system SHALL capture identity of the systemapplication which restored Record Entry content.
6. システムは記録入力内容の復元を行ったシステムアプリケーションの ID を採り込まなければならない。
7. The system SHALL capture the type of Record Event
trigger (i.e., restore).
7. システムは記録イベントトリガのタイプ（つまり復元）を採り込まなければならない。
8. The system SHALL capture the date and time Record
Entry content is restored.
8. システムは記録入力内容が復元された日時を採り込まなけ
ればならない。

RI.1.1.16
Function
Destroy or Identify
RecordEntriesas
Missing
記録入力の破棄あるいは
紛失認識

Row#

1980

1981

1982

1983

1984

1985

1986

11990

Statement: Destroy or Identify Record Entries as Missing (1 or more instances)
機能概要：記録入力の破棄あるいは紛失認識（1 以上のインスタンス）
Description: Occurs when Record Entries are destroyed or identified as missing. - Destruction
typically occurs after conclusion of the legal retention period. - Destruction of Record Entries may
be initiated by User command. - Destruction of Record Entries is the responsibility of the System– which invokes relevant rules. - An Audit Trigger is initiated to track Record Entry Destruction
or Notation as Missing. Reference: ISO 21089, Section 12.11.
機能説明：このイベントは記録入力内容が破棄あるいは消失と認識された場合に発生する。 - 通常は記録入力の破棄は法的保存期間の終了後に発生する。- 記録入力の破棄はユーザコマンドにより開始される。- 記録入力内容の破棄はシステムの責任である － システムは関連するルールに従う。-記録
入力の破棄や紛失記録を追跡するための監査が開始される。参照：ISO 21089, Section 12.11.
1. The system SHALL provide the ability to delete (destroy) 1991
Record Entries (e.g., those exceeding their legal
retention period) according to scope of practice,organizational policy, and/or jurisdictional law.
1．システムは業務の範囲、組織ポリシーおよび/または管轄法

Section/id#：
Type:
Name:

Conformance Criteria

Row#

律に従って、記録入力の消去（破棄）をする機能を提供しなければならない（例：法的保存期限を経過したもの）。
2. The system SHALL provide the ability to tag Record
Entries as missing.
2. システムは記録入力を紛失したことのタグ付けをする機能を提供しなければならない。

1992

RI.1.1.16.1
Function
Evidence of Record
Entry
Destruction
Event
記録入力の破棄イベント
の証跡

1993

Statement: Maintain Evidence of Record Entry Destruction Event
機能概要：記録入力の破棄イベントの証跡の維持
Description: Evidence of Record Entry Destruction Event includes key metadata, ensures healthrecord integrity (and trust) and enables record audit.
機能説明：記録入力内容の破棄イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when Record 1994
Entry content is destroyed according to scope of practice,organizational policy, and/or jurisdictional law.
1. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、記録入力内容が破棄される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 1995
where Record Entry content is destroyed.
2. システムは記録入力内容を破棄した組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who is 1996
subject of destroyed Record Entry content.
3. システムは破棄された記録入力内容の主体である患者のID を採り込まなければならない。
4. The system SHALL capture a destruction identifier for 1997
destroyed Record Entry content (e.g., nursing home
inpatient stay from 3/15/2000 thru 6/10/2000).
4. システムは破棄された記録入力内容の破棄 ID を採り込まなければならない（例：3/15/2000 から 6/10/2000 まで特別養護老人ホーム入院患者の滞在）。
5. The system SHALL capture identity of the user 1998
destroying Record Entry content.
5. システムは記録入力内容の破棄を行ったユーザの ID を採
り込まなければならない。
6. The system SHALL capture identity of the system 1999
application which destroyed Record Entry content.
6. システムは記録入力内容の破棄を行ったシステムアプリケーションの ID を採り込まなければならない。
7. The system SHALL capture the type of Record Event 2000
trigger (i.e., destroy).
7. システムは記録イベントトリガのタイプ（つまり破棄）を採り込まなければならない。
8. The system SHALL capture the date and time Record 2001
Entry content is destroyed.
8. システムは記録入力内容が破棄された日時を採り込まなけSection/id#：
Type:
Name:

Conformance Criteria

Row#

ればならない。
RI.1.1.17
Function
Deprecate/Retract
Record Entries
記録入力の否認/撤回

2006

Statement: Deprecate/retract Record Entries as invalid (1 or more instances)
機能概要：記録入力の不当としての否認/撤回（1 以上のインスタンス）
Description: Occurs when Record Entries are deprecated if found to be improperly identified orotherwise invalid. - Deprecation of Record Entries may be initiated by User command. Deprecation of Record Entries is the responsibility of the System – which invokes relevant rules.An Audit Trigger is initiated to track Record Entry Deprecation.
機能説明：このイベントは記録入力内容が不適切に決められるかさもなければ不当と判明し否認された場合に発生する。- 記録入力の否認はユーザコマンドにより開始される。- 記録入力内容の否認はシステムの責任である － システムは関連するルールに従う。-記録入力の否認を追跡するための監査が開始される。
1. The system SHALL provide the ability to 2007
deprecate/retract Record Entries as invalid according toscope of practice, organizational policy, and/or
jurisdictional law.
1．システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、記録入力を不当として否認/撤回する機能を提供しなければならない。
RI.1.1.17.1
2008
Function
Evidence of Record
Entry
Deprecation/Retraction
Event
記録入力の否認/撤回イ
ベントの証跡Statement: Maintain Evidence of Record Entry Deprecation/Retraction Event
機能概要：記録入力の否認/撤回イベントの証跡の維持
Description: Evidence of Record Entry Deprecation/Retraction Event includes key metadata,
ensures health record integrity (and trust) and enables record audit.
機能説明：記録入力内容の否認/撤回イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when Record 2009
Entry content is deprecated/retracted.
1. システムは記録入力内容が否認/撤回される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 2010
where Record Entry content is deprecated/retracted.
2. システムは記録入力内容を否認/撤回した組織の ID を採り込まなければならない
3. The system SHALL capture identity of the patient who is 2011subject of deprecated/retracted Record Entry content.
3. システムは否認/撤回された記録入力内容の主体である患者の ID を採り込まなければならない。
4. The system SHALL capture identity of the user 2012
deprecating/retracting Record Entry content.

Section/id#：
Type:
Name:

Conformance Criteria
4. システムは記録入力内容の否認/撤回を行ったユーザの ID
を採り込まなければならない
5. The system SHALL capture identity of the systemapplication which deprecated/retracted Record Entry
content.
5. システムは記録入力内容の否認/撤回を行ったシステムア
プリケーションの ID を採り込まなければならない。
6. The system SHALL capture the type of Record Event
trigger (i.e., deprecate/retract).
6. システムは記録イベントトリガのタイプ（つまり否認/撤回）を採り込まなければならない。
7. The system SHALL capture the date and time Record
Entry content is deprecated/retracted.
7. システムは記録入力内容が否認/撤回された日時を採り込まなければならない。
8. The system SHALL capture identity of the location (i.e.,
network address) where Record Entry content isdeprecated/retracted.
8. システムは記録入力が否認/撤回されたロケーション（ネットワークアドレス）ID を採り込まなければならない。

RI.1.1.18
Function
Re-Activate
RecordEntries
記録入力の復活

Row#

2013

2014

2015

2016

2018

Statement: Re-activate Record Entries (1 or more instances)
機能概要：記録入力の復活（1 以上のインスタンス）
Description: Occurs when Record Entries are made active again after previously Destroy or
Deprecate. - Re-activation of Record Entries may be initiated by User command. - Re-activation ofRecord Entries is the responsibility of the System – which invokes relevant rules.- An Audit
Trigger is initiated to track Record Entry Re-Activation.
機能説明：このイベントは過去に破棄あるいは否認された記録入力内容が再度復活された場合に発生する。- 記録入力の復活はユーザコマンドにより開始される。- 記録入力内容の復活はシステムの責任である － システムは関連するルールに従う。-記録入力の復活を追跡するための監査が開始される。
1. The system SHALL provide the ability to re-activate 2019(previously deleted or deprecated) Record Entries
according to scope of practice, organizational policy,
and/or jurisdictional law.
1. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、（過去に破棄あるいは否認された）記録入力を復活する機能を提供しなければならない。
RI.1.1.18.1
2020
Function
Evidence of Record
Entry
Re-Activation
Event
記録入力の復活イベントの証跡Statement: Maintain Evidence of Record Entry Re-Activation Event
機能概要：記録入力の復活イベントの証跡の維持
Description: Evidence of Record Entry Re-Activation Event includes key metadata, ensures healthSection/id#：
Type:
Conformance Criteria
Name:record integrity (and trust) and enables record audit.

Row#

機能説明：記録入力内容の復活イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when 2021
destroyed or deprecated Record Entry content is reactivated.
1. システムは過去に破棄あるいは否認された記録入力内容が復活される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 2022
where Record Entry content is reactivated.
2. システムは記録入力内容を復活した組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who is 2023
subject of reactivated Record Entry content.
3. システムは復活された記録入力内容の主体である患者のID を採り込まなければならない。
4. The system SHALL capture identity of the user 2024
reactivating Record Entry content.
4. システムは記録入力内容の復活を行ったユーザの ID を採
り込まなければならない。
5. The system SHALL capture identity of the system 2025
application which re-activated Record Entry content.
5. システムは記録入力内容の復活を行ったシステムアプリケーションの ID を採り込まなければならない。
6. The system SHALL capture the type of Record Event 2026
trigger (i.e., re-activate).
6. システムは記録イベントトリガのタイプ（つまり復活）を採り込まなければならない。
7. The system SHALL capture the date and time Record 2027
Entry content is re-activated.
7. システムは記録入力内容が復活された日時を採り込まなけ
ればならない。
RI.1.1.19
2030
Function
Merge Record Entries
記録入力の併合
Statement: Merge Record Entries (2 or more instances)
機能概要：記録入力の併合（2 以上のインスタンス）
Description: Occurs when Record Entries are merged together. - Entries may be merged if
duplicate patient records are found.
機能説明：このイベントは記録入力内容がお互いに併合された場合に発生する。- 記録入力は重複した患者の記録が発見された場合に併合される。
1. The system SHALL provide the ability to logically merge 2031
patient Record Entries according to scope of practice,organizational policy, and/or jurisdictional law.
1. システムは業務の範囲、組織ポリシーおよび/または管轄法律に従って、論理的に患者の記録入力を併合する機能を提供しなければならない。
RI.1.1.19.1
2032
Function
Evidence of Record
Entry Merge Event
記録入力の併合イベント

Section/id#：
Type:
Name:
の証跡

Conformance Criteria

Row#

Statement: Maintain Evidence of Record Entry Merge Event
機能概要：記録入力の併合イベントの証跡の維持
Description: Evidence of Record Entry Merge Event includes key metadata, ensures health record
integrity (and trust) and enables record audit.
機能説明：記録入力内容の併合イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when Record 2033
Entries are merged (e.g., same patient, multiple sets ofrecord entries).
1. システムは記録入力内容が併合される都度それを監査しなければならない（例：同一患者、記録入力の重複セット）。
2. The system SHALL capture identity of the organization 2034
where Record Entries are merged.
2. システムは記録入力内容を併合した組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who is 2035
subject of merged Record Entries.
3. システムは併合された記録入力内容の主体である患者のID を採り込まなければならない。
4. The system SHALL capture the identifier for the source 2036
set of Record Entries.
4. システムは記録入力内容のソースセットの ID を採り込まなければならない。
5. The system SHALL capture the identifier for the target 2037
set of Record Entries.
5. システムは併合ターゲットの記録入力セットの ID を採り込まなければならない。
6. The system SHALL capture identity of the user merging 2038
Record Entries.
6. システムは記録入力内容の併合を行ったユーザの ID を採
り込まなければならない。
7. The system SHALL capture identity of the system 2039
application which merged Record Entries.
7. システムは記録入力内容の併合を行ったシステムアプリケーションの ID を採り込まなければならない。
8. The system SHALL capture the type of Record Event 2040
trigger (i.e., merge).
8．システムは記録イベントトリガのタイプ（つまり併合）を採り込まなければならない。
9. The system SHALL capture the date and time Record 2041
Entries are merged.
9．システムは記録入力内容が併合された日時を採り込まなけ
ればならない。
10. The system SHALL capture identity of the location (i.e., 2042
network address) where Record Entries are merged.
10．システムは記録入力が併合されたロケーション（ネットワークアドレス）ID を採り込まなければならない。
RI.1.1.20
2045
Function
Unmerge
RecordEntries
記録入力の併合解除

Section/id#：
Type:
Name:

Conformance Criteria

Row#

Statement: Unmerge previously merged Record Entries (2 or more instances)
機能概要：過去に併合された記録入力の併合解除（2 以上のインスタンス）
Description: Occurs when Record Entries must be unmerged from previous merge, as in RI.1.1.16.
機能説明：このイベントは RI.1.1.19 に記載されるような過去に併合された記録入力内容が併合解除された場合に発生する。
1. The system SHALL provide the ability to unmerge 2046
multiple patient Record Entries according to scope ofpractice, organizational policy, and/or jurisdictional law.
1. システムは業務の範囲、組織ポリシーおよび/または管轄区
域の法律に従って、患者の記録入力の併合解除する機能を提供しなければならない。
RI.1.1.20.1
2047
Function
Evidence of Record
Entry Unmerge Even
記録入力の併合解除イベ
ントの証跡
Statement: Maintain Evidence of Record Entry Unmerge Event
機能概要：記録入力の併合解除イベントの証跡の維持
Description: Evidence of Record Entry Unmerge Event includes key metadata, ensures healthrecord integrity (and trust) and enables record audit.
機能説明：記録入力内容の併合解除イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
1. The system SHALL audit each occurrence when merged 2048
Record Entries are unmerged.
1. システムは併合された記録入力内容が併合解除される都度それを監査しなければならない。
2. The system SHALL capture identity of the organization 2049
where Record Entries are unmerged.
2. システムは記録入力内容を併合解除した組織の ID を採り込まなければならない。
3. The system SHALL capture identity of the patient who is 2050
subject of unmerged Record Entries.
3. システムは併合解除された記録入力内容の主体である患者の ID を採り込まなければならない。
4. The system SHALL capture the identifier for the source 2051
set of Record Entries.
4. システムは記録入力内容のソースセットの ID を採り込まなければならない。
5. The system SHALL capture the identifier for the target 2052
set of Record Entries.
5. システムは併合解除ターゲットの記録入力セットの ID を採り込まなければならない。
6. The system SHALL capture identity of the user 2053
unmerging Record Entries.
6. システムは記録入力内容の併合解除を行ったユーザの ID
を採り込まなければならない。
7. The system SHALL capture identity of the system 2054
application which unmerged Record Entries.
7. システムは記録入力内容の併合解除を行ったシステムアプ
リケーションの ID を採り込まなければならない。

Section/id#：
Type:
Name:

RI.1.1.21
Function
Link Record Entries
記録入力のリンク

Conformance CriteriaRow#

8. The system SHALL capture the type of Record Event 2055
trigger (i.e., unmerge).
8．システムは記録イベントトリガのタイプ（つまり併合解除）
を採り込まなければならない。
9. The system SHALL capture the date and time Record 2056
Entries are unmerged.
9．システムは記録入力内容が併合解除された日時を採り込まなければならない。
2060

Statement: Link Record Entries (2 or more instances)
機能概要：記録入力のリンク（2 以上のインスタンス）
Description: Occurs when Record Entries are linked together. - Entries may be linked for a single
an encounter (patient visit)- Entries may be linked for an episode (patient problem)- Entries may
be linked for a selected population cohort
機能説明：このイベントは記録入力内容がお互いにリンクされた場合に発生する。- 記録入力は患者の外来受診に対してリンクされことがある。 - 記録入力はエピソード（患者の問題点）に対してリン
クされることがある。- 記録入力は選択されたコホート群に対してリンクされることがある。
1. The system SHALL provide the ability to logically link 2061
patient Record Entries according to scope of practice,organizational policy, and/or jurisdictional law.
1. システムは業務の範囲、組織ポリシーおよび/または管轄区
域の法律に従って、論理的に患者の記録入力をリンクする機能を提供しなければならない。
RI.1.1.21.1
2062
Function
Evidence of Record
Entry Link Event
記録入力のリンクイベン
トの証跡Statement: Maintain Evidence of Record Entry Link Event
機能概要：記録入力のリンクイベントの証跡の維持
Description: Evidence of Record Entry Link Event includes key metadata, ensures health record
integrity (and trust) and enables record audit.
機能説明：記録入力内容のリンクイベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
RI.1.1.22
2072
Function
Unlink Record Entries
記録入力のリンクの解除
Statement: Unlink previously linked Record Entries (2 or more instances)
機能概要：過去にリンクされた記録入力のリンクの解除（2 以上のインスタンス）
Description: Occurs when Record Entries must be unlinked from previous linkage, as in RI.1.1.18.
機能説明：このイベントは RI.1.1.21 に記載されるような過去にリンクされた記録入力内容のリンクを解除しなければならない場合に発生する。
1. The system SHALL provide the ability to unlink multiple 2073

Section/id#：
Type:
Name:

Conformance CriteriaRow#patient Record Entries according to scope of practice,organizational policy, and/or jurisdictional law.
1. システムは業務の範囲、組織ポリシーおよび/または管轄区
域の法律に従って、患者の記録入力のリンクを解除する機能を提供しなければならない。
RI.1.1.22.1
Function
Evidence of Record
Entry Unlink Event
記録入力のリンク解除イ
ベントの証跡2074

Statement: Maintain Evidence of Record Entry Unlink Event
機能概要：記録入力のリンク解除イベントの証跡の維持
Description: Evidence of Record Entry Unlink Event includes key metadata, ensures health record
integrity (and trust) and enables record audit.
機能説明：記録入力内容のリンク解除イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
RI.1.1.23
2084
Function
Place Record Entries on
Legal Hold
記録入力の訴訟ホールド
設定
Statement: Hold Record Entries in an unaltered state for legal hold period (1 or more instances)
機能概要：記録入力を訴訟ホールド期間中変更不可の状態に保つ（1 以上のインスタンス）
Description: Occurs when Record Entries must be marked (and held in an unaltered state) for
purposes of a legal hold (typically as the result of court or legal action).
機能説明：このイベントは訴訟ホールドの目的に対してマーク（そして変更できない状態に保持）されなければならない場合に発生する（通常は裁判所あるいは法的アクションの結果として）。
1. The system SHALL provide the ability to manage a 2085
specified set of patient Record Entries during period oflegal hold, marking as to on hold status and preventing
alteration according to scope of practice, organizational
policy, and/or jurisdictional law.
1. システムは業務の範囲、組織ポリシーおよび/または管轄区
域の法律に従って、訴訟ホールド期間中ホールド状態であることをマークし、また変更を禁止することで指定された患者記録入力のセットを管理する機能を提供しなければならない。
RI.1.1.23.1
2086
Function
Evidence of Record
Entry Legal Hold Event
記録入力の訴訟ホールド
イベントの証跡
Statement: Maintain Evidence of Record Entry Legal Hold Event
機能概要：記録入力の訴訟ホールドイベントの証跡の維持
Description: Evidence of Record Entry Legal Hold Event includes key metadata, ensures healthrecord integrity (and trust) and enables record audit.

Section/id#：
Type:
Name:

Conformance Criteria

Row#

機能説明：記録入力の訴訟ホールドイベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
RI.1.1.24
2099
Function
Release Record Entries
from Legal Hold
記録入力の訴訟ホールド
解除
Statement: Release legal hold on Record Entries (1 or more instances)
機能概要：記録入力を訴訟ホールドから解除（1 以上のインスタンス）
Description: Occurs when Record Entries are released from legal hold (previously marked andheld in unaltered state), as in RI.1.1.20.
機能説明：このイベントは訴訟ホールド（過去にマークされまた変更できない状態に保持された状態）から解除する場合に発生する。
1. The system SHALL provide the ability to release patient 2100
Record Entries from legal hold status according to scopeof practice, organizational policy, and/or jurisdictionallaw.
1. システムは業務の範囲、組織ポリシーおよび/または管轄区
域の法律に従って、患者記録入力を訴訟ホールド状態から解除する機能を提供しなければならない。
RI.1.1.24.1
2101
Function
Evidence of Record
Entry
Legal
Hold
Removal Event
記録入力の訴訟ホールド
解除イベントの証跡
Statement: Maintain Evidence of Record Entry Legal Hold Removal Event
機能概要：記録入力の訴訟ホールド解除イベントの証跡の維持
Description: Evidence of Record Entry Legal Hold Removal Event includes key metadata, ensures
health record integrity (and trust) and enables record audit.
機能説明：記録入力の訴訟ホールド解除イベントの証跡にはキーメタデータが含まれ、健康記録の真正性（および信頼性）を保証し、記録の監査を可能とする。
3. The system SHALL capture identity of the patient who is 2104
subject of Record Entries released from legal hold.
3. システムは訴訟ホールド解除された記録入力内容の主体である患者の ID を採り込まなければならない。
4. The system SHALL capture identity of the user releasing 2105
Record Entries from legal hold.
4. システムは記録入力内容の訴訟ホールド解除を行ったユー
ザの ID を採り込まなければならない。
5. The system SHALL capture identity of the system 2106
application which released Record Entries from legal
hold.
5. システムは記録入力内容の訴訟ホールド解除を行ったシス
テムアプリケーションの ID を採り込まなければならない。
7. The system SHALL capture the date and time Record 2108
Entries are released from legal hold.
7．システムは記録入力内容が訴訟ホールド解除された日時を

Section/id#：
Type:
Name:

Conformance Criteria

Row#

採り込まなければならない。
RI.1.2HeaderRecord Lifespan
レコード・ライフスパン

2111

Statement: Manage Record Lifespan
機能概要：レコード寿命の管理
Description: Record Lifecycle Events (Section RI.1.1) are those required to manage Record Entries
in persistent storage over the full course of Record Lifespan (Section RI.1.2). See Section RI.1.1,
Record Lifecycle, for further description.
機能説明：レコード・ライフサイクル・イベント（セクション RI.1.1 は）レコード・ライフスパン（セクション RI.1.2 ）の全過程にわたって永続的なストレージ内のレコード・エントリを管理するために必要なものである。さらなる説明については、セクション RI.1.1 のレコード・ライフサイクルを参照のこと。
RI.1.2.1
2112
FunctionManage Record Entries
レコード・エントリ管理
Statement: Manage/Persist Record Entries (Multiple instances)
機能概要：レコード・エントリの管理／持続（複数インスタンス）
Description: Occurs upon Record Entry origination/retention and thereafter on a continuous anduninterrupted basis for lifespan of each Record Entry.- Ensures long-term retention andpreservation of EHR Record Entries, without alteration. Reference: ISO 21089, Section 12.2.2
機能説明：レコード・エントリの開始/保持が起こり、その後の継続的で途切れない各レコード・エン
トリの寿命の基盤となる－EHR レコード・エントリが変更されることなく、長期的保存や保全を確保する。参考： ISO 21089 セクション 12.2.2
1. The system SHALL manage each Record Entry as a 2113
persistent, indelible (unalterable) data object, including
its revision history.
1. システムは各レコード・エントリを永続的、消去できない（不変の）データ・オブジェクトとして、その改訂履歴を含めて、管理できなければならない。
2. The system SHALL manage (persist) each Record Entry 2114
for its applicable retention period according to scope ofpractice, organizational policy, and/or jurisdictional law.
2. システムは、実施範囲、組織ポリシー、および/または管轄区域の法律に従って、その適用可能な保存期間の間、各レ
コード・エントリを管理（保持）しなければならない。
3. The system SHALL manage (persist) the full set of 2115
identity, event and provenance Audit Metadata for eachRecord Entry, conforming to lifecycle events in function
RI.1.1 (Record Lifecycle) and metadata requirements infunction TI.2.1.1 (Record Entry Audit Triggers).
3. システムは、機能 RI.1.1 （レコード・ライフサイクル）
におけるライフサイクル・イベントと機能 TI.2.1.1（レコード・エントリ監査トリガー）におけるメタ・データ要件に適合した形で、各レコード・エントリの、識別、イベン
ト、起源、 監査メタデータのすべてを管理（保持）しなけ
ればならない。

4.

RI.1.2.2
FunctionManage Record Entries
for Legal Hold
訴訟ホールドのためのレ
コード・エントリ管理

The
systemSHALL manage(persist)
the 2116
attestation/signature event (e.g., digital signature) of
each Record Entry conforming to function RI.1.1.4(Attest Record Entry Content).
4. システムは、RI.1.1.4（レコード・エントリ内容証明）に準拠し、各レコード・エントリの検証/署名イベント（例えば、デジタル署名）を管理（保持）しなければならない。
5. The system SHALL manage Record Entries with data 2117
content in standard and non-standard formats.
5. システムは、データコンテンツといっしょにレコード・エ
ントリを、標準および非標準形式で管理することができなければならない。
6. The system SHALL manage Record Entries containing 2118
both structured and unstructured data.
6. システムは、構造化および非構造化データの両方を含むレ
コード・エントリを管理できなければならない。
12. IF allowing tags for specific Record Entry deletion, 2124
THEN the system SHALL provide the ability to manage
the set of tagged Entries, allowing review andconfirmation before actual deletion occurs according toscope of practice, organizational policy, and/or
jurisdictional law.
12. もしも特定のレコード・エントリの削除のためのタグを許可する場合、システムは実施範囲、組織ポリシー、および/または管轄区域の法律に従って、実際に削除する前に、評価と確認を可能にするように、タグ付けされたエントリのセットを管理する機能を提供しなければならない。
13. IF allowing tags for specific Record Entry deletion, 2125
THEN the system SHALL provide the ability to delete
Entries according to scope of practice, organizational
policy, and/or jurisdictional law.
13. もしも特定のレコード・エントリの削除のためのタグを許可するならば、システムは、実施範囲、組織ポリシー、および/または管轄区域の法律に基づいて、エントリを削除する機能を提供しなければならない
14. IF allowing tags for specific Record Entry deletion, 2126
THEN the system SHALL provide the ability to renderconfirming notification that the destruction occurred
according to scope of practice, organizational policy,
and/or jurisdictional law.
14. もしも特定のレコード・エントリの削除のためのタグを許可するならば、システムは実施範囲、組織ポリシー、および/または管轄区域ｈｈの法律に従って、破棄が発生したことの確認通知を表示する機能を提供しなければならない。
2132

Statement: Manage/Preserve Record Entries for Legal Hold (Multiple instances)
機能概要：訴訟ホールドのためのレコード・エントリの管理/持続（複数インスタンス）
Description: Occurs when a set of Record Entries is designated to be held for legal purposes orproceedings. - Ensures preservation of a set of Record Entries for a designated time, held without
alteration.
機能説明：レコード・エントリのセットが法的目的や手続のために保持されるように指定された場合に発生する－変更なく保持され、指定された時間にレコード・エントリのセットの保全を保証する。

1. The system SHALL conform to function RI.1.1.23 (Place
Record Entries on Legal Hold).
1. システムは機能 RI.1.1.23 (訴訟ホールドへのレコード・エ
ントリ設定)に適合しなければならない。
2. The system SHALL conform to function RI.1.1.24(Release Record Entries from Legal Hold).
2. システムは機能 RI.1.1.24 (訴訟ホールドからのレコード・
エントリ解除)に適合しなければならない。
3. The system SHALL provide the ability to control accessto data/records during legal hold, preventing unauditable alteration or unauthorized use forpreservation purposes.
3. システムは訴訟ホールドの期間中、保全のために監査不能な修正あるいは権限のない利用を防ぐために、データ/レコードへのアクセス制御ができなければならない
4. The system SHALL provide the ability to maintainrecords beyond normal retention period according toscope of practice, organizational policy, and/or
jurisdictional law.
4. システムはレコードを、実務範囲・組織ポリシー・管轄区
域法制度に従って、通常の保持期間を超えて保持できなけ
ればならない。
RI.1.3HeaderRecord States
レコード状態

2133

2134

2135

2136

2140

Statement: Manage Record States
機能概要：レコード状態の管理
Description: Record Entries may reside in various states that must be managed. An importantunderlying principle for managing record states is the need to retain Record Entries that havebeen viewed for patient care purposes even if the Entry has not been completed or attested. This
principle has important legal impact because it provides an account of what the provider viewed
and relied on for clinical decision-making. For example, if Record Entry content was available inpending state and a clinician used the information to make decisions, it is important to retain thepending version even after the final version was available. Determining if Record Entry content
was used for patient care may be challenging. Access logs could provide a mechanism to determine
if the information was used.
機能説明：レコード・エントリは、管理すべき様々な状態に属することができる。レコード状態管理に関する重要な基本的原則は、エントリが完了あるいは保証されていなくても、患者ケア目的で参照されるレコード・エントリは保持される必要があるということである。この原則は重要な法的影響力を持つ、なぜならば、サービス提供者が何を参照し臨床的意思決定の拠り所にしたかの説明を提供するからである。例えば、もしレコード・エントリ内容が保留状態において利用可能で、臨床家がその情報を意思決定に利用した場合、最終のバージョンが利用可能になった後においても保留バージョンを保持することが重要である。もしレコード・エントリ内容が患者ケアに利用された場合、決定することはチャレンジングかもしれない。アクセスログは情報が利用されるかどうかを確認するメカニズ
ムを提供できる。
RI.1.3.1
2141
FunctionManage Record Pending
State
Statement: Manage Record Entries during the various states of completion.
機能概要：完了までの様々な状態におけるレコード・エントリの管理
Description: Record Entries may reside in various states that must be managed. An importantunderlying principle for managing record states is the need to retain Record Entries that havebeen viewed for patient care purposes even if it has not been completed or attested. This principle

has important legal impact because it provides a record of what the provider relied on for clinicaldecision-making. For example, if a Record Entry was available in pending state and a clinician
accessed the information to make decisions, it is important to retain the pending version evenafter the final version was available. Determining if the Record Entry was accessed for patientcare may be challenging. Access logs should show if the information was accessed/viewed.
機能説明：レコード・エントリは、管理すべき様々な状態に属することができる。レコード状態管理に関する重要な基本的原則は、エントリが完了あるいは保証されていなくても、患者ケア目的で参照されるレコード・エントリは保持される必要があるということである。この原則は重要な法的影響力を持つ、なぜならば、サービス提供者が何を参照し臨床的意思決定の拠り所にしたかの説明を提供するからである。例えば、もしレコード・エントリ内容が保留状態において利用可能で、臨床家がその情報を意思決定のためにアクセスした場合、最終のバージョンが利用可能になった後においても保留バージョンを保持することが重要である。もしレコード・エントリ内容が患者ケアに利用された場合、決定することはチャレンジングかもしれない。アクセスログは情報が利用／アクセスされたかを示さなければならない。
4. IF the system displays pending Record Entries, THEN 2145
the system SHALL tag and present that a Record Entryis pending or incomplete.
4. システムがレコード・エントリ保留を表示した場合、シス
テムはレコード・エントリが保留あるいは未完了であることを、タグ付けし示さなければならない。
7. The system SHALL capture a date/time stamp and 2148
identify the author each time a Record Entry is updated
including when opened, when updated, with thesignature event and when officially closed, conforming tofunction TI.2.1.1 (Record Entry Audit Triggers).
7. システムは、日付/時刻スタンプを取得し、いつオープンさ
れ、いつ更新され、署名イベントと共にいつ正式にクローズしたかを含むレコード・エントリが更新された各時刻で著者を識別し、TI.2.1.1（レコード・エントリ監査トリガ）
機能に適合しなければならない。
RI.1.3.2
2149
FunctionManage Record Entry
Amended,Corrected
and Augmented State
レコード・エントリ修正、訂正、拡張状態管理
Statement: Manage Record Entries amended, corrected or augmented after finalization (orsignature/attestation).
機能概要：完了（あるいは署名/検証）後のレコード・エントリ修正、訂正あるいは拡張の管理
Description: Clinicians need the ability to correct, amend or augment Record Entries once they
have been completed. When an amendment, correction or augmentation has been made, principles
for documentation practices require that the original documentation must be accessible, readable,
and unobliterated. A user must have a clear indication that modifications have been made to an
Record Entry. There is optionality in how a system may identify a Record Entry that has beencorrected or amended – a flag or indicator could be displayed, the text could be in a different font,etc. The original Record Entry is not required to be displayed, but can be linked or traced back.
The original Record Entry and each successive amendment, correction or augmentation should be
retained for the legally prescribed timeframe as defined by scope of practice, organizational policy,
and/or jurisdictional law.
機能説明：臨床家はレコード・エントリを一旦完了してからも訂正、修正あるいは拡張可能である必要がある。修正、訂正、拡張が行われた際に、文書手続きの原則として、オリジナルの文書がアクセ
スでき、再利用でき、削除されないことが求められる。レコード・エントリに修正がなされたことの明確な表示を利用者は得られなければならない。オプションとしては、システムがどのような方法でレコード・エントリが訂正あるいは修正されたことを識別するか－フラグあるいは指標が表示される、テキストが異なるフォントになる等。オリジナルのレコード・エントリは表示される必要なないが、リンクされたり、遡れる必要がある。オリジナルのレコード・エントリとその後の修正、訂正、

拡張は、実施範囲や組織ポリシー、および/または管轄地域の法律に従って、法的に定められた時間フ
レームの中で保持されなければならない
1. The system SHALL provide the ability to update a Record 2150
Entry for purposes of amendment, correction oraugmentation, conforming to function RI.1.1.2 (Amend
Record Entry Content).
1. システムは RI.1.1.2(レコード・エントリ内容修正)に、適合
し修正、訂正、拡張目的でレコード・エントリを更新できなければならない。
2. The system SHALL provide the ability to tag a Record 2151
Entry as an amendment, a correction of erroneous
information and the reason, or an augmentation to
supplement content.
2. システムは、修正、エラー情報や理由の訂正、補足内容の追加の際に、レコード・エントリにタグ付けできなければならない。
3. The system SHALL capture, maintain and render the 2152
corresponding date, time, and user specifying when andby whom a Record Entry was amended, corrected, oraugmented, conforming to function RI.1.1.2.1 (Evidenceof Record Entry Amendment Event).
3. システムは RI.1.1.2.1(レコード・エントリ修正エベントのエビデンス)に適合した形で、レコード・エントリの修正、訂正、拡張の日付、時刻、利用者が特定したいつ、誰によってという情報を取得、保持、表示できなければならない。
4. The system SHALL present the current version and 2153
provide a link or clear direction for accessing previous
version(s) of the Record Entry.
4. システムはレコード・エントリの現バーションを提示でき、過去バージョンにアクセスするためのリンクあるいは明確な方法を提供できなければならない。
5. The system SHALL manage all versions of the Record 2154
Entry for the legal retention period, conforming tofunction RI.1.2.1 (Manage Record Entries).
5. システムは、RI1.2.1(レコード・エントリ管理)に適合して、法的保存期間の間、レコード・エントリの全バージョンを管理しなければならない。
RI.1.3.3
2155
FunctionManage Record Entry
Succession and Version
Control
レコード・エントリの遷
移とバージョン・コント
ロール管理
Statement: Manage successive Record Entry versions over time.
機能概要：一連のレコード・エントリの経時的バージョンの管理
Description: The system must have a mechanism to handle versions and succession of Record
Entries (such as a preliminary and final laboratory reports, amended or corrected documents).
Versioning and succession management is based on Record Entry content, and/or status changeover time.A version may be one of:1) A completed and attested Record Entry; 2) A Record Entry
completed and attested which has been modified one or more times3) A Record Entry that has
been viewed for clinical decision-making purposes by an individual other than the author4) A
Record Entry that has been captured in an incomplete state per organization business rules andupdated over time (i.e., a preliminary laboratory test). 5) A Record Entry that electively, according
to the author, must be preserved in the current state at a given point in time (i.e., History andPhysical). Certain types of Record Entries are typically handled in versions, for example:
laboratory results (preliminary and final)- Dictated reports- Work ups (over course of days)The

prior version of Record Entries should be retained for the legally prescribed timeframe as definedby scope of practice, organizational policy, and jurisdictional law.
機能説明：システムはレコード・エントリのバージョンや遷移（たとえば検査の仮レポートと最終レ
ポート、修正あるいは訂正文書）を扱う仕組みを持たなければならない。バージョンと継承管理はレ
コード・エントリ内容、かつ/あるいは経時的状態変化に基づく。バージョンは次の１つかもしれない:
1)完了し保証されたレコード・エントリ; 2)完了し 1 回以上修正されたことが保証されたレコード・
エントリ; 3)著者ではない個人によって臨床的な意思決定のために参照されたレコード・エントリ; 4)
組織のビジネス・ルールにより不完全な状態で取得されたレコード・エントリで継時的に更新されたもの（たとえば検体検査の仮結果）; 5)著者によって選択的に、ある時点における現在の状態で保持されているレコード・エントリ（たとえば、病歴と身体所見）。あるタイプのレコード・エントリは通常複数のバージョンで扱われる（仮結果と最終結果）-口述筆記したレポート-精密検査（複数日程にわたるコース）。レコード・エントリの前バージョンは実施範囲や組織ポリシー、管轄地域の法律に従って、法的に定められた時間フレームの中で保持しなければならない。
2. The system SHALL provide the ability to update a Record 2157
Entry and save it as a new version.
2. システムはレコード・エントリを更新し、それを新バージョンとして保存できなければならない。
3. The system SHALL capture, maintain and render the 2158
date, time and user for the original and each updated
version of the Record Entry.
3. システムは日付、時刻、オリジナルと各更新バージョンのレコード・エントリの利用者情報を取得、保持、表示できなければならない。
4. The system SHALL manage the succession of Record 2159
Entries in chronological version order.
4. システムはレコード・エントリの遷移を発生順のバージョン順序で管理できなければならない。
RI.1.3.42160
FunctionManage Record Entry
Retraction
レコード・エントリ撤回
管理Statement: Remove a record entry from view if it is deemed erroneous and cite the reason.
機能概要：レコード・エントリが間違っていると判断されその理由を言及する場合に、ビューからレ
コード・エントリを削除する
Description: Record retraction is used to reverse changes that have been made to existing Record
Entries. Once a Record Entry has been retracted, it is no longer visible in standard queries, though
it remains accessible in EHR audit records should evidence ever be required for legal or otherexceptional circumstances.Canada Health Infoway provides the following definition for retraction:
This mechanism allows an existing record to be “removed” from the EHR if it is deemed erroneous.
It can also be used to reverse changes that have been made to an existing record. Once a record
has been retracted, it is no longer visible in standard queries, though it remains accessible in EHR
audit records should evidence ever be required for legal or other exceptional circumstances. After
retracting an erroneous record, a user has the ability to resubmit a corrected record with no visible
indication that there was ever a previous version. Retract generally has significant constraints
upon its use because of the risks of removing data from a patient’s record that might have beenused by others in making decisions. The specifics will vary by jurisdiction, and potentially even bytype of data.There are times that a EHR Record Entry is created then found to be erroneous, i.e.,
the record may belong to another individual. In these cases, it is necessary to remove that record
from view (storing it in case it may be needed for litigation or investigation purposes, etc.). After
retracting an erroneous record, a user has the ability to resubmit a corrected record with no visible
indication that there was ever a previous version.
機能説明：レコード撤回は、存在するレコ－ド・エントリに対して行われる逆変化に用いられる。一度レコード・エントリが撤回されると、それは標準的な問い合わせではもはや参照することはできな
いが、EHR 監査記録の中に残存し法的あるいはそのほかの例外的な環境において要求される際のエビデンスとしてアクセスできる。カナダ・ヘルス・インフォウェイは、撤回に関して次の定義を行っている:存在するレコードが間違っていると判断された際に、それを EHR から「削除される」ことを許可するメカニズム。撤回は存在するレコードに対して行われる逆方向の変化についても使用される。一旦レコードが撤回されると、それはもはや標準的な問い合わせでは参照できないが、EHR 監
査記録の中に残存し法的あるいはそのほかの例外的な環境において要求される際のエビデンスとしてアクセスできる。間違ったレコードを撤回した後、利用者は、旧バージョンがあることの表示がない状態で、正しいレコードを再提出することができる。患者記録から他の人が意思決定に使用するかもしれないデータを削除するリスクがあるため、撤回は一般的にその使用については大きな制約を伴う。詳細は管轄区域によって異なるし、データのタイプによっても異なるであろう。EHR レコード・
エントリが作成されてから間違いが発見されるには、時間が経過します、つまりレコードは他の個人に属するかもしれない。このような場合、ビューからレコードを消す必要がある（訴訟や調査目的で必要になる場合に備えてレコードの保存はする）。間違えたレコードを撤回した後は、利用者は、旧バージョンがあることの表示がない状態で、正しいレコードを再提出することができる。
1. The system SHALL provide the ability to hide a Record 2161
Entry from view and retain it such that it is only visible
upon specific request and with appropriate
authorization.
1. システムはビューからレコード・エントリを隠すことができ、また適切な許可の元で特別な要求によってのみ参照可
能な形でレコードを保持できなければならない。
4. The system SHALL conform to function RI.1.1.17 2164
(Deprecate/Retract Record Entries).
4. システムは RI1.1.17(レコード・エントリ廃止/撤回)に適合しなければならない。
RI.1.42165
Function
Record Completeness
レコード完結性Statement: Manage Record Completeness
機能概要：レコード完結性の管理
Description: The EHR-S must provide the ability for an organization to define minimum elements
and timeframes for completion at the report level and at the record level. Provide a report that
identifies completion and timeliness status by patient/ health record number or other specified
parameters. Prior to disclosure for legal proceedings or other official purposes, an organization
analyzes the health record for completeness. EHR systems must provide the ability to define aminimum set of content to be analyzed for timeliness and completeness and provide a report ofthe status.
機能説明：EHR システムは、組織にとって、レポートのレベルとレコードのレベルにおける完結性に対する最低限の要素と時間フレームを定義できなければならない。患者/健康レコード番号あるいは特定のパラメータによって、完成と適時性を識別したレポートを提供する。法的手続きや公的目的に関する開示に先立って、組織は健康レコードの完結性を分析する。EHR システムは、適時性や完結性を分析するための内容のミニマム・セットを定義する機能を提供でき、ステータスのレポートを提供できる。
1. The SHALL provide the ability to manage timeframes for 2166
completion of specified Record Entry content according
to organizational business rules.
1. システムは組織のビジネス・ルールに従って特定のレコー
ド・エントリ内容の完成のための時間フレームを管理できなければならない。
RI.2
2171
Function
Record Synchronization
レコード同期Statement: Manage Record Synchronization
機能概要：レコード同期の管理
Description: An EHR-S may consist of a set of components or applications; each application

manages a subset of the health information. Therefore it is important that, through various
interoperability mechanisms, an EHR-S maintains all the relevant information regarding thehealth record in synchrony. For example, if a physician orders an MRI, a set of diagnostic images
and a radiology report will be created. As a result, the patient demographic information, the orderfor MRI, the diagnostic images associated with the order, and the report associated with the study
must all be synchronized in order for the clinicians to receive a synchronized view the complete
record (with respect to time and geographic location).Date and time need to be consistent acrossthe applications that are part of the EHR system.Synchronization demonstrates a sequence andchain of events for reconstruction and is relevant during a legal proceeding. Maintenance ofsynchronization activities could be relevant during a legal proceeding.Note: Standards exist for
Consistent Date and Time.
機能説明：EHR システムはコンポーネントあるいはアプリケーションのセットから構成されるかもしれない；各アプリケーションは健康情報のサブセットを管理している。それゆえに、様々な相互運用性メカニズムがあるけれども、EHR システムは同期する健康レコードのすべての関連性のある情報を保持している。たとえば、医師が MRI オーダをした際には、診断画像のセットと放射線レポー
トが作成される。その結果、患者基本情報、MRI オーダ、そのオーダに紐付く診断画像、その検査に紐付くレポートは、臨床医にとってすべて順番に同期して、完結したレコードの同期したビューが受領できるべきである（時間と場所に配慮して）。日付と時刻情報はアプリケーション全体で一貫性があるべきである。同期性は、再構成のためのイベントの順序と連続性を保証し、法的手続きにも関連する。同期性の維持活動は法的手続きに関連する可能性がある。注: 日付と時刻の一貫性に関する標準が存在する。
1. The system SHALL conform to function TI.5.1 2172
(Application and Structured-Document InterchangeStandards).
1. システムは TI5.1(アプリケーションと構造化文書交換標準)に適合しなければならない。
5. The system SHALL provide the ability to manage date 2176
and time-related information between applications,components, services, systems, and devices.
5. システムは、アプリケーション、コンポーネント、サービ
ス、システム、デバイス間の日付と時刻関連情報を管理する機能を提供しなければならない。
RI.3
2177
Function
Record Archive andRestore レコード保管と復元
Statement: Manage Record Archive and Restore
機能概要：レコード保管と復元の管理
Description: EHR Record Entries must be transitioned over its lifecycle from online data
structures to near-line or off-line data structures. The archive function performs this transition ofRecord Entries from an online, production EHR-S to offline storage for information that is not
being purged/destroyed. The system must provide such archive and restore functions to extract
and preserve indefinitely, Record Entries selected to be removed from the live production EHR-S
database and retained. Record Entries must be archived and restored in such a manner as topermit them to be returned to their original or similar information structures. Archived Record
Entries must also include corresponding metadata to ensure logical and semantic consistency of
the information for subsequent access upon restoration. The archive function should provide bothan automated, configurable capability as well as a user-invoked archival function to enable
selected Record Entries to be preserved, or flagged for preservation.
In the first instance, rules are specified to enable the system to conduct archiving in an unattended
fashion. This is often the case for periodic system maintenance requirements (e.g., nightly
processing where archival, data summarization and possibly purging of information occurs). In
the second instance the system should provide the ability to select Record Entries to be preserved
for future reference and access, such as in the case where selected Entries need to be preserved
and retained for litigation.In restoring information, it may occur that Record Entries being
restored are a subset of the Entries originally archived. For example, when all Record Entries fora patient encounter were archived and only a particular set of Record Entries related to a study
or result are to be restored. The system may provide for such finer granularity of
restoration.Archiving and restoring of Record Entries must be performed in a timely fashion,
consistent with the operational requirements of both EHR users and system and technology
capabilities.The system must enable compliance with records retention according to scope ofpractice, organizational policy or jurisdictional law.
機能説明：EHR レコード・エントリは、そのライフサイクルにわたって、オンラインデータ構造からニアラインあるいはオフラインデータ構造に推移する必要がある。保管機能は、情報が消去/破壊されないように、オンラインの EHR システム製品からオフラインのストレージまで、レコード・エント
リの推移を実現する。システムは抽出し永久に保持するために、保管や復元機能を提供し、レコード・
エントリを稼動している EHR システムデータベースから削除や保持されるために選択する。レコー
ド・エントリは、元のあるいは似たような情報構造に戻ることが許可されるように、保管や復元すべきである。保管されたレコード・エントリは、復元時にアクセスする際の情報の論理的・意味的整合性を確保するための対応したメタデータも含まなければならない。保管機能は自動的で、設定可能な機能であるだけではなく、利用者が呼び出すことができる選択したレコード・エントリを保存あるいは保存するためのフラグ付けをすることができる保管機能が提供されるべきである。
最初の例は、システムが操作者なしで保管を行うためのルールが設定されている。これは定期的なシ
ステム保守要件としてよくあるケースである（例えば、保管、データ集約、あるいは情報の削除は発生するような夜間プロセス）。第二の例は、システムは将来の参照やアクセスのために保持すべきレ
コード・エントリを選択できるべきで、例えば、あるエントリは訴訟のために保存・保持する必要がある。情報を復元する際に、復元されるレコード・エントリは元々保管されたエントリのサブセット
であることがある。例えば、患者の出来事のすべてのレコード・エントリが保管され、ある検査や結果に関連した特定のレコード・エントリのセットのみが復元される。システムはこのような細かい粒度の復元機能を提供するかもしれない。レコード・エントリの保管と復元は、タイムリーに、EHR 利
用者とシステムの両方の運用要件に一致し、システムと技術能力の元で、実行されなければならない。
システムは、実施範囲や組織ポリシー、管轄地域の法律に従って、レコード保持の遵守をしなければならない。
1. The system SHALL provide the ability to archive and 2178
restore Record Entries according to scope of practice,organizational policy, and/or jurisdictional law (e.g.,
to/from off-line or near-line media).
1. システムは実施範囲、組織ポリシー、かつ/あるいは管轄地
域の法律に従って、レコード・エントリの保管と復元ができなければならない（例えば、オフラインあるいはニアラ
インのメディアへあるいはメディアから）
2. The system SHALL provide the ability for an authorized 2179
user to tag and untag Record Entries to be archived.
2. システムは、権限をもつ利用者が、保管するレコード・エ
ントリにタグ付けしたりタグをはずす機能を提供しなけ
ればらない。
3. The system SHALL provide the ability to archive or 2180
restore metadata that is associated with Record Entries
that have been archived or restored.
3. システムは保管あるいは復元されたレコード・エントリに関連したメタデータを保管あるいは復元する機能を提供しなければならない。
8. The system SHALL provide the ability to manage 0(configure) archival parameters for Record Entries (e.g.,what and when to archive).
8. システムはレコード・エントリの保管パラメータを管理（設定）する機能を提供しなければならない（例えば、何が、いつ保管されたか）。

7. Trust Infrastructure Section

Section/id#：
Type:
Name:
TI.1
Header
Security

Conformance Criteria

Row#
2185

Statement: Manage EHR-S security.
機能概要：EHR-S セキュリティマネジメント
Description: EHR-S security consists of entity authentication, entity authorization, entity access
control, patient access management, secure data exchange, attestation, patient privacy andconfidentiality. EHR audit functions are described in TI.2.
機能説明：EHR-S セキュリティは、エンティティ認証、エンティティ認可、エンティティアクセス制
御、患者アクセス管理、安全なデータ交換、検証、患者のプライバシーと機密性から構成されています。 EHR 監査機能は TI.2 に記述されています。
TI.1.1
2186
Function
Entity Authentication
Statement: Authenticate EHR-S users, and/or entities before allowing access.
機能概要：アクセスを許可する前に EHR システムユーザおよび/またはエンティティを認証する。
Description: All entities accessing the EHR-S are subject to authentication.Examples of entity
authentication, with varying levels of authentication rigor, include: - username/password;- digital
certificate;- secure token;- biometrics.
機能説明：EHR システムにアクセスするすべてのエンティティは認証の対象となります。さまざまなレベルの厳密さのエンティティ認証の例は以下の通り - ユーザ名/パスワード、 - デジタル証明書、 - セキュアトークン、 - バイオメトリクス。
1. The system SHALL authenticate entities (e.g., users, 2187
organizations, applications, components, objects, and/or
devices) accessing EHR-S protected resources (e.g., functions
and data) according to scope of practice, organizational policy,
and/or jurisdictional law, using an authentication mechanism
such as an accredited Standards Development Organizationapproved authentication standard (e.g., SAML, WS-Trust,
Kerberos), username/password, digital certificate, secure
token,
biometric,or
hardware-specificaddressing
mechanism. (See also ISO 22600.)

2.

3.

システムは、実務の範囲、組織の方針、および/または管轄法に従って、EHR システムで保護されたリソース（機能やデータなど）にアクセスするエンティティ（例えば、ユーザ、組織、ア
プリケーション、コンポーネント、オブジェクト、および/またはデバイス）を認証しなければならない。その際、認定された標準化機関によって承認された認証標準（SAML、WS-Trust、
Kerberos など）、ユーザ名/パスワード、デジタル証明書、セキュアトークン、バイオメトリック、またはハードウェア固有のアドレス指定メカニズムなどの認証メカニズムを使用する。
（ISO 22600 も参照のこと。）
The system SHALL manage authentication data/information 2188
securely (e.g., passwords or biometric data).
システムは、認証データ／情報（例えば、パスワードまたはバイオメトリックデータ）を安全に管理しなければならない。
The system SHALL maintain configurable conditions andrules which protect against invalid, possibly malicious,
authentication attempts according to organizational policy,

2189

Section/id#：
Type:
Name:

Conformance Criteria

Row#

and/or jurisdictional law (e.g., consecutive invalid logon
attempts).

4.

システムは、組織の方針および/または管轄法に従った無効な、おそらく悪意のある、認証の試み（例えば、連続した無効なログオンの試み）から保護する設定可能な条件および規則を維持しなければならない。
IF passwords are used to control access to the EHR-S, THEN 2190
the system SHALL provide the ability to maintainconfigurable timeframes (e.g., 180 days) for the reuse ofpasswords according to organizational policy, and/or
jurisdictional law.

5.

パスワードが EHR システムへのアクセスを制御するために使用されている場合、システムは、組織の方針および/または管轄法に従ってパスワードを再利用するための設定可能な時間枠（例えば 180 日）を維持する能力を提供しなければならない。
IF passwords are used to control access to the EHR-S, THEN 2191
the system SHALL provide the ability to maintain aconfigurable limit on the reuse of recently used passwords(e.g., the last 5 passwords) according to organizational policy,
and/or jurisdictional law.

6.

7.

8.

9.

パスワードが EHR システムへのアクセスを制御するために使用されている場合、システムは組織の方針および／または管轄法に従って最近使用されたパスワード（例えば最後の 5 つのパスワード）の再使用に対する設定可能な制限を維持する能力を提供すること。
IF username/passwords are used to control access to the 2192
EHR-S, THEN the system SHALL maintain password
strength rules (e.g., requiring a minimum number ofcharacters and inclusion of alphanumeric complexity).
ユーザ名／パスワードがＥＨＲ システムへのアクセスを制御するために使用される場合、システムはパスワード強度規則を維持しなければならない（例えば、最小文字数と英数字の複雑さの包含を要求する）。
IF passwords are used to control access to the system, THEN
the system SHALL capture the passwordti. using obfuscation
techniques (e.g., during user password entry) according toscope of practice, organizational policy, and/or jurisdictional
law.

2193

システムへのアクセスを制御するためにパスワードが使用されている場合、システムは passwordti を実践の範囲、組織の方針、および/または管轄法に従って、難読化技術を用いて記録しなければならない。
（たとえば、ユーザのパスワード入力中）
IF passwords are used to control access to the EHR-S, THEN 2194
the system SHALL manage password reset as anadministrative function.
パスワードが EHR システムへのアクセスを制御するために使用される場合、システムは管理機能としてパスワードリセットを管理しなければならない。
IF user passwords are initially set or later reset by anadministrator, THEN the system SHALL provide the ability
to update password at the next successful logon.

2195

Section/id#：
Type:
Name:

Conformance Criteria
ユーザパスワードが最初に設定された、または後で管理者によってリセットされた場合、システムは次回の正常なログオン時にパスワードを更新する機能を提供しなければならない。
10. The system SHALL present limited feedback to the user
during authentication.

Row#

2196

システムは、認証中に限られたフィードバックをユーザに提示しなければならない。
11. The system SHALL provide the ability to enter caseinsensitive 'usernames' that contain typeable alpha-numericcharacters in support of ISO-646/ECMA-6 (aka US ASCII).

2197

システムは、ISO-646 / ECMA-6（別名 US ASCII）をサポート
する、入力可能な英数字を含む大文字と小文字を区別しない「ユーザ名」を入力する機能を提供しなければならない。
12. IF passwords are used, THEN the system SHALL provide theability to enter case-sensitive passwords that containtypeable alpha-numeric characters in support of ISO646/ECMA-6 (aka US ASCII).

2198

パスワードが使用される場合、システムは ISO-646 / ECMA-6（別名 US ASCII）をサポートする入力可能な英数字を含む大文字と小文字を区別するパスワードを入力する機能を提供しなければならない。
TI.1.2Function
Entity Authorization

2199

Statement: Manage set(s) of EHR-S access control permissions.
機能概要：EHR システムアクセス制御権限のセットのマネジメント
Description: Entities are authorized to use components of an EHR-S in accordance with their scopeof practice within local policy or legal jurisdiction. Authorization rules provide a proper framework
for establishing access permissions and privileges for the use of an EHR system, based on user,role or context. A combination of these authorization categories may be applied to control access
to EHRS resources (i.e., functions or data), including at the operating system level.- User based
authorization refers to the permissions granted to access EHR-S resources based on the identityof an entity (e.g., user or software component). - Role based authorization refers to the permissions
granted to access EHR-S resources based on the role of an entity. Examples of roles include: anapplication or device (tele-monitor or robotic); or a nurse, dietician, administrator, legal guardian,
and auditor. - Context-based Authorization refers to the permissions granted to access EHR-S
resources within a context, such as when a request occurs, explicit time, location, route of access,quality of authentication, work assignment, patient consents and authorization. See ISO 10181-3
Technical Framework for Access Control Standard. For example, an EHR-S might only allow
supervising providers’ context authorization to attest to entries proposed by residents under theirsupervision.
機能説明：エンティティは、現地の方針または法的管轄内での実務の範囲に従って、EHR システムの構成要素を使用することを許可されている。承認規則は、ユーザ、役割、またはコンテキストに基づいて、EHR システムを使用するためのアクセス許可と特権を確立するための適切なフレームワー
クを提供する。これらの認証カテゴリの組み合わせは、オペレーティングシステムレベルを含む、
EHRS リソース（すなわち、機能またはデータ）へのアクセスを制御するために適用されることがある。 - ユーザベース認証はエンティティ（例えば、ユーザまたはソフトウェアコンポーネント）の識
別情報に基づいてＥＨＲ − Ｓリソースにアクセスするために与えられた許可を指す。 - 役割ベース
認証とは、エンティティの役割に基づいて EHR システムリソースにアクセスするために付与される許可を指す。役割の例には、次のものがあります。アプリケーションまたはデバイス（テレモニター

Section/id#：
Type:
Conformance Criteria
Row#
Name:
またはロボット）。または看護師、栄養士、管理者、法定後見人、および監査人。 - コンテキストベ
ース認証とは、要求が発生したとき、明示的な時間、場所、アクセスの経路、認証の質、作業の割り
当て、患者の同意、承認など、コンテキスト内で EHR システムリソースにアクセスするために与えられる許可を指す。アクセス制御規格の ISO 10181-3 テクニカルフレームワークを参照してください。例えば、EHR システムは、監督下にあるプロバイダーのコンテクスト認証が、その監督下で居住者によって提案されたエントリを証明することのみを許可するかもしれません。
1. The system SHALL provide the ability to manage sets of 2200
access-control permissions granted to an entity (e.g., user,
application, device) based on identity, role, and/or context
according to scope of practice, organizational policy, and/or
jurisdictional law.
システムは、実務の範囲、組織の方針、および/または、/または、 -管轄法に応じて、識別情報、役割、および/またはコンテ
キストに基づいて、エンティティ（ユーザ、アプリケーション、
デバイスなど）に付与されたアクセス制御許可のセットを管理できる 機能を提供しなければならない。
2. The system SHALL conform to TI.2 (Audit) to audit 2201
authorization actions as security events.
システムは、セキュリティイベントとしての許可動作を監査するために TI.2（監査）に適合しなければならない。
3. The system SHALL provide the ability to manage roles (e.g.,clinician versus administrator) and contexts (e.g., legal
requirements versus emergency situations) for authorizationaccording to scope of practice, organizational policy, and/or
jurisdictional law.

2202

システムは、実施の範囲、組織の方針、および／または管轄法に従って承認のための役割（例えば、臨床医対管理者）および状況（例えば法的要件対緊急事態）を管理する能力を提供しなければならない。
4. The system SHALL maintain a revision history of all entity 2203
record modifications.
システムは、すべての実体記録の修正の改訂履歴を維持しなけ
ればならない。
TI.1.3Function
Entity Access Control

2205

Statement: Manage access to EHR-S resources.
機能概要：EHR システムリソースへのアクセスマネジメント
Description: To ensure access is controlled, an EHR-S must authenticate and check authorizationof entities for appropriate operations.
機能説明：アクセスが確実に管理されるようにするために、EHR システムは適切な操作のためにエンティティの認可を確認し、認証しなければなりません。
1. The system SHALL conform to function TI.1.1 (Entity 2206
Authentication).
システムは、機能 TI.1.1（エンティティ認証）に適合しなければならない。
2. The system SHALL conform to function TI.1.2 (Entity
Authorization).

2207

Section/id#：
Type:
Name:

Conformance Criteria

Row#

システムは、機能 TI.1.2（エンティティ認証）に適合しなければならない。
3. The system SHALL provide the ability to manage system anddata access rules for all EHR-S resources according to scopeof practice, organizational policy, and/or jurisdictional law.

2208

システムは、業務の範囲、組織の方針、および/または管轄法に従って、すべての EHR システムリソースのシステムおよびデータアクセス規則を管理する機能を提供しなければならない。
4. The system SHALL manage the enforcement of 2209
authorizations to access EHR-S resources.
システムは、EHR システムリソースにアクセスするための認可の執行を管理しなければならない。
5. The system SHALL control access to EHR-S resources after aconfigurable period of inactivity by terminating the session,or by initiating a session lock that remains in effect until theentity re-establishes access using appropriate identification
and authentication procedures, according to organizational
policy, and/or jurisdictional law.
システムは、組織の方針および／または管轄法にもとづき設定可能な非アクティブ期間の後、セッションを終了するか、または組織が適切な識別および認証手順を使用してアクセスを再確立するまで有効なセッションロックを実施することによって EHR システムリソースへのアクセスを制御しなければならない。
7. The system SHALL control-access to data, and/or
functionality by using authentication mechanisms thatcomply with regulatory and policy guidelines (e.g.,by using a
combination of Username and Password, Digital Certificates,
Secure Tokens, and/or Biometrics).

2210

0

システムは、規制および方針のガイドラインに準拠した認証メ
カニズムを使用して（例：ユーザ名とパスワード、デジタル証
明書、セキュアトークン、および/またはバイオメトリクスを使用して）データおよび/または機能へのアクセスを制御しなければならない。
TI.1.3.1
Function
Emergency
Control

2211
AccessStatement: Manage emergency access to EHR-S resources.
機能概要：EHR システムリソースへの緊急アクセスマネジメント
Description: The intent of Emergency Access Control is to mitigate the potential for impeding theprovision of care in an emergency situation in accordance with organizational policy.For example,
emergency access may include: 1) Single record entry (e.g., single laboratory results, single
document, single view); 2) Single patient; 3) Single login session, multiple patients; 4) Site mode
allowing simultaneous emergency access to all users.Logging of a user’s activities should occur inthe audit record/metadata. Reports of emergency access use for follow up are critical forcompliance and monitoring.
機能説明：緊急アクセス管理の目的は、組織の方針に従って、緊急事態におけるケア提供を妨げる可能性を軽減することです。例えば、緊急アクセスには、次のものが含まれます。1) 単一の記録エント
リ（例えば、単一の検査結果、単一の文書、単一のビュー）。 ２）一人の患者。 3）シングルログイ

Section/id#：
Type:
Conformance Criteria
Row#
Name:
ンセッション、複数の患者。 4）すべてのユーザに同時に緊急アクセスを許可するサイトモード。ユーザの活動の記録は監査記録/メタデータで行われるべきです。 フォローアップのための緊急アクセス使用の報告は、コンプライアンスと監視にとって重要です。
1. The system SHALL provide the ability to define emergency 2212
access rules according to scope of practice, organizational
policy, and/or jurisdictional law.
システムは、実践の範囲、組織の方針、および/または管轄法に従って緊急アクセス規則を定義する機能を提供しなければならない。
2. The system SHALL manage emergency access by individual
users based on criteria (e.g., defined rules and categories)
according to organizational policy, and/or jurisdictional law.

2214

システムは、組織の方針および／または管轄法に従って、基準（例えば、定義された規則およびカテゴリ）に基づいて個々のユーザによる緊急アクセスを管理しなければならない。
3. The system SHALL provide the ability to maintain 2215
emergency access time limits according to scope of practice,organizational policy, and/or jurisdictional law.
本システムは、業務の範囲、組織の方針、および/または管轄法に従って緊急アクセス時間制限を維持する機能を提供しなけ
ればならない。
6. The system SHALL provide the ability to capture a reason for
emergency access.
システムは緊急アクセスの理由を把握する機能を提供しなけ
ればならない。
7. The system SHALL provide the ability to render an after
action report for follow up of emergency access.

2217

2218

システムは、緊急アクセスのフォローアップのために行動後報告を提出する機能を提供しなければならない。
TI.1.4
Function
Patient
Management

2219
AccessStatement: Manage a patient’s access to personal health information.
機能概要：個人の健康情報への患者のアクセスマネジメント
Description: A healthcare delivery organization will be able to manage a patient’s ability to viewhis or her EHR based on organization policy or jurisdictional law. Typically, a patient or their legal
representative (e.g., guardian, surrogate) has the right to view his or her EHR.
機能説明：医療提供組織は、組織の方針または管轄法に基づいて、患者の EHR を表示するための患者の能力を管理することができる。 典型的には、患者または彼らの法定代理人（例えば、保護者、代理人）は、彼または彼女のＥＨＲを見る権利を有する。
1. IF organizational policy allows patient access to the EHR-S, 2220
THEN the system SHALL conform to Function TI.1.3 (Entity
Access Control).
組織の方針が患者の EHR システムへのアクセスを許可する場
合、システムは機能 TI.1.3（エンティティアクセス制御）に適合しなければならない。
2. IF organizational policy allows patient access to the EHR-S,

2221

Section/id#：
Type:
Name:

Conformance Criteria

Row#

THEN the system SHALL conform to Function TI.1.2 (Entity
Authorization).
組織の方針が患者の EHR システムへのアクセスを許可する場
合、システムは機能 TI.1.2（エンティティ認証）に適合しなければならない。
TI.1.5Function
Non-Repudiation

2222

Statement: Limit an EHR-S user's ability to deny (repudiate) data origination, transmission orreceipt by that user.
機能概要：そのユーザによるデータの発信、送信、または受信を拒否（拒否）するために EHR-S ユーザの能力を制限する。
Description: An EHR-S allows data entry to a patient's electronic health record and it can be asender or receiver of healthcare information. Non-repudiation is a way to guarantee that thesource of the data/record cannot later deny that fact; and that the sender of a message cannot later
deny having sent the message; and that the recipient cannot deny having received the message.
Components of non-repudiation can include: - Digital signature, which serves as a unique
identifier for an individual (much like a written signature); - Confirmation service, which utilizes
a message transfer agent to create a digital receipt (providing confirmation that a message wassent, and/or received); - Timestamp, which proves that a document existed at a certain date andtime; - The use of standardized timekeeping protocols (e.g., the Integrating the Healthcare
Enterprise (IHE) Consistent Time Profile).
機能説明：EHR システムは、患者の電子健康記録へのデータ入力を可能にし、それは健康管理情報の送信者または受信者になり得る。 否認防止は、データ/レコードのソースが後でその事実を否定できないことを保証する方法である。 そして、メッセージの送信者が後でそのメッセージを送信した
ことを否定することはできない。 受信者がメッセージを受信したことを否定することはできない。
否認防止のコンポーネントには、次のものが含まれる。 - デジタル署名。個人の一意の識別子として機能する（書面による署名とよく似ている）。 - 確認サービス。メッセージ転送エージェントを利用してデジタルレシートを作成する（メッセージが送信された、および/または受信されたことの確認を提供する）。 - タイムスタンプ。文書が特定の日時に存在したことを証明する。 - 標準化された計時プロトコル（例えば、the Integrating the Healthcare Enterprise（ＩＨＥ）CT プロファイル）の使用。
1. The system SHALL capture the identity of the entity taking
the action according to scope of practice, organizational policy,
and/or jurisdictional law.
システムは、実務の範囲、組織の方針、および/または管轄法に従って行動を起こす事業体の身元を記録しなければならない。
2. The system SHALL capture time stamp of the initial entry,
modification and exchange of data according to scope ofpractice, organizational policy, and/or jurisdictional law.
システムは、業務の範囲、組織の方針、および/または管轄法に従って、データの最初の入力、変更、および交換のタイムスタ
ンプを記録しなければならない。
3. The system SHALL conform to function TI.2 (Audit) toprevent repudiation of data origination, transmission andreceipt according to scope of practice, organizational policy,
and/or jurisdictional law.
システムは、業務の範囲、組織の方針、および/または管轄法に従ったデータの発信、送受信の拒否を防止するために、機能
TI.2（監査）に適合しなければならない。

Section/id#：
Type:
Name:
TI.1.6Function
Secure Data Exchange

Conformance Criteria

Row#
2227

Statement: Secure all modes of EHR data exchange.
機能概要：EHR データ交換のすべてのモードの保護
Description: Whenever an exchange of EHR information occurs, it requires appropriate security
and privacy considerations, including data obfuscation as well as both destination and source
authentication when necessary. For example, it may be necessary to encrypt data sent to remoteor external destinations.
機能説明：EHR 情報の交換が発生するときはいつでも、それは必要に応じて送信先と送信元の両方の認証と同様にデータ難読化を含む適切なセキュリティとプライバシーの考慮を必要とします。 たとえば、リモートまたは外部の宛先に送信されるデータを暗号化する必要があるかもしれません。
1. The system SHALL secure all modes of EHR data exchange. 2228
システムは、EHR データ交換のすべてのモードを保護しなけ
ればならない。
2. The system SHALL conform to function TI.1.7 (Secure Data
Routing).
システムは、機能 TI.1.7（セキュアデータルーティング）に適合しなければならない。
3. The system SHALL encrypt and decrypt EHR data that is
exchanged over a non-secure link.

2229

2231

システムは、非セキュアリンク上で交換される EHR データを暗号化および復号しなければならない。
4. IF encryption is used, THEN the system SHALL exchange 2232
data using
recognized
standards-based
encryption
mechanisms according to organizational policy, and/or
jurisdictional law.
暗号化が使用される場合、システムは、組織の方針および/または管轄法に従って、承認された標準ベースの暗号化メカニズムを使用してデータを交換しなければならない。
8. The system SHALL provide the ability to determine static ordynamic addresses for known and authorized sources anddestinations.

2234

システムは、既知および許可されている送信元および送信先の静的アドレスまたは動的アドレスを決定する機能を提供しなければならない。
TI.1.7
Function
Secure Data Routing

2235

Statement: Route electronically exchanged EHR data only to/from known and authenticateddestinations/sources (according to applicable healthcare-specific rules and relevant standards).
機能概要：電子的に交換された EHR データを、既知の認証された送信先/送信元との間でのみ（該当するヘルスケア固有の規則および関連規格に従って）ルーティングする。
Description: An EHR-S needs to ensure that it is exchanging EHR information with the entities(applications, institutions, directories) it expects. This function depends on entity authorization
and authentication to be available in the system. For example, a physician practice management
application in an EHR-S might send claim attachment information to an external entity. To

Section/id#：
Type:
Conformance Criteria
Row#
Name:
accomplish this, the application must use a secure routing method, which ensures that both thesender and receiving sides are authorized to engage in the information exchange. Known sourcesand destinations can be established in a static setup or they can be dynamically determined.
Examples of a static setup are recordings of IP addresses or recordings of DNS names. For dynamic
determination of known sources and destinations systems can use authentication mechanisms as
described in IN.1.For example, the sending of a laboratory order from the EHRS to a laboratory
system within the same organization usually uses a simple static setup for routing. In contrast
sending a laboratory order to a reference laboratory outside of the organization will involve somekind of authentication process. Provision of a secure network infrastructure is beyond the scopeof an EHR-S.
機能説明：EHR システムは、EHR 情報が期待するエンティティ（アプリケーション、機関、ディレクトリ）と EHR 情報を交換していることを確認する必要がある。この機能は、システムで利用可能になるエンティティの認証と認可に依存する。たとえば、EHR システム内の医師診療管理アプリケーションは、請求添付情報を外部のエンティティに送信することがある。これを達成するために、ア
プリケーションは送信側と受信側の両方が情報交換に従事することを許可されることを保証する安
全なルーティング方法を使用しなければならない。既知の発信元および発信先は、静的設定で確立することも、動的に決定することもできる。静的設定の例としては、IP アドレスの記録や DNS 名の記録がある。既知の送信元および送信先の動的決定のために、システムは IN.1 に記述されているような認証メカニズムを使用することができる。たとえば、EHRS から同じ組織内のラボシステムへのラ
ボオーダの送信では、通常、ルーティングに単純な静的設定を使用する。これとは対照的に、組織の外部の検査会社に検査オーダを送信することは、ある種の認証プロセスを伴うことになる。安全なネットワークインフラストラクチャの提供は EHR システムの範囲外である。
1. The system SHALL conform to function TI.1.1 (Entity 2236
Authentication) to exchange EHR data only to and fromknown, authenticated sources and destinations.
システムは、既知の認証された発信元および発信先との間でのみ EHR データを交換するために、機能 TI.1.1（エンティティ
認証）に適合しなければならない。
2. The system SHALL conform to Section TI.2 (Audit) to capture
audit information about changes to the status of sources anddestinations.

2237

システムは、送信元および送信先のステータスの変更についての監査情報を取り込むために、セクション TI.2（監査）に準拠しなければならない。
TI.1.8Function
Patient Privacy
Confidentiality

2238
and

Statement: Enable the enforcement of the applicable jurisdictional and organizational patient
privacy rules as they apply to various parts of an EHR-S through the implementation of security
mechanisms.
機能概要：セキュリティメカニズムの実装を通じて、EHR システムのさまざまな部分に適用される、管轄区域および組織の患者のプライバシー保護規則の施行を可能にする。
Description: Patients’ privacy and the confidentiality of EHRs are violated if access to EHRs occurs
without authorization. Violations or potential violations can impose tangible economic or social
losses on affected patients, as well as less tangible feelings of vulnerability and pain. Fear of
potential violations discourages patients from revealing sensitive personal information that may
be relevant to diagnostic and treatment services. Rules for the protection of privacy andconfidentiality may vary depending upon the vulnerability of patients and the sensitivity ofrecords. Strongest protections should apply to the records of minors and the records of patientswith stigmatized conditions. Authorization to access the most sensitive parts of an EHR is mostdefinitive if made by the explicit and specific consent of the patient. Please see the definition ofSection/id#：
Type:
Conformance Criteria
Row#
Name:
masking in the glossary.Organizational practices related to privacy and security jurisdictionallaws could be called into question during a legal proceeding. Adherence to applicable laws supports
the credibility and trustworthiness of the organization.
機能説明：認可なしに EHR へのアクセスが発生すると、患者のプライバシーと EHR の機密性が侵害されます。違反または潜在的な違反は、影響を受ける患者に明白な経済的または社会的損失をもたらす可能性があるだけでなく、脆弱性および痛みに対する明白な感情の減少ももたらします。診断および治療サービスに関連する機密の個人情報が潜在的な違反に対する恐れがあることを患者に開示することをお勧めします。プライバシーと機密性の保護に関する規則は、患者の脆弱性および記録の機密性にとても依存しています。未成年者の記録および偏見のある患者の記録には、最も厳重な保護を適用する必要があります。患者の明示的かつ具体的な同意によって行われた場合、EHR の最も機
密性の高い部分にアクセスする許可が最も決定的になります。用語集のマスキングの定義を参照してください。プライバシーおよびセキュリティ管轄法に関連する組織的慣行は、訴訟手続の際に問題になる可能性があります。適用法の遵守は、組織の信頼性と信頼性を裏付けます。
1. The system SHALL provide the ability to maintain 2239
compliance with requirements for patient privacy andconfidentiality according to scope of practice, organizational
policy, and/or jurisdictional law (e.g., US HIPAA Privacy
Rules, US Federal Conditions of Participation for
Medicare/Medicaid Providers).
システムは、実務の範囲、組織の方針、および/または管轄法（例：
米国 HIPAA のプライバシー規則、米国のメディケア参加条件/メディケイド提供者）に従って、患者のプライバシーおよび機密保持の要件への準拠を維持する機能を提供しなければならない。
2. The system SHALL conform to function TI.1.1 (Entity 2240
Authentication).
システムは、機能 TI.1.1（エンティティ認証）に適合しなければならない。
3. The system SHALL conform to function TI.1.2 (Entity
Authorization).
システムは、機能 TI.1.2（エンティティ認可）に適合しなければならない。
4. The system SHALL conform to function TI.1.3 (Entity AccessControl).
システムは、機能 TI.1.3（エンティティアクセス制御）に適合しなければならない。
5. The system SHALL conform to function TI.1.5 (NonRepudiation).
システムは、機能 TI.1.5（否認防止）に適合しなければならない。
6. The system SHALL conform to function TI.1.6 (Secure Data
Exchange).
システムは、機能 TI.1.6（セキュアデータ交換）に適合しなければならない。
7. The system SHALL conform to function TI.2 (Audit).
システムは、機能 TI.2（監査）に適合しなければならない。
8. The system SHALL provide the ability to maintain varying
levels of confidentiality according to patient preferences, userrole, scope of practice, organizational policy, and/or
jurisdictional law.

2241

2242

2243

2244

2245
2246

Section/id#：
Type:
Name:

Conformance Criteria

Row#

システムは、患者の嗜好、ユーザの役割、業務の範囲、組織の方針、および/または管轄法に従って、さまざまなレベルの機密性を維持する機能を提供しなければならない。
9. The system SHALL provide the ability to mask parts of theelectronic health record (e.g., medications, conditions,sensitive documents) from disclosure according to patient
preferences, user role, scope of practice, organizational policy,
and/or jurisdictional law.

2247

システムは、患者の嗜好、ユーザの役割、業務の範囲、組織の方針、および/または管轄法に従って、電子カルテの一部（例：
医薬品、状態、機密文書）を開示から隠す機能を提供しなければならない。
10. The system SHALL provide the ability to unmask (override a 2248
mask) in emergency or other specific situations in accordancewith users' role, and according to scope of practice,organizational policy, and/or jurisdictional law.
システムは、緊急事態またはその他の特定の状況において、ユーザの役割に従って、また実務の範囲、組織の方針、および/または管轄法に従って、マスクを解除する（マスクを上書きする）
機能を提供しなければならない。
11. IF the system allowed a user to unmask (override a mask) in 2250
emergency or other specific situations, THEN the system
SHALL provide the ability to collect the reason for theoverride.
システムが緊急事態または他の特定の状況でユーザがマスク解除（マスクを上書き）することを許可した場合、システムは上書きの理由を収集する機能を提供しなければならない。
12. The system SHALL provide the ability to manage patientconsents to, or restrictions against, any access to data.

2251

システムは、データへのアクセスに対する患者の同意または制限を管理する機能を提供しなければならない。
13. The system SHALL provide the ability to manage a privacy
policy according to patient preferences, user role, scope ofpractice, organizational policy, and/or jurisdictional law.

2252

システムは、患者の嗜好、ユーザの役割、業務の範囲、組織の方針、および/または管轄法に従ってプライバシー方針を管理する機能を提供しなければならない。
14. The system SHALL provide the ability to control access by
specified user(s) to a particular patient health record either
by inclusion or exclusion according to patient preferences,user role, scope of practice, organizational policy, and/or
jurisdictional law.

2253

システムは、患者の嗜好、ユーザの役割、業務の範囲、組織の方針、および/または管轄法に従った包含または除外のいずれかによって、特定のユーザによる特定の患者健康記録へのアクセスを制御する機能を提供しなければならない。
TI.1.8.1
Function
RedactPatient
Identifying Information

2254

Section/id#：
Type:
Name:

Conformance Criteria

Row#

Statement: Maintain patient identities and conditions invisible to the public and other providers
who do not have “need to know” on public tracking screens.
機能概要：公衆追跡画面で「知る必要」を持たない公衆および他の医療提供者には患者の身元および状態を見えないように維持する。
Description: A number of systems implement large tracking screens, common displays or
dashboards to support workflows. In these applications, there is a need to create de-identified
views for broadcast in common areas.
機能説明：多くのシステムは、ワークフローをサポートするために大きな追跡画面、一般的なディスプレイ、またはダッシュボードを実装しています。 これらの用途では、共通領域で放送するための無名化されたビューを作成する必要がある。
1. The system SHALL provide the ability to manage redaction 2255
of patient identities on publicly viewable status boards
according to organizational policy, and/or jurisdictional law.
システムは、組織の方針および/または管轄法に従って、公的に閲覧可能なステータスボード上で患者の身元の修正を管理する機能を提供しなければならない。
TI.1.8.2
FunctionProtect
Patient

2256
IndividualStatement: Flag patient identity as confidential to others.
機能概要：患者の身元を他人に機密としてフラグを立てる。
Description: Create a flag to indicate to all providers caring for the patient, as well as
administrative staff who may receive phone calls from family members or others, the need toprotect the identity of patients at risk of harm, or requesting similar anonymity. Despite best
efforts of confidentiality, display should identify patients at particular risk of harm during stay(e.g., domestic violence).
機能説明：患者の世話をしているすべての医療提供者、家族や他の人から電話を受ける可能性のある管理職員、危害の危険にさらされている患者の身元を保護する必要性、または同様の匿名性の要求を示すフラグを作成する。 機密保持のための最善の努力にもかかわらず、ディスプレイは、滞在中に特定の危害の危険性がある患者を特定してしまう（例えば、家庭内暴力）。
1. The system SHALL provide the ability to maintain the 2257
designation of patients who require protection of theiridentity from others, including family, visitors, and non
participating healthcare providers according to scope ofpractice, organizational policy, and/or jurisdictional law.
本システムは、実務の範囲、組織の方針、および/または管轄法に従って、家族、訪問者、および参加していない医療提供者を含む他者からの身元の保護を必要とする患者の指定を維持す
る機能を提供しなければならない。
TI.1.9Function
SystemOperation
Measurements

2258

Statement: Manage the change of status of an external facility.
Description: A health care delivery relies on services provided by other external facilities such aslaboratories or Long Term Care facilities. The status of those facilities is subject to change forexample: power outage, flooding or overcapacity. Therefore, the EHR system needs to capture theSection/id#：
Type:
Conformance Criteria
Row#
Name:
status of the external facilities, notify appropriate individuals / organizations or even change theworkflow based on established business rules. Change of the status of an external facility ispatient safety concern because a provider may need to adjust patient care or care workflows
accordingly. For example, changes of status of external facility include: laboratory no longer
accredited, laboratory power outage, Long Term Care facility at overcapacity. If laboratory loses
accreditation an administrator needs to be notified to adjust the workflow. If status change isanticipated on regular basis, the system may automatically trigger workflow adjustment
according to established business rule that take in consideration the status of the external facility.
The example for later, the local Long Term Care facility may routinely exceed the capacity on theweekends; therefore, the business rule will accommodate for automatic workflow adjustments.
TI.1.102260
Function
Service Availability
Statement: Manage the ability to access, render and determine information related to Service
Level Agreement.
Description: A provider may need to be aware of certain Service Level Agreement information inorder to mitigate patient safety-related risks that depend on system availability or system
performance.
TI.1.112263
Function
TrustedInformation
Exchange EnvironmentStatement: Maintain a Trusted Information Exchange environment to enable common security
measures among participants in the health information exchange.
Description: A Trusted Information Exchange environment facilitates protected healthinformation exchange by employing common user authentication across multiple systems, and/ororganizations. A Trusted Information Exchange environment can help decrease risk and liability
for participating members of the Trusted Information Exchange environment by ensuring that
protected health information is consistently managed by all participants.
TI.2
2265
Function
Audit
Statement: Audit Key Record, Security, System and Clinical Events
機能概要：監査キーレコード、セキュリティ、システムおよび臨床イベント
Description: EHR Systems have built in audit triggers to capture key events in real-time,
including events related to record management, security, system operations or performance or
clinical situations. Event details, including key metadata (who, what, when, where), are captured
in an Audit Log. Audit Review functions allow various methods of critical event notification as
well as routine log review. Audit functions implement requirements according to scope of practice,organizational policy, and jurisdictional law.
機能説明：EHR システムは、記録管理、セキュリティ、システム運用またはパフォーマンスまたは臨
床状況に関連するイベントを含む、重要なイベントをリアルタイムで捉えるための監査トリガを内蔵しています。 重要なメタデータ（誰、何、いつ、どこ）を含むイベントの詳細は、監査ログに記録される。 監査レビュー機能を使用すると、日常的なログレビューだけでなく、さまざまな方法で重要なイベントを通知できます。 監査機能は、実務の範囲、組織の方針、および管轄法に従って要件を実装する。
1. The system SHALL conform to function TI.1.3 (Entity Access 2266
Control) to limit access to, or modification of, audit record
information to appropriate entities according to scope ofpractice, organizational policy, and/or jurisdictional law.

Section/id#：
Type:
Name:

Conformance Criteria

Row#

システムは、業務の範囲、組織の方針、および/または管轄法に従って監査記録情報へのアクセスまたは監査記録情報の変更を制限するために、機能 TI.1.3（エンティティアクセス制御）に適合しなければならない。
2. The system SHALL conform to function TI.1.3 (Entity Access 2267
Control) to limit access to audit record information for
purposes of deletion according to scope of practice,organizational policy, and/or jurisdictional law (e.g., limit
access to only allow a specific system administrator to delete
audit record information).
システムは、業務の範囲、組織の方針、および/または管轄法に従って削除を目的とした監査記録情報へのアクセスを制限する機能 TI.1.3（エンティティアクセス制御）に適合しなければならない（たとえば、特定のシステム管理者だけが監査記録情報を削除できるようにアクセスを制限する）。
TI.2.1
Function
Audit Triggers

2268

Statement: Manage Audit Triggers
機能概要：監査トリガのマネジメント
Description: EHR Systems have built in audit triggers to capture key events in real-time. Audit
triggers signal key:- Record management and lifecycle events;- Security events related to systemand data safeguards, both routine and exceptional;- System events related to performance andoperations, both routine and exceptional.- Clinical events with special log requirements.
機能説明：EHR システムは、重要なイベントをリアルタイムで捉えるための監査トリガを内蔵している。 監査記録は、重要なシグナルとなります： - 記録管理とライフサイクルイベント - 日常業務と例外の両方のシステムとデータの保護に関連するセキュリティイベント - 日常業務と例外の両方のパフォーマンスと運用に関連するシステムイベント。
1. The system SHALL audit key events, as specified in function 2269
TI.2.1 (Audit Triggers) and child functions, according to scopeof practice, organizational policy, and/or jurisdictional law.
システムは、業務の範囲、組織の方針、および/または管轄法に従って、機能 TI.2.1（監査トリガ）とその子機能に指定されているとおりに、重要な事象を監査しなければならない。
2. The system SHALL capture key Audit Metadata at each
Audit Trigger, as specified in TI.2.1 (Audit Triggers) and childfunctions, according to scope of practice, organizational policy,
and/or jurisdictional law.

2270

システムは、実務の範囲、組織の方針、および/または管轄法に従って、TI.2.1（Audit Triggers）および子機能に指定されているとおりに、各 Audit Trigger で重要な Audit Metadata を記録しなければならない。
3. The system SHALL capture an Audit Log Entry at each Audit 2271
Trigger as specified in TI.2.1 (Audit Triggers) according toscope of practice, organizational policy, and/or jurisdictionallaw.
システムは、実務の範囲、組織の方針、および/または管轄法に従って、TI.2.1（Audit Triggers）に規定されているように、各Audit Trigger で監査ログエントリを記録しなければならない。
4. The system SHALL capture the current master clock time to 2272

Section/id#：
Type:
Name:

Conformance CriteriaRow#establish valid record date and time metadata.
システムは、有効な記録日時メタデータを確立するために現在のマスタークロック時刻を記録しなければならない。
TI.2.1.1
Function
Record Entry
Triggers

2274
Audit

Statement: Manage Record Entry Audit Triggers
機能概要：レコード入力監査トリガマネジメント
Description: Record Entries are managed throughout their lifespan at various points in theirlifecycle. Record Entry Audit Triggers are designed to capture Record Entry related events
including key metadata (who, what, when, where, why). See Function RI.1, Record Lifecycle.
機能説明：レコードエントリは、ライフサイクルのさまざまな時点で、その存続期間を通して管理される。 レコード入力監査トリガは、主要なメタデータ（誰、何、いつ、どこで、なぜ）を含むレコー
ド入力関連のイベントを記録するように設計されている。 機能 RI.1、ライフサイクルの記録を参照すること。
1. The system SHALL conform to Function RI.1 (Record 2275
Lifecycle) and its RI.1.x.1 Subsections to capture andmaintain Record Entry Audit Metadata.
システムは、レコード入力監査メタデータを取得し維持するた
めに、機能 RI.1（レコードライフサイクル）およびその RI.1.x.1
サブセクションに適合しなければならない。
2. The system SHALL link an Audit Log Entry to each Record
Entry according to scope of practice, organizational policy,
and/or jurisdictional law.
システムは、業務の範囲、組織の方針、および/または管轄法に従って、監査記録項目を各記録項目にリンクさせなければならない。
3. The system SHALL harmonize Audit Log Entry Metadata
and corresponding Record Entry Metadata to ensure theyremain identical.

2276

2277

システムは、監査ログエントリメタデータと対応するレコード
エントリメタデータを調和させて、それらが同一であることを確実にしなければならない。
TI.2.1.2
Function
Security Audit Triggers

2278

Statement: Manage Security Audit Triggers
機能概要：セキュリティ監査トリガマネジメント
Description: Security Audit Triggers are designed to capture security related events, both routine
and exceptional, including key metadata (who, what, when, where, why).
機能説明：セキュリティ監査トリガは、主要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、日常的で例外的なセキュリティ関連のイベントを記録するように設計されている。
1. The system SHALL provide the ability to enter the reason 2279
that access control functions are being overridden.
システムは、アクセス制御機能が無効にされている理由を入力

Section/id#：
Type:
Name:

Conformance Criteria

Row#する機能を提供しなければならない。
2. The system SHALL audit key events according to scope ofpractice, organizational policy, and/or jurisdictional law.

2280

システムは、業務の範囲、組織の方針、および/または管轄法に従って重要な出来事を監査しなければならない。
3. The system SHALL capture key Audit Metadata at each
Audit Trigger according to scope of practice, organizational
policy, and/or jurisdictional law.

2281

システムは、業務の範囲、組織の方針、および/または管轄法に従って、各監査トリガで主要な監査メタデータを記録しなければならない。
4. The system SHALL capture an Audit Log Entry at each Audit
Trigger according to scope of practice, organizational policy,
and/or jurisdictional law.
システムは、実務の範囲、組織の方針、および/または管轄法に従って、各監査トリガで監査ログエントリを記録しなければならない）。
5. The system SHALL provide the ability to record system
maintenance events for entry to and exit from the EHR
system.

2282

2283

システムは、EHR システムに出入りするためのシステムメン
テナンスイベントを記録する機能を提供しなければならない。
TI.2.1.2.1
Function
Security Event Security
Audit Trigger

2285

Statement: Manage Audit Trigger initiated to track Security event.
機能概要：セキュリティイベントを追跡するために開始された監査トリガのマネジメント
Description: Capture security events, both routine and exceptional, including key metadata (who,what, when, where, why).
機能説明：主要なメタデータ（誰、何、いつ、どこ、なぜ）を含む、日常的なものと例外的なものの両方のセキュリティイベントを記録する。
1. The system SHALL audit each occurrence when security 2286
events are detected according to scope of practice,organizational policy, and/or jurisdictional law.
システムは、業務の範囲、組織の方針、および/または管轄法に従ってセキュリティイベントが検出された場合に、各発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
2287
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of theuser.
既知の場合、システムはユーザの身元を記録しなければならない。
4. The system SHALL capture identity of the system.
システムはシステムの識別情報を記録しなければならない。

2288

2289

Section/id#：
Type:
Name:

Conformance CriteriaRow#

5. The system SHALL capture the event initiating audit trigger.

2290

システムはイベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2291

2292

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.2.2
Function
User Authentication to
the System (Start user
session) Security Audit
Trigger

2294

Statement: Manage Audit Trigger initiated to track user authentication to the system (start user
session).
機能概要：システムに対するユーザ認証を追跡するために開始された監査トリガー（ユーザセッショ
ンの開始）のマネジメント。
Description: Capture user authentication to the system (start user session), both routine andexceptional, including key metadata (who, what, when, where, why).
機能説明：システムへのユーザ認証（ユーザセッションの開始）を記録する。これには、キーメタデータ（だれ、何、いつ、どこ、何故）が含まれる。
1. The system SHALL audit each occurrence of user 2295
authentication at logon (start session).

2.
3.

4.
5.

システムは、ログオン時（セッション開始時）にユーザ認証の発生を監査しなければならない。
The system SHALL capture identity of the organization.
2296
システムは組織の身元を記録しなければならない。
IF known, THEN the system SHALL capture identity of theuser.
既知の場合、システムはユーザの識別情報を記録しなければならない。
The system SHALL capture identity of the system.
システムはシステムの識別情報を記録しなければならない。
The system SHALL capture the event initiating audit
trigger.

システムはイベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければ
ならない。

2297

2298
2299

2300

Section/id#：
Type:
Name:

Conformance Criteria

Row#

7.

2301

8.

The system SHALL capture identity of the location (i.e.,
network address).

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
The system SHALL capture the method of user 2302
authentication (e.g., user ID, password, biometrics, token,
security question(s)).
システムは、ユーザ認証の方法（例えば、ユーザ ID、パスワー
ド、バイオメトリクス、トークン、セキュリティ上の質問）を記録しなければならない。

TI.2.1.2.3
Function
User
Authentication(SystemPromptfor
Password
Change)Security Audit Trigger

2303

Statement: Manage Audit Trigger initiated to track user authentication (system prompt for
password change).
機能概要：ユーザ認証を追跡するために開始された監査トリガ（パスワード変更のためのシステムプロンプト）のマネジメント。
Description: Capture user authentication (system prompt for password change), both routine andexceptional, including key metadata (who, what, when, where, why).
機能説明：キーメタデータ（誰、何、いつ、どこ、なぜ）を含む、日常的で例外的なユーザ認証（パスワード変更のためのシステムプロンプト）を記録する。
1. The system SHALL audit each occurrence of user 2304
authentication when user is prompted to change password.

2.
3.

4.
5.

システムは、ユーザがパスワードを変更するように促されたときに、ユーザ認証の発生を監査しなければならない。
The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
IF known, THEN the system SHALL capture identity of theuser.
既知の場合、システムはユーザの識別情報を記録しなければならない。
The system SHALL capture the identity of the system.
システムはシステムの識別情報を記録しなければならない。
The system SHALL capture the event initiating audit
trigger.

システムはイベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.

7.

システムは、イベント開始監査トリガの日時を記録しなければならない。
The system SHALL capture identity of the location (i.e.,
network address).

2305
2306

2307
2308

2309

2310

Section/id#：
Type:
Name:

Conformance Criteria

8.

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
IF password change successful, THEN the system SHALL
capture the new password.

Row#

2311

パスワードの変更に成功したら、システムは新しいパスワードを記録しなければならない。
TI.2.1.2.4
Function
User Request to Change
Password Security Audit
Trigger

2312

Statement: Manage Audit Trigger initiated to track user request to change password.
機能概要：ユーザのパスワード変更要求を追跡するために開始された監査トリガのマネジメント。
Description: Capture user request to change password, both routine and exceptional, including
key metadata (who, what, when, where, why).
機能説明：重要なメタデータ（誰、何、いつ、どこで、なぜ）を含め、日常的でも例外的でも、パスワードを変更するためのユーザ要求を記録します。
1. The system SHALL audit each occurrence of user 2313
authentication when user requests password change.

2.
3.

4.
5.

システムは、ユーザがパスワード変更を要求したときに、ユー
ザ認証の発生を監査しなければならない。
The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
IF known, THEN the system SHALL capture identity of theuser.
既知の場合、システムはユーザの識別情報を記録しなければならない。
The system SHALL capture identity of the system.
システムはシステムの識別情報を記録しなければならない。
The system SHALL capture the event initiating audit
trigger.

システムはイベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.

7.

8.

システムは、イベント開始監査トリガの日時を記録しなければならない。
The system SHALL capture identity of the location (i.e.,
network address).

2314
2315

2316
2317

2318

2319

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
IF password change successful, THEN the system SHALL 2321
capture the new password.
パスワードの変更に成功したら、システムは新しいパスワード

Section/id#：
Type:
Name:

Conformance Criteria

Row#

を記録しなければならない。
TI.2.1.2.5
Function
User Log Out (End user
session) Security Audit
Trigger

2322

Statement: Manage Audit Trigger initiated to track user log out (end user session).
機能概要：ユーザのログアウトを追跡するために開始された監査トリガー（エンドユーザセッション）のマネジメント。
Description: Capture user log out (end user session), both routine and exceptional, including key
metadata (who, what, when, where, why).
機能説明：主要なメタデータ（誰、何、いつ、どこ、なぜ）を含む、日常的で例外的なユーザログア
ウト（エンドユーザセッション）を記録します。
1. The system SHALL audit each occurrence of user logout (end 2323
session).
システムは、各ユーザログアウトの発生（セッション終了）を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2324
2325

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2326

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2327

システムはイベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2328

2329

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.2.6
Function
User Access (Successful)
Security Audit Trigger

2331

Statement: Manage Audit Trigger initiated to track user access (successful).
機能概要：ユーザクセスを追跡するために開始された監査トリガー（成功）のマネジメント。
Description: Capture user access (successful), both routine and exceptional, including key
metadata (who, what, when, where, why).

Section/id#：
Type:
Name:

Conformance Criteria

Row#

機能説明：主要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、日常的で例外的なユーザクセス（成功）を記録します。
1. The system SHALL audit each occurrence when user access 2332
is successful.
システムは、ユーザクセスが成功したときには、その発生を監査する必要があります。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2333
2334

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2335

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2336

システムはイベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2337

2338

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.2.7
Function
User Attempts to Access
Data (Unsuccessful –Access Denied) Security
Audit Trigger

2339

Statement: Manage Audit Trigger initiated to track user attempts to access data (unsuccessful –access denied).
機能概要：ユーザがデータにアクセスしようとした試みを追跡するために開始された監査トリガ（失敗 - アクセス拒否）のマネジメント。
Description: Capture user attempts to access data (unsuccessful – access denied), both routine andexceptional, including key metadata (who, what, when, where, why).
機能説明：キャプチャ・ユーザが、キー・メタデータ（誰、何、いつ、どこ、なぜ）を含む、日常的でも例外的でもあるデータへのアクセス試行（失敗 - アクセス拒否）。
1. The system SHALL audit each occurrence when user access 2340
is unsuccessful (denied).
システムは、ユーザクセスが失敗した（拒否された）ときには、その発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
2341

Section/id#：
Type:
Name:

Conformance Criteria

Row#

システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2342

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2343

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2344

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2345

2346

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.2.8
Function
Extraordinary
User
Access (Break the Glass)
Security Audit Trigger

2347

Statement: Manage Audit Trigger initiated to track extraordinary user access (break the glass).
機能概要：非常時のユーザクセスを追跡するために開始された監査トリガ（ブレイクグラス）のマネ
ジメント。
Description: Capture extraordinary user access (break the glass), both routine and exceptional,
including key metadata (who, what, when, where, why).
機能説明：重要なメタデータ（誰、何、いつ、どこ、何故）を含む、日常的および例外的な非常時のユーザクセス（ブレイクグラス）を記録する。
1. The system SHALL audit each occurrence when 2348
extraordinary access is successful (e.g., "break the glass"scenario).
システムは、非常時のアクセスが成功した場合（たとえば、「ブ
レイクグラス」シナリオ）に、発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
2349
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2350

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2351

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2352

Section/id#：
Type:
Name:

Conformance Criteria
システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

Row#

2353

2354

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
8. The system SHALL capture the rationale for extraordinary 2355
user access.
システムは、異常なユーザクセスの理論的根拠を記録しなければならない。
TI.2.1.2.9
Function
User
Permissions(Authorization) Security
Audit Trigger

2356

Statement: Manage Audit Trigger initiated to track user permissions (authorization).
機能概要：ユーザ許可を追跡するために開始された監査トリガ（認証）のマネジメント。
Description: Capture user permissions (authorization), both routine and exceptional, including
key metadata (who, what, when, where, why).
機能説明：主要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、日常的および例外的なユーザ権限（認証）を取得する。
1. The system SHALL audit each occurrence when user 2357
permissions (authorizations) are granted, removed or
updated.
システムは、ユーザの許可（認証）が付与、削除、または更新されたときに、発生するたびに監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2358
2359

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2360

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2361

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければ
ならない。

2362

Section/id#：
Type:
Name:

Conformance CriteriaRow#

7. The system SHALL capture identity of the location (i.e.,
network address).

2363

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
9. The system SHALL capture identity of user to whom 2365
permissions apply.
システムはパーミッションが適用されるユーザの身元を記録しなければならない。
10. The system SHALL capture the new set of applicable user
permissions (authorizations).

2366

システムは適用可能なユーザ許可（認証）の新しいセットを記録しなければならない。
TI.2.1.3
Function
System Audit Triggers

2367Statement: Manage System Audit Triggers
機能概要：システム監査トリガのマネジメント
Description: System Audit Triggers are designed to capture system related events, both routine
and exceptional, including key metadata (who, what, when, where, why).
機能説明：システム監査トリガは、主要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、日常的および例外的なシステム関連のイベントを記録するように設計されている。
5. The system SHALL provide audit capabilities for recording 2372
access and usage of systems, data, and organizational
resources.
システムは、システム、データ、および組織のリソースへのア
クセスと使用状況を記録するための監査機能を提供しなければならない。
6. The system SHALL provide audit capabilities to capturesystem events at the hardware and software architecturelevel.
システムはハードウェアおよびソフトウェアアーキテクチャ
レベルでシステムイベントを捉えるための監査機能を提供しなければならない。
7. The system SHALL provide the ability to record system
maintenance events for entry to and exit from the EHR
system.
システムは、EHR システムに出入りするためのシステムメン
テナンスイベントを記録する機能を提供しなければならない。
8. The system SHALL provide the ability to record system
maintenance events for remote access connections including
those for system support and maintenance activities forsecurity and access purposes.

2373

2374

2375

システムは、システムサポートおよびセキュリティおよびアクセス目的のメンテナンス活動のためのイベントを含むリモート
アクセス接続のためのシステムメンテナンスイベントを記録する機能を提供しなければならない。
TI.2.1.3.1

2376

Section/id#：
Type:
Name:
Function
System Event System
Audit Trigger

Conformance Criteria

Row#

Statement: Manage Audit Trigger initiated to track system events.
機能概要：システムイベントを追跡するために開始された監査トリガのマネジメント。
Description: Capture system events, both routine and exceptional, including key metadata (who,what, when, where, why).
機能説明：重要なメタデータ（誰、何、いつ、どこ、なぜ）を含む、日常的および例外的なシステム
イベントを記録する。
1. The system SHALL audit each occurrence when system 2377
events are detected according to scope of practice,organizational policy, and/or jurisdictional law.
システムは、業務の範囲、組織の方針、および/または管轄法に従ってシステムイベントが検出された場合に、各発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2378
2379

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2380

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2381

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2382

2383

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.3.2
Function
System Started System
Audit Trigger

2385

Statement: Manage Audit Trigger initiated to track system started event.
機能概要：システム開始イベントを追跡するために開始された監査トリガーのマネジメント。
Description: Capture system started event, both routine and exceptional, including key metadata(who, what, when, where, why).
機能説明：キャプチャー・システムは、重要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、
日常的および例外的なイベントを開始した。

Section/id#：
Type:
Name:

Conformance Criteria

Row#

1. The system SHALL audit each occurrence when systemstarted.

2386

システムは、システム起動時に各発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2387
2388

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2389

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2390

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2391

2392

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.3.3
Function
Back Up Started System
Audit Trigger

2393

Statement: Manage Audit Trigger initiated to track back-up started event.
機能概要：バックアップ開始イベントを追跡するために開始された監査トリガーのマネジメント。
Description: Capture back-up started event, both routine and exceptional, including key metadata(who, what, when, where, why).
機能説明：重要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、定期的および例外的なバックアップ開始イベントを記録する。
1. The system SHALL audit each occurrence when database 2394
backup is initiated.
1.システムは、データベースのバックアップが開始されたときに、発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of theuser.
既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2395
2396

2397

Section/id#：
Type:
Name:

Conformance Criteria

Row#

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2398

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2399

2400

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.3.4
Function
Back Up Completed
System Audit Trigger

2401

Statement: Manage Audit Trigger initiated to track back-up completed event.
機能概要：バックアップ完了イベントを追跡するために開始された監査トリガーのマネジメント。
Description: Capture back-up completed event, both routine and exceptional, including key
metadata (who, what, when, where, why).
機能説明：重要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、定期的および例外的なバックアップ完了イベントを記録する。
1. The system SHALL audit each occurrence when database 2402
backup is completed.
システムは、データベースのバックアップが完了したときに発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2403
2404

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2405

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2406

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2407

2408

Section/id#：
Type:
Name:

Conformance Criteria

Row#

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
8. The system SHALL capture backup success or failure.
2409
システムはバックアップの成功または失敗を記録しなければならない。
TI.2.1.3.5
Function
Back
Up
RecoveryStarted System Audit
Trigger

2410

Statement: Manage Audit Trigger initiated to track back-up recovery started event.
機能概要：バックアップの回復開始イベントを追跡するために開始された監査トリガーのマネジメン
ト。
Description: Capture back-up recovery started event, both routine and exceptional, including key
metadata (who, what, when, where, why).
機能説明：キーとなるメタデータ（誰、何、いつ、どこで、なぜ）を含む、日常的および例外的なバックアップリカバリ開始イベントを記録する。
1. The system SHALL audit each occurrence when database 2411
recovery is initiated.
システムは、データベースの回復が開始されたときに、各発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2412
2413

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2414

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2415

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2416

2417

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.3.6
Function
Back
Up
RecoveryCompleted System Audit
Trigger2418

Section/id#：
Type:
Name:

Conformance Criteria

Row#

Statement: Manage Audit Trigger initiated to track back-up recovery completed event.
機能概要：バックアップ回復の完了イベントを追跡するために開始された監査トリガーのマネジメン
ト。
Description: Capture back-up recovery completed event, both routine and exceptional, including
key metadata (who, what, when, where, why).
機能説明：主要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、日常的および例外的なバックアップ回復完了イベントを記録する。
1. The system SHALL audit each occurrence when database 2419
recovery is completed.
システムは、データベースの回復が完了したときに、発生するたびに監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2420
2421

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2422

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2423

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2424

2425

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
8. The system SHALL capture backup recovery success or 2426
failure.
システムはバックアップリカバリの成功または失敗を記録しなければならない。
TI.2.1.3.7
Function
Batch
Job
Started
System Audit Trigger

2427

Statement: Manage Audit Trigger initiated to track batch job started event.
機能概要：バッチジョブ開始イベントを追跡するために開始された監査トリガーのマネジメント。
Description: Capture system batch job started event, both routine and exceptional, including key
metadata (who, what, when, where, why).
機能説明：主要なメタデータ（誰、何、いつ、どこ、なぜ）を含む、日常的及び例外的なシステムバ

Section/id#：
Type:
Conformance CriteriaName:
ッチジョブの開始イベントの取得。
。
1. The system SHALL audit each occurrence when a batch job
is initiated.
システムは、バッチジョブが開始されたときに発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

Row#

2428

2429
2430

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2431

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2432

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2433

2434

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.3.8
Function
Batch Job Completed
System Audit Trigger

2435

Statement: Manage Audit Trigger initiated to track batch job completed event.
機能概要：バッチジョブ完了イベントを追跡するために開始された監査トリガーのマネジメント。
Description: Capture batch job completed event, both routine and exceptional, including key
metadata (who, what, when, where, why).
機能説明：主要なメタデータ（誰、何、いつ、どこ、なぜ）を含む、日常的および例外的なバッチ・
ジョブ完了イベントを記録する。
1. The system SHALL audit each occurrence when a batch job 2436
is completed.
システムは、バッチジョブが完了したときに発生を監査しなけ
ればならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of theuser.
既知の場合、システムはユーザの識別情報を記録しなければな
らない。

2437
2438

Section/id#：
Type:
Name:

Conformance CriteriaRow#

4. The system SHALL capture identity of the system.

2439

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2440

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2441

2442

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.3.9
Function
MaintenanceStarted
System Audit Trigger

2443

Statement: Manage Audit Trigger initiated to track maintenance started event.
機能概要：保守開始イベントを追跡するために開始された監査トリガーのマネジメント。
Description: Capture maintenance started event, both routine and exceptional, including key
metadata (who, what, when, where, why).
機能説明：主要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、日常的および例外的なメンテ
ナンス開始イベントを記録する。
1. The system SHALL audit each occurrence when maintenance 2444
is initiated, including down time.
システムは、メンテナンスが開始されたときに、停止時間を含む各発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2445
2446

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2447

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2448

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2449

2450

Section/id#：
Type:
Name:

Conformance Criteria

Row#

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.3.10
Function
Maintenance Completed
System Audit Trigger

2451

Statement: Manage Audit Trigger initiated to track maintenance completed event.
機能概要：保守完了イベントを追跡するために開始された監査トリガーのマネジメント。
Description: Capture maintenance completed event, both routine and exceptional, including key
metadata (who, what, when, where, why).
機能説明：主要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、日常的および例外的なメンテ
ナンス完了イベントを記録する。
1. The system SHALL audit each occurrence when maintenance 2452
is completed, including restart from down time.
システムは、ダウンタイムからの再起動を含め、メンテナンスが完了したときに各発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2453
2454

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2455

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2456

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2457

2458

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.3.11
Function
Resource Usage System
Audit Trigger

2459

Statement: Manage Audit Trigger initiated to track resource usage event.
機能概要：リソース使用状況イベントを追跡するために開始された監査トリガーのマネジメント。
Description: Capture resource usage event, both routine and exceptional, including key metadata(who, what, when, where, why).

Section/id#：
Type:
Name:

Conformance Criteria

Row#

機能説明：主要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、日常的および例外的なリソース使用状況イベントを記録します。
1. The system SHALL audit usage of system resources (access, 2460
computational, storage, network) according to scope ofpractice, organizational policy, and/or jurisdictional law.
システムは、業務の範囲、組織の方針、および/または管轄法に従って、システムリソース（アクセス、計算、ストレージ、ネットワーク）の使用状況を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2461
2462

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2463

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2464

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2465

2466

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.3.12
Function
SystemMaintenance
Events -Local Access
System Audit Trigger

2467

Statement: Manage Audit Trigger initiated to track system maintenance events -local access.
機能概要：システムメンテナンスイベントを追跡するために開始された監査トリガ- ローカルアクセ
スのマネジメント。
Description: Capture system maintenance events -local access, both routine and exceptional,
including key metadata (who, what, when, where, why).
機能説明：重要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、システムメンテナンスイベン
トの定期的および例外的なローカルアクセスを記録する。
1. The system SHALL audit each occurrence of a system 2468
maintenance event with local access.
システムは、ローカルアクセスでシステムメンテナンスイベン
トの発生を監査しなければならない。
2. The system SHALL capture identity of the organization.

2469

Section/id#：
Type:
Name:

Conformance Criteria

Row#

システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2470

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2471

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2472

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2473

2474

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.3.13
Function
SystemMaintenance
Events - Remote Access
System Audit Trigger

2475

Statement: Manage Audit Trigger initiated to track system maintenance events -remote access.
機能概要：システムメンテナンスイベントを追跡するために開始された監査トリガ
セスのマネジメント。

- リモートアク

Description: Capture system maintenance events -remote access, both routine and exceptional,
including key metadata (who, what, when, where, why).
機能説明：主要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、日常的および例外的なシステ
ムメンテナンスイベント-リモートアクセスを記録する。
1. The system SHALL audit each occurrence of a system 2476
maintenance event with remote access.
システムは、リモートアクセスでシステムメンテナンスイベン
トの発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2477
2478

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2479

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2480

システムは、イベント開始監査トリガを記録しなければならな

Section/id#：
Type:
Name:

Conformance Criteria

Row#

い。
6. The system SHALL capture the date and time of the event
initiating audit trigger.

2481

システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2482

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.3.14
Function
System Maintenance EHRorClinicalSoftware System Audit
Trigger

2483

Statement: Manage Audit Trigger initiated to track system maintenance - EHR or clinicalsoftware.
機能概要：システムメンテナンスを追跡するために開始された監査トリガ - EHR または臨床ソフト
ウェアのマネジメント
Description: Capture system maintenance - EHR or clinical software, both routine andexceptional, including key metadata (who, what, when, where, why).
機能説明：主要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、日常的および例外的な-EHR ま
たは臨床用ソフトウェアシステムのメンテナンス を記録する。
1. The system SHALL audit each occurrence of a system 2484
maintenance event when EHR or clinical software is
updated or re-configured.
システムは、EHR または臨床用ソフトウェアが更新または再設定されたときに、システムメンテナンスイベントが発生する
たびに監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of
the user.
既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.
システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit
trigger.
システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,

2485
2486

2487
2488

2489

2490

Section/id#：
Type:
Name:

Conformance Criteria

Row#

network address).
システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.3.15
Function
System Maintenance Codes,
Vocabulary,
Knowledge,
Rules
System Audit Trigger

2491

Statement: Manage Audit Trigger initiated to track system maintenance of codes, vocabulary,knowledge and rules.
機能概要：コード、語彙、知識および規則のシステム保守を追跡するために開始された監査トリガのマネジメント。
Description: Capture system maintenance of codes, vocabulary, knowledge and rules - both routine
and exceptional, including key metadata (who, what, when, where, why).
機能説明：主要なメタデータ（誰、何、いつ、どこで、なぜ）を含め、日常的および例外的なコード、
語彙、知識、およびルールのシステムメンテナンスを記録する。
1. The system SHALL audit each occurrence of a system 2492
maintenance event when codes, classification schemes,
knowledge bases, clinical or business practice rules are
updated or re-configured.
システムは、コード、分類体系、知識ベース、臨床または業務慣行の規則が更新または再設定されたときに、システム保守イ
ベントの発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
2493
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2494

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2495

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2496

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2497

2498

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.3.16
Function
Data Corruption System

2499

Section/id#：
Type:
Name:
Audit Trigger

Conformance Criteria

Row#

Statement: Manage Audit Trigger initiated to track data corruption events.
機能概要：データ破損イベントを追跡するために開始された監査トリガのマネジメント。
Description: Capture data corruption event, including key metadata (who, what, when, where,
why).
機能説明：主要なメタデータ（誰、何、いつ、どこで、なぜ）を含むデータ破損イベントを記録する。
1. The system SHALL audit each occurrence or detection of data 2500
corruption.
システムは、データ破損の発生または検出を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2501
2502

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2503

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2504

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2505

2506

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.4
Function
Clinical Audit Triggers

2507

Statement: Manage Clinical Audit Triggers
機能概要：臨床監査のトリガのマネジメント
Description: Clinical Audit Triggers are designed to capture certain clinical events, both routine
and exceptional, including key metadata (who, what, when, where, why).
機能説明：臨床監査トリガは、重要なメタデータ（誰、何、いつ、どこ、なぜ）を含む、日常的および例外的な特定の臨床イベントを記録するように設計されています。
1. The system SHALL provide the capability to track all clinical 2508
alerts.
システムは、すべての臨床警報を追跡する機能を提供しなければならない。
2. The system SHALL provide the capability to track all

2509

Section/id#：
Type:
Name:

Conformance CriteriaRow#acknowledgements of clinically significant report changes.
システムは、臨床的に重要な報告書の変更に関するすべての確認を追跡する機能を提供しなければならない。
TI.2.1.4.1
Function
Clinical Alerts ClinicalAudit Trigger

2511

Statement: Manage Audit Trigger initiated to track clinical alerts.
機能概要：臨床アラートを追跡するために開始された監査トリガのマネジメント。
Description: Capture clinical alerts, both routine and exceptional, including key metadata (who,what, when, where, why).
機能説明：重要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、日常的および例外的な警告を記録する。
1. The system SHALL audit each occurrence of a clinical alert 2512
according to scope of practice, organizational policy, and/or
jurisdictional law.
システムは、実践の範囲、組織の方針、および/または管轄法に従って臨床警告の発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2513
2514

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2515

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2516

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2517

2518

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.4.2
Function
AcknowledgementsofClinicallySignificant
Report Changes ClinicalAudit Trigger

2520

Statement: Manage Audit Trigger initiated to track acknowledgement of clinically significant
report changes.

Section/id#：
Type:
Name:

Conformance Criteria

Row#

機能概要：臨床的に重要なレポート変更の確認を追跡するために開始された監査トリガのマネジメン
ト。
Description: Capture acknowledgement of clinically significant report changes, both routine andexceptional, including key metadata (who, what, when, where, why).
機能説明：重要なメタデータ（誰、何、いつ、どこ、なぜ）を含む、日常的および例外的な、臨床的に重要なレポートの変更の確認を記録する。
1. The system SHALL audit each occurrence of an 2521
acknowledgement of clinically significant report changes
according to scope of practice, organizational policy, and/or
jurisdictional law.

2.
3.

4.
5.

6.

7.

システムは、実践の範囲、組織の方針、および/または管轄法に従った臨床的に重要な報告の変更の承認の各発生を監査しなければならない。
The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
IF known, THEN the system SHALL capture identity of theuser.
既知の場合、システムはユーザの識別情報を記録しなければならない。
The system SHALL capture identity of the system.
システムはシステムの識別情報を記録しなければならない。
The system SHALL capture the event initiating audit
trigger.
システムは、イベント開始監査トリガを記録しなければならない。
The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
The system SHALL capture identity of the location (i.e.,
network address).

2522
2523

2524
2525

2526

2527

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
TI.2.1.4.3
Function
DisableDecision
Support Alerts ClinicalAudit Trigger

2529

Statement: Manage Audit Trigger initiated to track disabling of decision support alerts.
機能概要：意思決定支援アラートの無効化を追跡するために開始された監査トリガのマネジメント。
Description: Capture disabling of decision support alerts, both routine and exceptional, including
key metadata (who, what, when, where, why).
機能説明：重要なメタデータ（誰、何、いつ、どこで、なぜ）を含む、日常的および例外的な意思決定支援アラートの無効化を記録する。

Section/id#：
Type:
Name:

Conformance Criteria

Row#

1. The system SHALL audit each occurrence when decision
support alerts are disabled according to scope of practice,organizational policy, and/or jurisdictional law.

2530

実践の範囲、組織の方針、および/または管轄法に従って意思決定支援の警告が無効になっている場合、システムは各発生を監査しなければならない。
2. The system SHALL capture identity of the organization.
システムは組織の身元を記録しなければならない。
3. IF known, THEN the system SHALL capture identity of the
user.

2531
2532

既知の場合、システムはユーザの識別情報を記録しなければならない。
4. The system SHALL capture identity of the system.

2533

システムはシステムの識別情報を記録しなければならない。
5. The system SHALL capture the event initiating audit trigger.

2534

システムは、イベント開始監査トリガを記録しなければならない。
6. The system SHALL capture the date and time of the event
initiating audit trigger.
システムは、イベント開始監査トリガの日時を記録しなければならない。
7. The system SHALL capture identity of the location (i.e.,
network address).

2535

2536

システムは、場所の識別情報（すなわち、ネットワークアドレス）を記録しなければならない。
8. The system SHALL capture the rationale for disabling 2537
clinical alerts.
システムは、臨床警報を無効にするための理論的根拠を記録しなければならない。
TI.2.2Function
Audit Log Management

2538

Statement: Manage Audit Log
機能概要：監査ログのマネジメント
Description: Audit Triggers create Audit Log entries. Audit Log entries are typically managed aspersistent evidence of events occurring over time, including events pertaining to record
management, security, system operations and performance, key clinical situations.Audit log
entries capture event details, including key metadata (who, what, when, where).Audit log
functions fulfill log maintenance and persistence requirements according to scope of practice,organizational policy, and jurisdictional law.
機能説明：監査トリガは監査ログエントリを作成する。 監査ログエントリは通常、レコード管理、セキュリティ、システム運用およびパフォーマンス、主要な臨床状況に関連するイベントなど、時間の経過とともに発生するイベントの永続的な証拠として管理される。 監査ログ機能は、実践の範囲、組織の方針、および管轄法に従って、ログの保守と永続性の要件を満たす。
1. The system SHALL provide the ability to capture audit log 2539
entries using a standards-based audit record format

Section/id#：
Type:
Name:

Conformance CriteriaRow#according to scope of practice, organizational policy, and/or
jurisdictional law (e.g., IETF RFC 3881 "Internet
Engineering Task Force, Request For Comment, Security
Audit and Access Accountability Message XML Data
Definitions for Healthcare Applications").
システムは、実務の範囲、組織の方針、および/または管轄法（例
えば、IETF RFC 3881「インターネット技術特別調査委員会」
コメント要求”セキュリティ監査とアクセスアカウンタビリティメッセージ医療アプリケーションのための XML データ定義”）に従って、標準ベースの監査記録フォーマットを使用して監査ログエントリを取り込む機能を提供しなければならない。
3. The system SHALL provide the ability to log access to audit 2542
log entries, and/or metadata.
システムは、監査ログエントリおよび/またはメタデータへのア
クセスをログに記録する機能を提供しなければならない。
TI.2.2.1
Function
Audit Log Indelibility

2543

Statement: Manage Audit Log Indelibility
機能概要：監査ログの保存性のマネジメント
Description: Audit logs must be maintained in a persistent and indelible form according to scopeof practice, organizational policy, and jurisdictional law.
機能説明：監査ログは、実践の範囲、組織の方針、および管轄法に従って、永続的かつ消えない形式で維持されなければならない。
1. The system SHALL manage each Audit Log entry as a 2544
persistent, indelible (unalterable) data object including all
metadata.
システムは、各監査ログエントリを、すべてのメタデータを含む永続的で消去不可能な（変更不可能な）データオブジェクトとして管理しなければならない。
TI.2.3Function
Audit Notification andReview

2545

Statement: Notify of Audit Events, Review Audit Log
機能概要：監査イベントの通知、監査ログの確認
Description: EHR system functions allow various methods of critical event notification (from audit
triggers) as well as routine log review.Audit log notification and review functions implement
requirements according to scope of practice, organizational policy, and jurisdictional law.
機能説明：EHR システム機能は、日常的なログレビューと同様に（監査トリガからの）重要なイベン
ト通知のさまざまな方法を可能にする。監査ログ通知およびレビュー機能は、業務の範囲、組織の方針、および管轄法に従って要件を実装する。
1. The system SHALL provide the ability to render a report 2546
based on audit log entries.
システムは、監査ログエントリに基づいてレポートを表示する機能を提供しなければならない。
2. The system SHALL provide the capability to generate reports

2547

Section/id#：
Type:
Name:

Conformance Criteria

Row#

based on ranges of system date and time that audit log entries
were captured.
システムは、監査ログエントリが取得されたシステムの日時範
囲に基づいてレポートを生成する機能を提供しなければならない。
4. The system SHALL allow emergency access log entry review
based on criteria such as individual assignment or specifiedrole, reasons, patient information/record entries according toorganizational policy, and/or jurisdictional law.

2549

システムは、個人の割り当てまたは特定の役割、理由、組織の方針に従った患者情報/記録エントリ、および/または管轄法などの基準に基づいて緊急アクセスログエントリのレビューを許可しなければならない。

TI.3
Function
Registry and Directory
Services
レジストリとディレクト
リ・サービス

2550

Statement: Enable the use of registry services and directories to uniquely identify, locate andsupply links for retrieval of information related to:- patients and providers for healthcare
purposes; - payers, health plans, sponsors, and employers for administrative and financial
purposes; - public health agencies for healthcare purposes, and- healthcare resources and devices
for resource management purposes.
機能概要：レジストリサービスとディレクトリを使用して、医療のための患者と医療提供者情報、管理と財務のための支払者、保険計画、保険提供者そして雇用者情報、医療のための衛生行政機関情報、資源管理のための医療資源・医療機器情報へのリンクを特定し、配置し、供給することを可能にする。
Description: Registry and directory service functions are critical to successfully managing thesecurity, interoperability, and the consistency of the health record data across an EHR-S. These
services enable the linking of relevant information across multiple information sources within, or
external to, an EHR-S for use within an application. This applies to directories/registries internal
to the EHR-S as well as directories/registries external to the EHR-S . Transmission may occur
automatically or manually and may include small or large amounts of data. Directories andregistries support communication between EHR Systems and may be organized hierarchically orin a federated fashion. For example, a patient being treated by a primary care physician for achronic condition may become ill while out of town. The new provider’s EHR-S interrogates a local,
regional, or national registry to find the patient’s previous records. From the primary care record,a remote EHR-S retrieves relevant information in conformance with applicable patient privacy
and confidentiality rules.An example of local registry usage is an EHR-S application sending aquery message to the Hospital Information System to retrieve a patient’s demographic data.
機能説明：レジストリとディレクトリ・サービス機能は EHR-S を通して医療記録情報のセキュリテ
ィ、相互運用性、一貫性を正しく管理するために重要である。 これらのサービスは EHR-S 内外の複数の情報源をまたいで適切な情報を関連付けし、アプリケーション内で使用することを可能にする。
これは EHR-S 内のディレクトリ／レジストリだけでなく EHR-S 外のディレクトリ／レジストリにも適用される。データ転送は自動または手動で行われ、微小な情報から膨大な情報まで含むことがある。 ディレクトリとレジストリは EHR システム同士の情報伝達を助け、階層的または連邦的に編成されうる。例えば、プライマリーケアの医師から持病の治療を受けている患者が町の外で発症するかもしれない。新しい医療提供者の EHR-S は患者の過去の記録を探して、ローカルの、地域の、または国のレジストリを検索する。 遠隔の EHR-S は適切な患者のプライバシーと秘密保持規約に従っ

てプライマリーケアの記録から関連する情報を検索する 。ローカルのレジストリの使用法の一例としては、EHR-S アプリケーションが患者の人口統計学的な情報を検索するために病院情報システムにクエリのメッセージを送信することがあげられる。
1．The system SHALL provide the ability to manage internal 2551
registry services and directories.
内部のレジストリサービスやディレクトリを管理する機能を提供すること。
2. The system SHALL provide the ability to exchange information 2552
with external registry services and directories.
外部のレジストリサービスやディレクトリと情報交換可能な機能を提供すること。
3. The system SHALL provide the ability to securely exchange 2553
information with external registry services and directories.
外部のレジストリサービスやディレクトリと安全に情報交換可能な機能を提供すること。
4. The system SHALL conform to function TI.5.1 (Application and 2554
Structured-Document Interchange Standards) to exchange
information with external registry services and directories.
外部のレジストリサービスやディレクトリと情報交換するために TI.5.1 (アプリケーションと構造化文書の交換規格) に準拠
すること。

TI.4
FunctionStandard Terminology
andTerminology
Services 標準用語と用語
サービス

2562

Statement: Support semantic interoperability through the use of standard terminologies,
standard terminology models and standard terminology services.
要求事項：標準用語モデル、および標準用語サービスの使用を通じて関連付けのなされた相互運用性をサポートすること。
Description: The purpose of supporting terminology standards and services is to enable semanticinteroperability.
Interoperability is demonstrated by the consistency of human and machine interpretation ofshared data and reports.
It includes the capture and support of consistent data for templates and decision support
logic.Terminology standards pertain to concepts, representations, synonyms, relationships andcomputable (machine-readable) definitions.
Terminology services provide a common way for managing and retrieving these items, including
historically correct version interpretation.
Terminology services need to support legal requirements for retrospective health record
information and system data.
機能説明：標準用語と用語サービスをサポートする目的は、相互運用性を可能にすることである。
相互運用性は、人の一貫性と共有されたデータと報告書の機械解釈により実証される。
それはキャプチャとテンプレートの一貫しているデータの提供と合理的な用語規約を提供する決定は、概念、表現、同義語、関係、およびコンピュータ利用可能な定義に関連していることを含んでいる。
用語サービスにより歴史的に正しいバージョン解釈を含むこれらのアイテムの管理と取り出しのための共通の方法が提供される。

用語サービスは、過去に遡ってヘルスレコード情報とシステムデータのための法的必要条件を提供する必要がある。
TI.4.1
FunctionStandard Terminology
and Terminology Models
標準用語と用語モデル

2565

Statement: Employ approved standard terminologies to ensure data correctness and to enable
semantic interoperability (both within an enterprise and externally).Support a formal standard
terminology model.
要求事項：データの正確さを保証し、関連付けされた相互運用性を確保するために（内外で）承認された相互運用性を使用すること。フォーマルな標準用語モデルを準備すること。
Description: Semantic interoperability requires standard terminologies combined with a formal
standard information model. An example of an information model is the HL7 Reference
Information Model. Another example is the ISO/EN 13606 Electronic Health Record
Communication.A terminology provides semantic and computable identity to its concepts.
Examples of terminologies that an EHR-S may support include: LOINC, SNOMED, ICD-9, ICD10, and CPT-4.Terminologies are use-case dependent and may or may not be realm dependent.
The key is that the standard be approved by all stakeholders. For example, terminologies for
public health interoperability may differ from those for healthcare quality, administrative
reporting, research, etc.Formal standard terminology models enable common semantic
representations by describing relationships that exist between concepts within a terminology orin different terminologies, such as exemplified in the model descriptions contained in the HL7
Common Terminology Services specification.The clinical use of standard terminologies is greatly
enhanced with the ability to perform hierarchical inference searches across coded concepts.
Hierarchical Inference enables searches to be conducted across sets of coded concepts stored in an
EHR-S. Relationships between concepts in the terminology are used in the search to recognize
child concepts of a common parent. For example, there may be a parent concept, "penicillin
containing preparations" which has numerous child concepts, each of which represents a
preparation containing a specific form of penicillin (Penicillin V, Penicillin G, etc.). Therefore, asearch may be conducted to find all patients taking any form of penicillin preparation.Clinical andother terminologies may be provided through a terminology service internal or external to an
EHR-S.
機能説明：語義の相互運用性は、フォーマルな標準の情報モデルと結合された標準用語を必要とする。
情報モデルの例は HL7 参照情報モデルがある。別の例は、その概念に語義がありコンピュータ可能な
アイデンティティを提供する ISO/EN13606 EHR Communication 規格がある。EHR システムが提供する用語の例は、LOINC、SNOMED、ICD-9、ICD-10、および CPT-4.を含む。用語はユースケースに依存する/依存しないかもしれない。規約がすべてのステークホルダーにより承認されることが鍵となる。例
えば、公衆衛生相互運用性のための用語は、医療品質、管理の報告、研究などから異なる。フォーマ
ルな標準用語モデルは用語の概念に存在する関係を描写することによって、共通の意味のある表現ができる。HL7 共通用語サービス仕様でモデル描写を例示されるように。標準用語の臨床利用はコード化された概念を横切った階層的な検索を実行する能力によって強められている。階層的なインターフ
ェイスは、EHR システムで蓄えられたコード化された概念のセットを横切って検索が実行できることを可能にする。用語の概念の関係性は、共通の親の子供の概念を理解する研究で利用されている。例
えば、親概念、多い子供概念〈ペニシリン〉を持っている（ペニシリン V、ペニシリンなど G）。従って、研究は全ての患者を見つける。臨床と他の用語は、内部か外部かの EHR の用語のサービスを通して与えられる。
2. The system SHALL determine that clinical terms and coded 2564
clinical data exist in an approved standard terminology.
システムは臨床用語およびコード化された臨床データが承認された標準用語に存在するか判定しなければならない。
6. The system SHALL provide the ability to manage terminology 2571
assets and supporting tools (internal or external to the EHRS).
システムは用語アセットとサポートツールを管理する機能を提供しなければならない。（EHR システムの内か外において）。

TI.4.2
Function
MaintenanceandVersioning of Standard
Terminologies
標準用語の保守とバージ
ョン管理

2576

Statement: Enable version control according to scope of practice, organizational policy, and/or
jurisdictional law to ensure maintenance of utilized standard terminologies.This includes theability to accommodate changes to terminology sets as the source terminology undergoes its
natural update process (new codes, retired codes, redirected codes). Such changes need to becascaded to clinical content embedded in templates, custom formularies, etc., as determined byexisting policy.
要求事項：実行の範囲や組織ポリシーおよび／または利用された用語の維持のための管轄区域の法律の範囲に従ってバージョン管理を可能すること。ソース用語がその自然なアップデートプロセスを受ける変化
を用語セットに適応させる能力を含む（新しいコード、不要なコード、リダイレクトしたコード）。そのよ
うな変化は、既存のポリシーのため決定されるようにテンプレート、カスタムの処方一覧などに埋め込まれた臨床の内容に次々に影響を及ぼしていく必要がある。
Description: Version control allows for multiple sets or versions of the same terminology to exist
and be distinctly recognized over time. Standard terminologies are usually periodically updated,and concurrent use of different versions may be required. Ideally, the meaning of a concept neverchanges over time, but a concept can be deprecated, and replaced with a new concept in a newversion. However, in some terminologies, the meaning of a concept can change over time. In any
case, it is important that retrospective analysis and research maintains the ability to relate to theappropriate conceptual meaning. If the terminology encoding for a concept changes over time, it
is also important that for legal health records, as well as for retrospective analysis and research,the different encodings can be correlated to ensure the permanence of the concept as originallycaptured. This does not necessarily imply that complete older versions of the terminology be kept
in the EHR-S, only access to the changes needs to be maintained.
機能説明：バージョン管理は、同じ用語のバージョンまたは複数のセットを考慮する。標準用語は、
通常周期的にアップデートされて、種々のバージョンの同時利用が必要であるかもしれない。理想的に、概念の意味は決して時間を変更しないけれども、概念は廃止されて、新しいバージョンの新しい概念と取り替えられる。しかしながら、いくつかの用語において、概念の意味は時間が経つにつれて変化する。ともかく、回顧分析と研究は、適切な概念の意味と関連する能力を維持することは重要となる。もし概念のためにエンコードしている用語が時間とともに切り換わるならば、また、回顧分析と研究だけでなく合理的なヘルスレコード～？重要である。これは、必ずしも、用語のより古いバー
ジョンが EHR システムに保持されるのを暗示していない。変化へのアクセスだけが維持される必要がある。
1. The system SHALL provide the ability to manage data using 2577
different versions of standard terminologies.
システムは、標準用語の種々のバージョンを使ってデータを管理する機能を提供しなければならない。
2. The system SHALL provide the ability to update standard 2578
terminologies.
システムは、標準用語をアップデートする機能を提供しなければならない。
5. The system SHALL provide the ability to update terminologies 2581
to a deprecated status.
システムは、廃止状態に用語をアップデートする機能を提供しなけ
ればならない。
6. The system SHALL provide the ability to update individual 2582
codes within a terminology to a deprecated status.
システムは、廃止状態に用語内の個々のコードをアップデートする機能を提供しなければならない。
7. The system SHALL provide the ability to update terms with 2583
their equivalent when terminology is changed, where codedterminology content is embedded in clinical models (e.g.,
templates and custom formularies), when the terminology
changes can be accomplished unambiguously, and if
consistent with scope of practice, organizational policy, and/or
jurisdictional law.
システムは、用語が変わる時アップデートする機能を提供しなければならない。コード化された用語の内容が臨床モデルにはめ込む。
（例えば、テンプレートおよびカスタムの処方一覧）に埋め込まれた用語の変化が明らかに遂行できる時に、およびもし実行の範囲や組織ポリシーおよび／または管轄区域の法律の範囲と一致しているならば用語が変更される時
8. The system SHALL provide the ability to update standard
terminologies used to enter clinical content (via templates,
custom formularies, etc.)
システムは、臨床内容を入力するために用いられた標準用語をアップデートする機能を提供しなければならない。
（テンプレートやカスタムの処方一覧などから ）9. The system SHALL maintain an audit log or a change historyof code system to the individual code level, for versions used,
dates implemented and updated to enable correctinterpretation of historical data over time.
システムは、監査ログや個々のコードレベルの変更履歴の維持しなければならない。
TI.4.3Function
Terminology Mapping
用語マッピング

2584

2585

2586

Statement: Map or translate one terminology to another as needed by local, regional, national, orinternational interoperability requirements.
要求事項：ローカルや地域、全国、国際的な相互運用性要件に必要となるような別のものへ用語をマッピ
ングもしくは翻訳が求められている。

Description: The ability to map or translate one terminology to another is fundamental to anorganization in an environment where several terminologies are in play to meet different
purposes. It is a common occurrence that data is captured using one terminology, but is sharedusing another terminology. Example: Within a healthcare organization there may be a need tomap terminology concepts with the same semantic meaning to meet different purposes (e.g.,
between an EHRS and an external laboratory system, or between an EHRS and a billing system).
Standard terminologies are evolving and maps will need to be adjusted to support this evolution
and more sophisticated use of standard terminologies and maps over time. Realm specific(including local, regional, national or international) interoperability requirements can also
determine the need for terminology mapping, and in many cases terminology mapping services(internal or external) can be used to satisfy these requirements. The interaction and mapping ofterminologies may be called into question in a legal proceeding, when clinical decisions were
documented or when semantic meaning could be misinterpreted.
It is important to seek guidance, document and retain all mapping decisions for all types ofterminology mapping, and to recognize when mapping may not be possible from one concept toanother.
The quality of mapping is dependent upon the skills and interpretation of standard terminologies
and clinical information by mapping experts.
機能説明：用語をマッピング、もしくは翻訳する能力がいくつかの用語が異なる目的で作用している環境の中で組織に必要な基礎となる。用語を利用することで得られるデータ、または別の用語では共有されるデータは共通の存在となる。例：医療機関内では、異なる目的のための同じ意味論的な意味を持った用語概念にマッピングされる必要があるかもしれない（例えば EHR システムおよび外部の研究所システム、または EHR システムと請求システムの間で）。徐々に発展している標準用語やマップ

は、時が経つにつれて、この発展や標準用語をより洗練された使用を提供するために調整される必要がある。具体的（ローカル、地域、全国または国際を含む）相互運用性要件は、用語がマッピングされる必要性を決定づける。および多くのケースの用語のマッピングサービスはそれらの要件を満たす。
（内部であるか、または外部である）臨床決定を説明する時や意味論的な意味が誤った解釈をする
時に、相互作用と用語のマッピングは合理的な手続きを問われる。ガイダンスやドキュメントを探す
こと、用語マッピングのすべてのタイプのためのすべてのマッピングの作成決定を記憶すること、および認めていることが重要である。 マッピングの品質は、標準用語のスキルと解釈および臨床の情報に依存する。
1. The system SHALL provide the ability to manage data using 2587
terminology maps which may be provided by terminology
mapping services (internal or external).
システムは、用語マップを使ってデータを管理する機能を提供しなければならない。
TI.5
2592
HeaderStandards-Based
Interoperability
標準ベースの相互運用性
Statement: Provide automated health care delivery processes and seamless exchange of clinical,
administrative, and financial information through standards-based solutions.
要求事項：自動化された医療提供プロセスおよびシームレスな臨床(情報)の交換、それと標準ベースのソリューションを通して得られた財務情報を提供すること。
Description: Interoperability standards enable certain applications to be shared among EHR
systems, resulting in a unified (logical) view of a given EHR system where several disparate
systems may actually be participating transparently. Interoperability standards also enablecertain information to be shared among EHR systems (including information that resides inregional, national, or international information exchanges). Interoperability standards also
promote timely and efficient information capture, use, and re-use, often reducing the cumulative
workload of the broad set of stakeholders.When health-related information is exchanged -- or when
external applications are used to extend an EHR system -- the interoperability methods andunderlying standards that were used in the process may need to be disclosed during a legal
proceeding (especially when the resulting information becomes part of the patient's medical
record).
機能説明：相互運用性規約は、EHR システム間で共有するアプリケーションでできる。実際いくつかの異種のシステムが透過的に参加しているかもしれない与えられた EHR システムの統合された（論理的な）ビューが得られる。相互運用性規約は、一定の情報が EHR システムに分けられることを可能にする（地域、全国、または国際的な情報交換にある情報を含む）。相互運用性規約は、時に促進させ、効率的な情報キャプチャ、使用、および再生使用も促進し、しばしば、ステークホルダーの広いセットの累積している仕事量を減らしている。健康関連情報は交換される－－または、外部のアプリケー
ションが使われる時 EHR システムを拡張するために－－プロセスにおいて使われた相互運用性方法および潜在的な規約は、法律の手続きの間に明らかにされる必要があるかもしれない（特に、結果として生じている情報が患者のカルテの一部になる時）。
TI.5.1
2593
Header
Application, StructuredMessage,
andStructured-Document
Interchange Standards
アプリケーション,構造化
メッセージ、構造化文書交
換標準
Statement: Support an EHR system's ability to operate seamlessly with systems that adhere torecognized application interchange standards. These systems include other EHR systems,
subcomponents of an EHR system, or other (authorized, non-EHR) systems.
要求事項：アプリケーション交換規約基づいたシームレスに動作する EHR システムを提供すること。
これらのシステムは、他の EHR システムまたは他の EHR システムのサブコンポーネントを含む。

Description: Since a health care organization typically has various external and internalinteroperability requirements, it must use a set of corresponding interoperability or interchange
standards that will meet its connectivity and information structure, format, and semantic
requirements. Information should be exchanged -- and applications should provide functionality - in a manner that appears to be seamless to the user. To be specific, if data is received from anexternal source that requires a user to manually copy-and-paste that data into multiple parts ofthe system, the exchange is not considered to be "seamless".
機能説明：一般に、医療機関が、様々な外部の、および内部の相互運用性要件があるので、それが、その接続性と情報構造、フォーマット、意味的な要件 と対応した相互運用性または交換規約のセットを使わなければならない。情報はユーザのためにシームレスであるような方法で交換される。－－および、アプ
リケーションは機能を提供するべきである－－。はっきり言えば、もしユーザが必要とする外のソースからコピー＆ペーストの手動でデータを受けるならば、システムの複数の部分にそのデータは「シームレス」
ように考慮されない。
Examples of standards-based EHR information content and exchange methods include:
standards-based data extracts, standards-based messages, standards-based documents (e.g., HL7
Clinical Document Architecture (CDA) documents), standards-based healthcare transactions, andstandards-based images (e.g., Digital Imaging and Communication in Medicine (DICOM)
documents).Support for multiple interaction modes is needed to respond to differing levels of
immediacy and types of exchange. For example, messaging is effective for many near-real time,
asynchronous data exchange scenarios but may not be appropriate if the end-user is requesting
an immediate response from a remote application.A variety of interaction modes are typicallysupported such as:
標準ベースの EHR 情報コンテンツと交換方法の例は次を含む：標準ベースのデータ抜粋、標準ベースのメッセージ、標準ベースの文書（例えば、HL7 診療文書アーキテクチャ（CDA）文書）、標準ベースの医療ト
ランザクション、および標準ベースのイメージ（例えば、医学（DICOM）文書のデジタル画像処理および通信）。複数のインタラクションモードの提供は、即時性の異なるレベルおよび交換のタイプに反応するために必要である。例えば、メッセージは、多くのリアルタイム、非同期のデータ交換シナリオのために効果的であるけれども、もしエンドユーザがリモートのアプリケーションから即時反応を要求しているなら
ば、適切ではないであろう。各種のインタラクションモードは一般に、以下など提供される：- Unsolicited Notifications (e.g., Adam Everyman has arrived at the clinic for his scheduled
appointment);- Query/Response (e.g., Query: Is Adam Everyman known to the system? Response: Yes, Adam's
medical record number is 12345678);- Service Request and Response (e.g., Request: Laboratory Order for “Fasting Blood Sugar”.
Response: the results of the test);- Information Interchange between organizations (e.g., in a regional health exchange or in anational health system);- Structured/discrete clinical documents (e.g., a structured clinical note);- Unstructured clinical document (e.g., dictated surgical note).
- 要求していないのに届いた通知書（例えば、アダムは予約した時間にクリニックに到着した）；- 質問／反応（例えば：システムに知らせると：はい、アダムのカルテは 12345678 と応答する）；- サービス要求および反応（例えば：検査オーダの結果「血糖を抑える 」：テストの結果を得る）；- 組織間の情報交換（例えば、地域の健康交換または全国的な健康システムにおいて）；- 構造化された／離散的な診療文書（例えば、構造化された臨床ノート）；- 不統一の診療文書（例えば、口述された外科ノート）。

Standard terminology is a fundamental part of interoperability and is described in section TI.4.
Using a formal explicit information model further optimizes interoperability.
An example of an information model is the HL7 Reference Information Model (RIM).
Organizations typically need to deal with more than one information model and may need todevelop a mapping between information models, a metamodel (that helps to explain and organize
the various information models), or both.
標準用語は相互運用性の根本的な部分であり、セクション TI.4 で説明されている。フォーマルな明
示的な情報モデルを使うことにより相互運用性はさらに最適化される。情報モデルの例は HL7 参照情報モデル（RIM）である。組織は一般に、複数の情報モデルを扱う必要があり、情報モデル、メタモデ
ル（それは、様々な情報モデルを説明し、組織するのに役立っている）、または両方のマッピングを発展させる必要があるかもしれない。
TI.5.1.1
2594
Function
Application InterchangeStandards
アプリケーション交換規
約Statement: Support the ability to operate seamlessly with other systems by using applications,
and/or structured messages and documents that adhere to interchange standards.
要求事項：交換規約に基づいた構造化されたメッセージや文書を使ったアプリケーションに使われることによって他のシステムとシームレスに動作するEHRシステムを提供すること。
Description: Placeholder - Not Defined at this time.
機能説明：プレースホールダーとは-定義されていないもの
1. The system SHALL provide the ability to receive andtransmit information using interchange standards as
required by realm / local -specific profiles, and/or byrecognized jurisdictional authorities.
システムは、領域/地域固有のプロファイル、および/または認められた監督官庁によって要求されている交換規約を利用して情報を送受信する機能を提供しなければならない。
2. The system SHALL provide the ability to seamlessly perform
interchange operations with other systems that adhere tointerchange standards as required by realm / local -specific,
and/or by recognized jurisdictional authorities.
このシステムは、領域/地域固有のもの、および/または認められた監督官庁の要求に応じて、交換規約に準拠している他のシステムとの交換をシームレスに実行する機能を提供しなければならない。
3. The system SHALL conform to TI.4 (Standard Terminology
and Terminology Services) including all child-functions, tosupport terminology standards according to scope of practice,organizational policy, and/or jurisdictional law.
システムは、実行の範囲や組織ポリシーおよび／または管轄区域の法律の範囲に従って標準用語をサポートするためにすべての子機能を含んでいる TI.4（標準用語と用語サービス）に適合しなければならない。
6. The system SHALL provide the ability to receive and transmit
data using standard, coded terminology.
システムは、コード化された用語の規約を利用したデータを送受信する機能を提供しなければならない。
11. The system SHALL store a log record of each data exchange(transaction) when transmitting information with external
systems.

2595

2596

2597

2600

2605

システムは、他のシステムから伝えられた情報について各々のデー
タ交換ログを蓄積する機能を提供しなければならない。
TI.5.1.2
Function
Structured-Document
Interchange Standards
構造化文書交換標準2606

Statement: Support the management of structured documents.
要求事項：構造化された文書の管理を提供すること。
Description: Structured documents are an important method of facilitating the exchange of
information to support care. Documents are often considered to be more permanent in nature;messages are often considered to be more transitory in nature.
機能説明：構造化された文書は、情報交換を容易にする重要な方法である。文書はしばしば永久的であると考えられる；メッセージはしばしば一時的なものと考えられる。
1. The system SHALL provide the ability to receive, maintain 2607
and transmit structured documents
システムは、構造化された文書を送受信し維持する機能を提供しなければならない。
TI.5.1.3
Function
Structured-Message
Interchange Standards
構造化メッセージ交換規
約Statement: Support the management of structured messages.
要求事項：構造化されたメッセージの管理を提供すること。
Description: Structured messages are an important method of facilitating the exchange of
information to support care. Messages are often considered to be more transitory in nature;
documents are often considered to be more permanent in nature.
機能説明：構造化されたメッセージは、情報交換を促進する重要な方法である。メッセージは、しば
しば一時的なものと考えられる；文書はしばしば永久的であると考えられる。
1. The system SHALL provide the ability to manage structured 0
messages according to scope of practice, organizational policy,
and/or jurisdictional law.
システムは、実践の範囲や組織ポリシーおよび/または管轄区域の法に従って構造化メッセージを管理する機能を提供しなければならない。
TI.5.22608
FunctionInterchange Standards
Versioning
and
Maintenance
交換規約のバージョン管理と維持Statement: Support various versions of an interchange standard.
要求事項：交換規約の様々なバージョンを提供すること。
Description: Interchange standards characteristically change throughout their lifecycles; thosechanges are often tagged with "version" numbers. EHR systems need to control the various
versions of interchange standards that are used within an EHR implementation and accommodatechanges that arise with each version. For example, if an organization migrates to version 2.5 of
HL7's messaging standard, it may choose to utilize that version's specimen or blood bankinformation capabilities. The organization may also find that certain fields have been retained forbackwards compatibility only or withdrawn altogether. The EHR-S needs to be able to handle all

of these possibilities. Standards typically evolve in such a way as to protect backwards
compatibility.
On the other hand, sometimes there is little, or no, backwards compatibility when an organization
may need to replace an entire standard with a new methodology. An example of this is migratingfrom HL7 v2 to HL7 v3.Interchange standards that are backward compatible support exchange
among senders and receivers who are using different versions. Version control ensures that thosesending information in a later version of a standard consider the difference in information content
that can be interchanged effectively with receivers, who are capable of processing only earlier
versions. That is, senders need to be aware of the information that receivers are unable to capture
and adjust their business processes accordingly
Version control enables multiple versions of the same interchange standard to exist and be
distinctly recognized over time. Since interchange standards are usually periodically updated,concurrent use of different versions may be required. Large (and/or federated) organizations
typically need to use different versions of an interchange standard to meet internal organizational
interoperability requirements. For example, the enterprise-wide standard might use HL7 v2.5 forlaboratory messages, but some regions of the enterprise might be at a lower level.
It should be possible to retire deprecated interchange standards versions when applicablebusiness cycles are completed while maintaining obsolete versions.
An example use of this is for possible claims adjustment throughout the claim’s life cycle.
When interchange standards change over time, it is important that retrospective analysis andresearch correlate and note gaps between the different versions’ information structures to support
the permanence of concepts over time.
機能説明：交換規約はそれらのライフサイクルを通して特徴的に変化する；それらの変化はしばしば「バージョン」番号がつけられる。EHR システムは、各々のバージョンで生じる EHR の実装や提供の変化がある交換規約の様々なバージョンで制御される必要がある。例えば、ある組織が HL7 メッセージ規約のVer2.5 へ移行するならば、バージョンの実例や血液バンク情報機能を利用することを選択するだろう。組織はバックヤードの共存を支えるある一定のフィールドに気付くだろう。EHR システムはそれらの可能性の全てを扱うことが必要である。規約は典型的に、バッグヤードにある共存を守るための方法で徐々に発展させる。
一方で、組織が新しい方法論で完全な規約に移行する必要がある場合、時々バッグヤードの共存がない。
これの例として、HL7Ver.2 から HL7Ver.3 への移行がある。バッグヤードの共存がある交換規約は、異なるバージョン間で利用される送信側と受信側へ交換を提供する。バージョン管理は、規約の後のバージョ
ンの送信情報が受信側で効率的に交換された情報コンテンツの違いを考慮することを保証する。すなわ
ち、送信側が、受信側が捕らえて、それに応じてそれらのビジネス・プロセスを調整することができない
情報に気づく必要がある。
バージョン管理は、同じ交換標準の複数のバージョンが存在し、はっきりと認められていることを可能にする。交換規約は通常、周期的にアップデートされるため、異なるバージョンが同時に利用されることが必要となる。大きな組織では、一般的に、内部組織的相互運用性の交換規約の異なるバージョンの利用が必要である。例えば、大事業の規約は検査メッセージでは HL7Ver2.5 を利用するだろう。しかし、大事業のいくつかの領域では低いレベルのメッセージ規約を利用するかもしれない。時代遅れのバージョンを維持する間、適用可能な景気変動が完成される時には、交換標準バージョンを廃止することは可能なはずである。この例の用途は、請求のライフサイクルを通してずっと、調整を要求する。交換規約が変わる時、
永続的な概念を提供する異なるバージョンの情報構造の間にある回顧分析と相関する研究とギャップが重要である。
1. The system SHALL provide the ability to use different 2609
versions of interchange standards.
システムは、異なるバージョンの交換規約を利用する機能を提供しなければならない。
2. The system SHALL provide the ability to change 2610
(reconfigure) the way that data is transmitted as aninterchange standard evolves over time and in accordancewith business needs.
システムは、ビジネスのニーズによって方法を変化（再設定）する機能を提供しなければならない。
TI.5.3FunctionStandards-Based
Application Integration
標準ベースのアプリケー
ション統合

2613

Statement: Integrate applications in a standards-based manner.
要求事項：アプリケーションを標準ベースの方法で統合すること。
Description: An EHR-S often consists of multiple applications. Some of those applications may be
within the EHR-S; others may be external to the EHR-S. The user of the EHR-S often benefits
when those applications are integrated. Application integration can be accomplished in an ad-hoc
fashion or in a standards- based fashion. The method(s) by which applications may be integrated
within an organization depends on that organization’s approach to application integration.
A given organization could conceivably employ multiple application integration approaches tomeet various application integration requirements.
機能説明：EHR システムはしばしば複数のアプリケーションから構成される。それらのアプリケーションのうちのいくつかが EHR システム内にあるかもしれない； または、EHR システムの外部にあるかもしれな
い。それらのアプリケーションが統合されていると、EHR システムのユーザはしばしば利益を得られる。
アプリケーション統合は特別の方式で遂行できるか、または、標準-に基づいた方式で遂行できる。組織内
でアプリケーションが統合された方法はアプリケーション統合の組織のアプローチに依存する。
与えられた組織は、多分、様々なアプリケーション統合要件を満たすように、複数のアプリケーション統合アプローチを使用できた。
1. The system SHALL provide the ability to integrate
applications in a standards-based fashion when the system iscomposed of, and/or is extended by disparate applications.
システムは、異種のアプリケーションにより拡張される時においても標準に基づいたアプリケーションを統合する機能を提供しなければならない。
TI.5.4
FunctionInterchange Agreements
データ交換の合意

2614

2616

Statement: Support the use of Interchange Agreements to specify the rules, responsibilities,
expectations, and methods by which Interchange Agreement partners may exchange information.
要求事項：パートナーが情報を交換できるルールや責任、見込みを示す交換合意の使用を提供すること。
Description: Systems that wish to communicate with each other must agree on certain
parameters/criteria that will govern an information exchange process. Interchange agreements
enable partnering systems to discover, negotiate, and utilize those parameters/criteria. An EHRS can use this information to define how data will be exchanged between the sending and thereceiving partners. Interchange services and capabilities can be discovered in an automatedfashion. Entity directories can be used to determine the address, profile, and data exchange
requirements of known, and/or potential Interchange Agreement partners.
Entity registries can be used to determine the security, addressing, and reliability requirements
between potential Interchange Agreement partnering systems.
機能説明：お互いにコミュニケーションを行うシステムは、情報交換プロセスで管理するためのあるパラメタやクライテリアに合意しなければいけない。交換合意は、それらのパラメタやクライテリア
を発見、協議、処理することを可能にする。EHR システムは送受信のパートナーシステムとの間で交換する定義された情報を利用することができる。交換サービスと機能は、自動化された方法で見いだされる。エンティティディレクトリは、既知のおよび／または潜在的な交換協定パートナーのアドレ
ス、プロフィール、およびデータ交換要件を決定するために使われる。エンティティレジストリは、
潜在的な交換協定と組むシステムの間のセキュリティ、アドレス、および信頼性要件を決定するために使用できる。
1. The system SHALL exchange information with Interchange 2617
Agreement partners based on interoperability agreement
descriptions.
システムは、相互運用性協定の説明に基づいた交換合意パートナー
間で情報を交換する機能を提供しなければならない。
TI.5.52622
Function
System Integration
システム統合Statement: Support the integration of the EHR system with related systems.
要求事項：関連したシステムとのEHRシステムの統合を提供すること。
Description: Within a given organization (for example, an institution, facility , or integrated caredelivery network), an EHR system may be directly integrated with other systems (for example, alaboratory Information System, Radiology System, Pharmacy System, or Hospital Information
System). Conversely, an EHR system may access these other systems indirectly by integratingwith a system that serves as the central routing mechanism for the organization. For example,
the EHR system may be integrated with the Hospital Information System which then routes the
EHR system's orders to a laboratory , pharmacy, or radiology service. Depending on the type of
information that is exchanged within an integrated-system environment, certain heuristics may
be needed that will help govern the information exchange process.
機能説明：与えられた組織（例えば、組織、機能、または統合されたケア伝達ネットワーク）内では、EHR システムが他のシステムと直接統合できる（例えば、検査システム、放射線医学システム、調剤システム、または病院情報システム）。逆に言えば、EHR システムは、組織の中心的なメカニズムに統合することによって、これらの他のシステムに間接的にアクセスできる。例えば、EHR システムは、
EHR システムのオーダを、検査、調剤、または放射線医学サービスに伝達する病院情報システムと統合できる。統合システム環境内で交換される情報のタイプに依存し、情報交換プロセスを制御するのに役立てるために一定の発見的学習が必要であるかもしれない。
1. The system SHALL provide the ability to integrate the EHR 2623
system with other systems (e.g., a laboratory Information
System, Radiology System, Pharmacy System, or Hospital
Information System) according to scope of practice,organizational policy, and/or jurisdictional law.
システムは、実行の範囲や組織ポリシーまたは管轄区域の法の範囲に従って、他のシステムと EHR システムを統合する機能を提供しなければならない。（例えば、検査システム、放射線情報シス
テム、調剤システム、または病院情報システム）

7. Trust Infrastructure Section
TI.6
Function
Business
Rules Management
ビジネスルールの管理

2627

Statement: Manage the ability to create, update, delete, view, and version business rules including
institutional preferences. Apply business rules from necessary points within an EHR-S to control
system behavior. An EHR-S audits changes made to business rules, as well as compliance to andoverrides of applied business rules.
Description: EHR-S business rule implementation functions include decision support, diagnostic
support, workflow control, and access privileges, as well as system and user defaults andpreferences. An EHR-S supports the ability of providers and institutions to customize decision
support components such as triggers, rules, or algorithms, as well as the wording of alerts andadvice to meet realm specific requirements and preferences.
機能概要：作成、アップデート、削除、閲覧、制度選択も含めたビジネスルールの版を管理する能力を有する。システムの動作を制御し、EHR システムの必要な点を使用することで、ビジネスルールに沿うことができる。EHR システムは、ビジネスルールの変更、法令変更、適用されたルールの逸脱を監査すること。
機能説明：EHR システムのビジネスルール実装機能とは、意思決定支援、診断支援、ワークフローコ
ントロール、アクセス権限を含む。同様に、システムの初期設定、ユーザの初期設定、選択肢も含む。
EHR システムは、トリガー、ルール、もしくは、アルゴリズムのような意思決定のコンポーネントと同様に、警告文言、特定領域に関する助言などにも医療提供者に適応できるように、制度やシステム機能を支援する。
1. The system SHALL provide the ability to manage business 2628
rules.
1. 当該システムはビジネスルールを管理する機能を当然に有しなければならない。
10. The system SHALL provide the ability to determine system 2637
behavior based upon defined business rules.
10. 当該システムは、予め定義されたビジネスルール基づいたシス
テムの動きを決める機能を当然に有しなければならない。
TI.7
Function
機能
Workflow Management
ワークフロー管理

2638

Statement: Support workflow management functions including both the management and set up
of work queues, personnel lists, and system interfaces as well as the implementation functions
that use workflow-related business rules to direct the flow of work assignments.
Description: Workflow management functions that an EHR-S supports include:-Distribution of
information to and from internal and external parties;-Support for task-management as well as
parallel and serial task distribution;-Support for notification and task routing based on system
triggers; and-Support for task assignments, escalations and redirection in accordance withbusiness rules. Workflow definitions and management may be implemented by a designatedapplication or distributed across an EHR-S.
機能概要：ワークフローマネジメント機能をサポートする。ワークフローマネジメント機能とは、各業務の配列管理、人員リスト、システム・インターフェイス、実施機能（ワークフロー関連の作業割当を決める際に使用する機能）を含む。

機能説明：EHR-S がサポートするワークフローマネジメント機能とは以下を含む。内外の部門の情報の配信機能。パラレル及びシリアルタスク分散などのタスクマネジメントのサポート機能。運用に基づく通知及び所定業務のアラート支援機能。仕事の割り当て、エスカレーション、運用に関連する変更を支援する機能。ワークフロー定義および管理は、指定されたアプリケーションまたは EHR-S
を通して配信され、実施されることが考えられる。
1. The system SHALL provide the ability to manage workflow 2639
business rules including work queues, personnel lists, andsystem interfaces.
1. システムは、ワーク配列、職員リスト、およびシステム・インターフェイスを含むワークフローの運用ルールを管理する機能を提供しなければならない。
TI.8
2653
Function
Database Backup andRecovery
データベースのバックア
プとリカバリーStatement: Provide for the ability to backup and recover the EHR system.
Description: To enable the preservation of the EHR database and it's data, functionality needs tobe present to record a copy of the database and it's contents to offline media as well as the recoveryof the system from a backup copy and resumption of normal system operation. The backup must
preserve both data as well as database structure and definition information sufficient to recovera complete functional EHR system. Database components may include, but not be limited toapplication data, security credentials, log/audit files, and programs; ultimately all EHR
components necessary to provide a full and complete operating environment. Finally, the backup
must be capable of being used during recovery processing to restore an exact copy of the EHR
system as of a particular instant in time. This is a requirement to be able to preserve logicalconsistency of information within the recovered EHR system. In providing for this capability thesystem may Include multiple backup, and/or redundancy solutions such as fail-over architecture,
database journaling, transaction processing, etc.The backup and recovery function must address
both physical system failure (i.e. failure of EHR system hardware) as well as logical system failure(e.g., database corruption).To support the requirement that the EHR system be available
whenever it is needed within the design parameters of the system and provide reliability andredundancy of the EHR database and it's data, the backup function shall not impact userfunctionality or appreciably impact user performance.The backup function may include features
which permit multiple processes and technologies to perform it's task. This may include multiple
backup technologies such as tape, disk, cloud, etc. Also, multiple architectures such as redundancy,
online, near-line and off-line media.

機能概要：EHR システムのバックアップまたはリカバリー機能の提供
機能説明：EHR データベースまたは、そのデータそのものの保存が可能なこと。機能的に、データベ
ースのコピー記録、オフラインメディアの記録、通常のシステム操作の消去記録、バックアップコピ
ーからの回復記録も含むこと。バックアップは、データおよびデータベース構造、または、機能的に十分な EHR システムの定義情報の両方を保存すること。データベースのコンポーネントは、アプリ
ケーションデータ、セキュリティ資格、ログ・監査ファイル、プログラムだけに限らない。最終的には、すべての EHR コンポーネントが、すべて、完ぺきに操作できる環境が提供される必要がある。
最終的にバックアップ時間は最短で行われ、ＥＨＲシステムの正確なコピーを復元しなければならない。また、バックアップは、リカバリー処理中にも使用されることが可能でなければならない。リカ
バリーされたＥＨＲシステム内で情報は論理的な整合性を保つことができるようにすることが求められている。この機能を提供するには、システムが複数のバックアップができ、および/またはフェイ
ルオーバー構造、データベースログ、トランザクション処理、などの冗長ソリューションバックアップを含むことが望ましい。バックアップとリカバリー機能は、物理的なシステム障害（ＥＨＲシステ
ムのハードウェア故障）だけでなく、論理的なシステム障害（例えば、データベースの破損）の両方に対応しなければならない。システム設計パラメーターの範囲内で必要とされる時はいつでもＥＨＲシステムが利用可能であり、ＥＨＲデータベースやデータの信頼性と冗長性を提供しなければならない。バックアップ機能は、ユーザの機能に影響を与えたり、ユーザの実業務中で感じるほどであってはならない。バックアップ機能は、複数処理、技術など、そのタスクを実行するために必要な特殊な技術を含めてもよい。これは、テープ、ディスク、クラウドのような複数のバックアップ技術を含む。
また、冗長性、オンライン、ニアラインおよびオフラインメディアなども、複数のアーキテクチャとして含んでもよい。
1. The system SHALL provide the ability to backup and recover 2654
EHR information according to scope of practice,organizational policy, and/or jurisdictional law.
1. システムは、診療範囲、組織ポリシーおよび/または管轄区域の法律に応じた EHR 情報のバックアップおよびリカバリー機能を提供しなければならない。
2. The system SHALL provide the ability to backup and recover 2655
all database contents including programs and all software
components necessary to permit a complete EHR to be
recovered. (i.e., 'full' backup and recovery)
2. システムは、バックップやデータベースの内容をすべてリカバリーする機能を提供しなければならない。その内容には、プログラ
ム、完全にリカバリーしたと認められる EHR のために必要なソ
フトウェアのコンポーネントを含む。
（すなわち、「フル」バックアップと「フルリカバリー」）
5. IF the EHR user requirements specify that the EHR system be 2658
available continuously, THEN the system SHALL provide theability to backup EHR information concurrently with thenormal operation of the EHR application.
5. EHR のユーザ要件で、特に EHR システムを継続的に利用することを指定した場合、システムは、EHR のアプリケーションの正常な動作の提供と同時にバックアップ機能を提供しなければ
ならない。

TI.9
Function
SystemManagement
Operations
andPerformance
システム管理のオペレー
ションとパフォーマンス

2662

Statement: Manage the change of status of an external facility and the ability to access, renderand determine information related to Service Level Agreement.
機能概要：外部施設の状態の変化とアクセス性能の管理すること。サービスレベルアグリーメントに関する情報の提示し決定すること。
Description: A health care delivery relies on services provided by other external facilities such aslaboratories or Long Term Care facilities. The status of those facilities is subject to change forexample: power outage, flooding or overcapacity. Therefore, the EHR system needs to capture thestatus of the external facilities, notify appropriate individuals / organizations or even change theworkflow based on established business rules. Change of the status of an external facility ispatient safety concern because a provider may need to adjust patient care or care workflows
accordingly. For example, changes of status of external facility include: laboratory no longer
accredited, laboratory power outage, Long Term Care facility at overcapacity. If laboratory loses
accreditation an administrator needs to be notified to adjust the workflow. If status change isanticipated on regular basis, the system may automatically trigger workflow adjustment
according to established business rules that take into consideration the status of the external
facility. The example for later, the local Long Term Care facility may routinely exceed the capacity
on the weekends; therefore, the business rule will accommodate for automatic workflow
adjustments. A provider may need to be aware of certain Service Level Agreement information inorder to mitigate patient safety-related risks that depend on system availability or system
performance.

機能説明：ヘルスケアの提供は、検査室や長期ケア施設等の他の外部の施設によって提供されるサービスに依存している。それらの施設のステータスは、例えば、停電、洪水、容量超過といった変化が対象となる。従って、EHR システムは、外部施設のステータスを捕捉し、適切な個人や組織に知らせる必要がある。確立されたビジネスルールに基づいたワーフフローの変化についても同様である。外部施設のステータスの変化は、患者安全に関係する。なぜなら医療関係者は、適宜、患者ケアやケア
ワークフローに順応する必要があるかもしれないからである。例えば、もはや認定されていない検査室、検査室の停電、長期ケア施設の容量超過を含む外部施設のステータスの変化などである。もし、検査室が認定を取り消されたら、管理者はそのワークフローを適切なものにするためにそのことを知らせる必要がある。もし、ステータスの変化が通常の原理では予想できない場合、システムは、外部の施設のステータスを熟慮したビジネスルールを確立することにより、自動的にワークフローを調整するトリガーとなるかもしれない。例えば、ローカルの長期ケア施設は、通常、週末の容量が超過しているかもしれない。従って、そのビジネスルールは自動的にワークフローを調整する。医療関係者
は、システムのアベイラビリティやパフォーマンスに依存する患者安全に関するリスクを緩和するた
めに、サービスレベルアグリーメント情報を知らされる必要があるかもしれない。

資料３ 用語集
用語aeromedical evacuation
aggregate patient data
ambulance
amendment
attestation
audit log
augmentation
authentication
authorization
care setting
claim
clinical document
clinical image
cliniciancompletenesscomputablecorrection
de-ｉdentify
delivery systems
demographic
demographic data
deprecatedeprecated status
directory
EHR system/EHR-S
eligibility
emergency medical services
emergency medical system
encounter
episode of careexternally-sourced
financial data
follow-up(s)formularyformularyguardian
health care delivery processes
health care organization
health care organizational
performance
health record information
health-related informationhome monitoring
interoperability
ISO/EN 13606
Electronic Health Record
Communication
jurisdictional
jurisdictional authorities
laboratory result
laboratory test
legal holdlegal requirements
legal retention period
ｌifecycle
lifespanliving will

対訳
患者空輸
患者データ集合
救急車
修正
検証
監査ログ
拡張
認証
認可
治療(中)
請求
診療文書
臨床画像
臨床家
完結性
コンピュータ利用可能
訂正
無名化
医療提供の制度
基本情報 または 患者属性
(患者の)基本情報
廃止
廃止状態
ディレクトリ
EHRシステム
保険加入資格救急医療サービス
救急医療システム(患者の)受療
治療（の間）
外部ソース（の）財務データ
フォローアップ
処方薬リスト
処方一覧
後見人
医療提供プロセス
医療機関
医療機関のパーフォーマンス
ヘルスレコード情報
健康関連情報在宅モニタリング
相互運用性
ISO/EN13606 EHR Communication規格
管轄区域
監督官庁
臨床検査結果臨床検査
訴訟ホールド
法的必要条件
法的保存期間ライフサイクルライフスパン
リビングウィル

locally-defined standard
machine interpretation
measurement
medication
medication history
medication reminder system
multiple instances
organizational policy
patient acuity
patient-originatedpersonal health record
person-level data
population-based
power of attorney form
primary care
protocolprovide the ability toprovider/providers
providers
policypublic healthpublic health organizations
radiographic image
reading capability
recallrecognized standard
record archiverecord entry
record stateregistry
re-identification
re-ｉdentify
renderrestoreretail pharmacy
retract
retrospective analysis
self-constructed queries
semantic meaning
serious adverse event
SHALL
SIG
standard terminology
structured-document interchange
standards
succession
surrogatetagtelemetryvital signwell-defined queries

ローカルに定義された
機械解釈
指標
投薬
薬歴
服薬リマインダーシステム
複数インスタンス
組織ポリシー
重篤度
患者由来（の）
個人健康記録人レベルのデータ
ポピュレーションに基づいた
法的委任状
かかりつけ
プロトコール～する機能を提供する
医療関係者
医療提供者
ポリシー
公衆衛生
公衆衛生の機関
レントゲン写真画像
読解力
リコール
広く認められた標準レコード保管レコード・エントリ
レコード状態
レジストリ
再特定化
実名化
提示する
復元
小売薬局
撤回
回顧分析
self-constructedクエリー
意味論的な意味
重篤有害事象しなければならない
用法
標準用語
構造化文書交換標準
遷移代理人
タグ
テレメトリー
バイタルサインwell-definedクエリー

資料 4
タスクフォースメンバー一覧（五十音順、活動時の所属組織を記載）

•

新垣

淑仁

日本電気株式会社

•

井川

澄人

株式会社 ソフトウェア・サービス

•

稲岡

則子

日本アイ・ビー・エム株式会社

•

大関

伸介

株式会社 シーエスアイ

•

岡田

真一

日本電気株式会社

•

岡田

美保子

一般社団法人

•

小柳出

•

高山

和也

富士通株式会社•

丹治

夏樹

日本電気株式会社•

塚田 智

亀田医療情報株式会社

•

並川

寛和

日本電気株式会社•

西土敦

亀田医療情報株式会社※JAHIS光宣

セキュリティ委員会

医療データ活用基盤整備機構

富士通株式会社委員長 茗原 秀幸

2019年3月発行

EHRシステム機能モデル リリース2の概要

発行元 保健医療福祉システム工業会〒105-0001 東京都港区虎ノ門1丁目19－9（虎ノ門TBビル6F）
電話 03-3506-8010 FAX 03-3506-8070（無断複写・転載を禁ず）