文档库 最新最全的文档下载
当前位置:文档库 › HL7V24文档翻译_病人转诊CH11

HL7V24文档翻译_病人转诊CH11

HL7V24文档翻译_病人转诊CH11
HL7V24文档翻译_病人转诊CH11

11.

Patient Referral

病人转诊Chapter Chair/Editor: Clement J. McDonald, MD

Regenstrief Institute and Indiana University School of Medicine

Chapter Chair/Editor: Hans Buitendijk

Shared Medical Systems

Chapter Chair/Editor: Gunther Schadow

Regenstrief Institute for Health Care

Chapter Chair/Editor: Helen Stevens

McKessonHBOC

11.1 CHAPTER 11 CONTENTS

11.1 CHAPTER 11 CONTENTS ....................................................................................................................... 11-1 11.2 PURPOSE.................................................................................................................................................... 11-4 11.2.1 P A TIENT REFERRAL AND RESPONSES ......................................................................................................11-5

11.2.1.1 Patient referral.............................................................................................................................. 11-6

11.2.1.2 Responding to a patient referral ................................................................................................... 11-7 11.2.2 A PPLICATION ROLES AND DATA PROCESS ...............................................................................................11-7

11.2.2.1 Application roles ........................................................................................................................... 11-7

11.2.2.2 The referring provider application role ........................................................................................ 11-8

11.2.2.3 The referred-to provider application role ..................................................................................... 11-8

11.2.2.4 The querying application role ....................................................................................................... 11-9

11.2.2.5 The auxiliary application role ..................................................................................................... 11-10

11.2.2.6 Application roles in a messaging environment ........................................................................... 11-11 11.2.3 G LOSSARY........................................................................................................................................... 11-11

11.2.3.1 Benefits: ...................................................................................................................................... 11-11

11.2.3.2 Clinical information: .................................................................................................................. 11-11

11.2.3.3 Dependent: .................................................................................................................................. 11-12

11.2.3.4 Eligibility/coverage: ................................................................................................................... 11-12

11.2.3.5 Encounter: .................................................................................................................................. 11-12

11.2.3.6 Guarantor: .................................................................................................................................. 11-12

11.2.3.7 Healthcare provider: ................................................................................................................... 11-12

11.2.3.8 Payor: ......................................................................................................................................... 11-12

11.2.3.9 Pre-authorization: ....................................................................................................................... 11-12

11.2.3.10 Primary care provider: ............................................................................................................... 11-12

11.2.3.11 Referral: ...................................................................................................................................... 11-12

Chapter 11: Referral

11.2.3.12 Referring provider: ..................................................................................................................... 11-12

11.2.3.13 Referred-to-provider: .................................................................................................................. 11-13

11.2.3.14 Specialist: ................................................................................................................................... 11-13

11.2.3.15 Subscriber: .................................................................................................................................. 11-13

11.3 PATIENT INFORMATION REQUEST MESSAGES AND TRIGGER EVENTS ............................ 11-14

11.3.1 RQI/RPI- REQUEST FOR INSURANCE INFORMA TION (EVENT I01) ........................................................ 11-15 11.3.2 RQI/RPL- REQUEST/RECEIPT OF PA TIENT SELECTION DISPLAY LIST (EVENT I02) ................................. 11-16 11.3.3 RQI/RPR- REQUEST/RECEIPT OF PA TIENT SELECTION LIST (EVENT I03) .............................................. 11-17 11.3.4 RQP/RPI- REQUEST FOR PA TIENT DEMOGRAPHIC DA TA (EVENT I04) ................................................... 11-18 11.3.5 RQC/RCI- REQUEST FOR PATIENT CLINICAL INFORMA TION (EVENT I05) ............................................. 11-19 11.3.6 RQC/RCL- REQUEST/RECEIPT OF CLINICAL DA TA LISTING (EVENT I06) .............................................. 11-21 11.3.7 PIN/ACK- UNSOLICITED INSURANCE INFORMA TION (EVENT I07) ....................................................... 11-22

11.4 PATIENT TREATMENT AUTHORIZATION REQUESTS ................................................................ 11-23

11.4.1 RQA/RPA- REQUEST PATIENT AUTHORIZATION MESSAGE ................................................................... 11-23 11.4.2 RQA/RPA- REQUEST FOR TREA TMENT AUTHORIZATION INFORMA TION (EVENT I08) ........................... 11-27 11.4.3 RQA/RPA- REQUEST FOR MODIFICATION TO AN AUTHORIZATION (EVENT I09) ................................... 11-27 11.4.4 RQA/RPA- REQUEST FOR RESUBMISSION OF AN AUTHORIZATION (EVENT I10) ................................... 11-27 11.4.5 RQA/RPA- REQUEST FOR CANCELLATION OF AN AUTHORIZATION (EVENT I11) .................................. 11-27 11.5 PATIENT REFERRAL MESSAGES AND TRIGGER EVENTS ........................................................ 11-28 11.5.1 REF/RRI- PA TIENT REFERRAL MESSAGE ............................................................................................. 11-28 11.5.2 REF/RRI- PA TIENT REFERRAL (EVENT I12) ......................................................................................... 11-31 11.5.3 REF/RRI- MODIFY PATIENT REFERRAL (EVENT I13) ............................................................................ 11-31 11.5.4 REF/RRI- CANCEL PA TIENT REFERRAL (EVENT I14)............................................................................ 11-32 11.5.5 REF/RRI- REQUEST PATIENT REFERRAL STA TUS (EVENT I15) .............................................................. 11-32 11.6 SEGMENTS .............................................................................................................................................. 11-32 11.6.1 RF1- REFERRAL INFORMATION SEGMENT............................................................................................ 11-32

11.6.1.0 RF1 - field definitions ................................................................................................................. 11-33

11.6.1.1 RF1-1 Referral status (CE) 01137 .......................................................................................... 11-33

11.6.1.2 RF1-2 Referral priority (CE) 01138 ....................................................................................... 11-33

11.6.1.3 RF1-3 Referral type (CE) 01139 ............................................................................................. 11-34

11.6.1.4 RF1-4 Referral disposition (CE) 01140 .................................................................................. 11-35

11.6.1.5 RF1-5 Referral category (CE) 01141 ..................................................................................... 11-36

11.6.1.6 RF1-6 Originating referral identifier (EI) 01142 .................................................................... 11-37

11.6.1.7 RF1-7 Effective date (TS) 01143 ............................................................................................. 11-38

11.6.1.8 RF1-8 Expiration date (TS) 01144 .......................................................................................... 11-38

11.6.1.9 RF1-9 Process date (TS) 01145 .............................................................................................. 11-38

11.6.1.10 RF1-10 Referral reason (CE) 01228 ....................................................................................... 11-38

11.6.1.11 RF1-11 External referral identifier (EI) 01300 ....................................................................... 11-39 11.6.2 AUT- AUTHORIZATION INFORMA TION SEGMENT ................................................................................. 11-40

11.6.2.0 AUT - field definitions ................................................................................................................. 11-41

11.6.2.1 AUT-1 Authorizing payor, plan ID (CE) 01146 ....................................................................... 11-41

11.6.2.2 AUT-2 Authorizing payor, company ID (CE) 01147 ............................................................... 11-41

11.6.2.3 AUT-3 Authorizing payor, company name (ST) 01148 ............................................................ 11-42

11.6.2.4 AUT-4 Authorization effective date (TS) 01149 ....................................................................... 11-42

11.6.2.5 AUT-5 Authorization expiration date (TS) 01150 ................................................................... 11-42

11.6.2.6 AUT-6 Authorization identifier (EI) 01151 ............................................................................. 11-42

11.6.2.7 AUT-7 Reimbursement limit (CP) 01152 ................................................................................ 11-43

11.6.2.8 AUT-8 Requested number of treatments (NM) 01153 ............................................................. 11-43

11.6.2.9 AUT-9 Authorized number of treatments (NM) 01154 ............................................................ 11-43

11.6.2.10 AUT-10 Process date (TS) 01145 ............................................................................................ 11-44 11.6.3 PRD- PROVIDER DA TA SEGMENT......................................................................................................... 11-44

Chapter 11: Referral

11.6.3.1 PRD-1 Provider role (CE) 01155 ............................................................................................ 11-45

11.6.3.2 PRD-2 Provider name (XPN) 01156 ....................................................................................... 11-45

11.6.3.3 PRD-3 Provider address (XAD) 01157 ................................................................................... 11-46

11.6.3.4 PRD-4 Provider location (PL) 01158 ..................................................................................... 11-46

11.6.3.5 PRD-5 Provider communication information (XTN) 01159.................................................... 11-47

11.6.3.6 PRD-6 Preferred method of contact - provider (CE) 00684 ................................................... 11-47

11.6.3.7 PRD-7 Provider identifiers (CM) 01162 ................................................................................. 11-47

11.6.3.8 PRD-8 Effective start date of provider role (TS) 01163 .......................................................... 11-47

11.6.3.9 PRD-9 Effective end date of provider role (TS) 01164 ............................................................ 11-48 11.6.4 CTD- CONTACT DA TA SEGMENT.......................................................................................................... 11-48

11.6.4.0 CTD field definitions ................................................................................................................... 11-49

11.6.4.1 CTD-1 Contact role (CE) 00196 ............................................................................................. 11-49

11.6.4.2 CTD-2 Contact name (XPN) 01165 ........................................................................................ 11-49

11.6.4.3 CTD-3 Contact address (XAD) 01166 .................................................................................... 11-50

11.6.4.4 CTD-4 Contact location (PL) 01167 ....................................................................................... 11-50

11.6.4.5 CTD-5 Contact communication information (XTN) 01168 ..................................................... 11-51

11.6.4.6 CTD-6 Preferred method of contact - provider (CE) 00684 ................................................... 11-51

11.6.4.7 CTD-7 Contact identifiers (CM) 01171 .................................................................................. 11-51

11.7 EXAMPLES .............................................................................................................................................. 11-51

11.7.1 RQI MESSAGE USING AN I01 EVENT WITH AN IMMEDIATE RESPONSE ................................................... 11-52 11.7.2 RQA MESSAGE USING AN I08 EVENT WITH AN IMMEDIATE RESPONSE.................................................. 11-53 11.7.3 RQA MESSAGE USING AN I08 EVENT WITH A DEFERRED RESPONSE...................................................... 11-53 11.7.4 REF MESSAGE USING AN I11 EVENT WITH AN IMMEDIATE RESPONSE................................................... 11-54 11.7.5 REF MESSAGE USING AN I11 EVENT WITH A DEFERRED RESPONSE....................................................... 11-55 11.7.6 RQC INQUIRY MESSAGE USING AN I05 EVENT WITH AN IMMEDIATE RESPONSE .................................... 11-57 11.8 OUTSTANDING ISSUES ........................................................................................................................ 11-59

11.8.1 HL7 OVERLAPPING WITH ASC X12N .................................................................................................. 11-59 目录

11 . 病人转诊 .............................................................................................................................. 错误!未定义书签。

11.1目的 ......................................................................................................................... 错误!未定义书签。

11.1.1病人转诊和回复 .............................................................................................................................. 11-5

11.1.2应用准则与数据处理 ...................................................................................................................... 11-7

11.1.3术语表 ............................................................................................................................................ 11-11 11.2病人信息的请求消息和触发事件..................................................................................................... 11-14

11.2.1RQI/RPI -请求保险信息(事件101) ......................................................................................... 11-15

11.2.2RQI/RPL -显示名单(事件I02) ...................................................................................................... 11-16

11.2.3RQI/RPR - 请求接受病人选择列表(事件 I03) ............................................................................. 11-17

11.2.4RQP/RPI - r请求病人的各项数据(事件I04).......................................................................... 11-18

11.2.5RQC/RCI -请求病人临床信息(事件I05) ................................................................................ 11-19

11.2.6RQC/RCL - 请求/接受临床数据列表(事件 I06) ........................................................................... 11-21

11.2.7PIN/ACK -主动提出的保险信息(事件I107)........................................................................... 11-22 11.3对病人实施治疗的授权请求。......................................................................................................... 11-23

11.3.1RQA/RP A -请求病人许可消息....................................................................................................... 11-23

11.3.2RQA/RP A - 请求治疗许可信息(事件I08) ............................................................................... 11-27

11.3.3RQA/RP A - 请求对一个授权的修改(事件I09)........................................................................ 11-27

11.3.4RQA/RP A -再次请求授权(事件I10) ........................................................................................ 11-27

11.3.5RQA/RP A -请求取消一个授权(事件I11)................................................................................. 11-27 11.4病人转诊的消息和事件。 ................................................................................................................ 11-28

Chapter 11: Referral

11.4.1REF/RRI -病人转诊消息 ............................................................................................................... 11-28

11.4.2REF/RRI -病人转诊(事件 I12)....................................................................................................... 11-31

11.4.3REF/RRI -修改病人转诊(事件I13) ............................................................................................... 11-31

11.4.4REF/RRI -取消病人转诊(事件I14) ............................................................................................... 11-32

11.4.5REF/RRI -请求病人转诊状况(事件I15) ....................................................................................... 11-32 11.5片 ........................................................................................................................................................ 11-32

11.5.1RF1 - 转诊资料片 .......................................................................................................................... 11-32

11.5.2AUT - 授权信息片.......................................................................................................................... 11-40

11.5.3PRD - 医疗单位数据片 ................................................................................................................. 11-44

11.5.4CTD - 相关数据片 ......................................................................................................................... 11-48 11.6例子 .................................................................................................................................................... 11-51

11.6.1RQI 通过直接回答的消息应用 I01 事件...................................................................................... 11-52

11.6.2RQA通过直接回答的消息应用 I08 事件.................................................................................... 11-53

11.6.3RQA通过直接回答的消息应用 I08 事件.................................................................................... 11-53

11.6.4REF通过直接回答的消息应用 I11 事件..................................................................................... 11-54

11.6.5REF通过延期回答的消息应用 I11 事件..................................................................................... 11-55

11.6.6RQC通过延迟回答的查询消息应用 I05 事件............................................................................ 11-57 11.7未解决的问题 .................................................................................................................................... 11-59

11.7.1HL7 和 ASC X12N的重复部分 ..................................................................................................... 11-59

11.2 PURPOSE

The Patient Referral chapter defines the message set used in patient referral communications between mutually exclusive healthcare entities. These referral transactions frequently occur between entities with different methods and systems of capturing and storing data. Such transactions frequently traverse a path connecting primary care providers, specialists, payors, government agencies, hospitals, labs, and other healthcare entities. The availability, completeness, and currency of information for a given patient will vary greatly across such a spectrum.

本章定义了应用于相互独立的医疗实体之间的病人安排交流信息。这些医疗安排的变动经常发生于应用不同获取和保存数据的方法和系统的实体之间。这种事务经常在初级保健单位、专家、付款者、政府机构、医院、实验室及其它医疗单位之间建立联系。对于一个病人的信息的可用性、完整性及同步性在他们之间大为不同。

The referral in this specification is viewed from the perspective of the provider as an individual, irrespective of

his/her affiliation with a specific institution or campus. Events triggering this kind of message are not restricted to a hospital environment, but have a community-wide area of impact in which more extensive identification of patients and healthcare providers is needed. Therefore, a referral must contain adequate identification information to meet the broadly varying requirements of the dissimilar systems within the community.

在本说明中谈及的医疗安排是从把供应作为个体化来看的,而不是把它与特定的机构联系起来。带来这种信息交换的事件不是限于医院的范围,而是社区性的范围。在其中需要更广泛的病人及保健单位的识别,因此,医疗安排必须包括足够的识别信息以满足社区中不同的系统的广泛的千差万别的要求。

This chapter describes the various events and resulting transactions that make up the referral message set. Examples have been provided to demonstrate the use of this specification within the events described. Each event example centers on a primary care provider's encounter with a patient. All of the examples in this chapter have been constructed using the HL7 Encoding Rules.

Chapter 11: Referral

本章叙述了一些不同的事件和由此产生的构成医疗安排系列的事务。如何在这些事件中应用本说明都一一举例说明。例子主要集中于初级保健单位处理病人中全部例子都采用HL7编码准则完成。

11.2.1 Patient referral and responses病人转诊和回复

When a patient is referred by one healthcare entity (e.g., a primary care provider) to another (e.g., a special-ist or lab) or when a patient inquiry is made between two separate entities, little is known about the infor-

mation each party requires to identify or codify the patient. The receiving entity may have no knowledge

of the patient and may require a full set of demographics, subscriber and billing information, eligibili-

ty/coverage information, pre-authorization information, and/or clinical data to process the referral. If the

receiving entity already has a record of the patient, the precise requirements for identifying that patient

record will vary greatly from one entity to another. The existing record of a patient residing in the database of a specialist, a lab, or a hospital may require updating with more current information. In addition, pro-

viders receiving a referral often require detailed information about the provider making the referral, such as

a phy sician’s name and address.

当病人在医疗单位间周转时(例如:初级保健单位到专家或实验室)或医疗单位之间的病人病情咨询时,医疗单位识别及整理资料所需的信息不为人知,转入单位可能没有病人的资料,需要一系列的人口、用户及记帐信息、资格/范围信息、认可前的信息。以及(或)临床资料来

完成转入,如果转入单位已经拥有该病人的记录,用于该病人的记录的详细要求在各单位间是不同的。在专家、实验室或医院中的数据库中已存在的病人记录可能需要更新的信息来更新。

此外,接受转入的单位常需要转出单位的详细信息,例如:内科医师的姓名和地址。

For example, a primary care provider making a referral may need to obtain insurance information or pre-

authorization from a payor prior to making a referral. Getting this information requires an inquiry and a re-sponse between the primary care provider and the payor. In addition, the primary care provider may re-

quest results from a lab to accompany the referral. Getting these results may require an inquiry and a re-

sponse between the primary care provider and the lab. The information could then be incorporated into a

referral sent from the primary care provider to the specialist. As the referral is processed, requested proce-dures are performed, the results are observed, and the relevant data must be returned to the primary care

provider. Such a response may frequently take the form of multiple responses as results become available.

例如:一个初级保健单位在转出前需要保险的信息或付款者的预先认可。获得此类信息需要初级保健单位转出时可能需要实验室出示结果,得到这些结果同样需要二者之间的咨询和应答。

然后,这些信息被汇集整和起来由初级医疗单位送至专科医院,随着转诊的进程、要求的步骤一一完成,实验室结果逐一分析。相关的资料必须反馈给初级保健单位,随着结果可以应用,这种应答也以多种多样的形式表现出来。

The message set that encompasses these transactions includes the referral (REF), requests for information

(RQA, RQC, RQP, RQI) and the returned patient information (RCI, RCL, RPA, RPI, RPL, RRI). The re-

ferral message originates a transaction and a return patient information message concludes the transaction.

At least one RPA/RPI is required to complete a patient referral or a patient request transaction, although

multiple RPI messages may be returned in response to a single REF message. The segments used in the

REF, RQA, RQI, RQP, RRI, RPH, RCI, RCL, RPA and RPI messages encompass information about patient, guarantor and next of kin demographics, eligibility/coverage information, accident, diagnosis, requested

procedures, payor pre-authorization, notes, and referring and consulting provider data.

围绕这些事务中的一系列信息,包括转诊在内,需要信息(RQA…RQL)以及信息的回馈

(RCI,RCL…FRL)转诊产生了事务、信息的蕴涵了这种事务,完成转诊或病员咨询事务,

至少需要一次RPA/RPI,尽管对于单个转诊信息多次FPI信息可能得到的反馈。在REF、

Chapter 11: Referral

RQA、RQI,RQP、RRL、…信息中采用的部分包括关于病人,担保人,亲属情况,合格/范围的信息以及转诊和会诊单位的资料。

11.2.1.1 Patient referral病人转诊

There are clear distinctions between a referral and an order. An order is almost always an intra-enterprise transaction and represents a request from a patient’s active provider to supporting providers for clearly d e-fined services and/or results. While the supporting provider may exercise great discretion in the perfor-

m ance of an order, overall responsibility for the patient’s plan of treatment remains with the ordering pr o-

vider. As such, the ordering provider retains significant control authority for the order and can, after the

fact, cause the order to be canceled, reinstated, etc. Additionally, detailed results produced by the support-ing provider are always reported back to the ordering provider, who remains ultimately responsible for eva-luating their value and relevance. A referral, on the other hand, can be either an intra- or an inter-enterprise transaction and represents not only a request for additional provider support but also a transfer of a portion or all of the responsibility fo r the patient’s plan of treatment. Once the referral is made, the referring pr o-

vider, during the transfer period, retains almost no control of any resulting actions. The referred-to provider becomes responsible for placing any additional orders and for evaluating the value and relevance of any re-sults, which may or may not be automatically passed back to the referring provider. A referred-to provider may, in turn, also become a referring provider.

在转诊和医嘱间有明确的区分,医嘱通常是单位内部的事务,是主治者要求辅助者提供明确指定服务和(或)检查结果。尽管辅助单位谨慎地执行医嘱。但医嘱制定人仍需对病人的治疗计划负责。如此以来,医嘱制定人仍严格把持着医嘱权,由此可以取消医嘱,恢复医嘱等。此

外,主治者要负责评价辅助单位提供的详细检查报告和相关性。而转出医疗安排既可为同一单位内部,也可为不同单位之间的事务。其不但要求其他单位的支持。而且部分或全部移交了治疗计划的责任。转出单位在转出起不负责任何责任,而转入单位取而代之执行判定医嘱的评价检查结果的价值和相关性,可以也可以不反馈给转出单位。转入单位,反之,也变成了转出单位。

A referral message is used to support transactions related to the referral of a patient from one healthcare

provider to another. This kind of message will be particularly useful from the perspective of a primary care provider referring a patient to a specialist. However, the application of the message should not be limited to this model. For example, a referral may be as simple as a physician sending a patient to another physi-

cian for a consultation or it may be as complex as a primary care provider sending a patient to a specialist for specific medical procedures to be performed and attaching the payor authorizations for those requested procedures as well as the relevant clinical information on the patient's case.

转诊的资料帮助实现医疗单位间病人的周转。这类资料在初级医疗单位转病人到专科时特别有用。然而,资料的应用并不仅限于这种模式。例如:转诊可以简单到一个内科医师请另一个内科医师为病人会诊,也可以复杂至初级医疗单位把病人转到专科或得到付款单位对转诊的授

权。以及提供病人的相关的临床资料。

In a community model, stringent security requirements will need to be met when dealing with the release of clinical information. This message set facilitates the proper qualification of requests because the message packet will contain all the data required by any application in the community, including the necessary pa-

tient demographic information and the proper identification of the party requesting the information.

在社区模式中,临床资料的公布需要符合严格的安全要求。由于这一系列资料包括全部的社区内实行需要的数据,包括必须的家庭、人口信息及索要资料的单位的正确识别。

Chapter 11: Referral

11.2.1.2 Responding to a patient referral对转诊的回复

When a patient is referred by one provider to another or is pre-admitted, there is a great likelihood that sub-sequent transactions will take place between the initiating entity (the referring or admitting physician) and the responding entity (the specialist or hospital). The subsequent transactions might include a variety of

queries, orders, etc. Within those subsequent transactions, there must be a way for the initiating system to refer to the patient. The “generic” patient information included in the original referral or the pre-admit Pa-tient Identification (PID) segment may not be detailed enough to locate the patient in the responding facili-ty’s database, unless the responding facility has assigned a unique identifier to the new patient. Similarly, the responding system may not have record retrieval capabilities based on any of the unambiguous, facility-neutral data elements (like the Social Security Number) included in the original referral or pre-admit PID

segment. This problem could result in the responding system associating subsequent orders or requests

with the wrong patient. One solution to this potential problem is for the responding system to utilize the

RRI message and return to the initiating system the unique internal identifier it assigns to the patient, and

with which it will primarily (or even exclusively) refer to that patient in all subsequent update operations.

However, the intent of the RRI message is that it will supply the originator of the referral type message

with sufficient patient demographic and/or clinical information to properly process continued transactions.

当病人转诊或安排入院时,在初始单位转入或收病人的内科医师和回应单位(专科医师或医

院)就产生这种事务。随之而来的事务可以包括一系列的询问、医嘱等。其中,需要有对病人的初级描述,这一“类型”的病人资料包括最初的转诊或入院前病人的识别。(PID)除非回应单位已经指定了特殊的新病人识别方法,否则它不会在回应指定的数据库中准确定位新病

人。同样,回应单位系统也不会具有基于在最初转诊或入院中包括的清晰客观参照数据对记录的提取能力。这一问题会导致回应单位无法正确的把病人及响应的医嘱和要求联系起来。解决这一潜在的问题的办法之一,是应用RRI资料及回到最初单位指定的特定内部识别。通过它就可以在所有的接下来的更新操作中专一地指定响应病人。但是,RRI资料的作用主要是提供帮助初始单位顺利完成转诊过程所需的充足的病人家庭人口资料和临床资料。

11.2.2 Application roles and data process应用准则与数据处理

11.2.2.1 Application roles应用准则

This Standard assumes that there are four roles that an application can take on: a referring or referred-by

provider application role, a referred-to provider application role, a querying application role, and an aux-

iliary application role. These application roles define the interactions an application will have with other

applications in the messaging environment. In many environments, any single application may take on

more than one application role.

这个标准是基于一个应用具有以下4个准则:这些准则定义了在消息环境下一个应用程序与另一个应用程序之间的交互作用。在许多环境中,单个的应用程序可能具有多于一个的应用准则。

This Standard’s definition of application roles does not intend to define or limit the functionality of specific products developed by vendors of such applications. Instead, this information is provided to help define

the model used to develop this Standard, and to provide an unambiguous way for applications to communi-cate with each other.

这个应用准则标准的定义并不打算明确界限或限制由对于这样的应用程序的买主开发的特别产品的功能。相反,它不仅能帮助定义开发这个标准的的模型,而且还能为应用提供一个明确的方式去互相通讯。

Chapter 11: Referral

11.2.2.2 The referring provider application role专科医生应用程序准则

A referring provider application requests the services of another healthcare provider (a referred-to provider)

application. There may or may not be any association between the referring provider application and the

receiving entity. Although in most cases a referral environment will be inter-enterprise in nature, it is not

limited to that model and applies to intra-enterprise situations also. Because the referring provider applica-tion cannot exert any control over the referred-to provider application, it must send requests to modify the status of the referred-to provider application. The referring provider application will often assume an aux-iliary application role once a patient has been accepted by another application. Once this happens, the re-

ferring provider application may receive unsolicited status updates from the referred-to provider application concerning the care of a patient.

专科医生应用程式需要医院应用程式所提供的服务。在专科医生应用程式与接收实体之间可能有也可能没有任何联系。虽然在大多数情况下,一个特定的环境在本质上是企业内部的,但对企业内部而言它也不应该被限于那个模型和应用的范围内,因为专科医生的应用程式不能施加任何控制于医疗单位应用程序,它必须发出请求去改变医疗单位应用程序状态。一旦一个病人被某一个应用程序所接受,专科医生应用程序经常假设有一个互补性的应用规则。一旦发生这个,专科医生应用程序可能会接收从和照顾这个病人有关的医疗单位应用程序中的主动的状态升级。

The analog of a referring provider application in a non-automated environment might be a primary care

provider diagnosing a patient with a problem that must in turn be referred to a specialist for a service. The primary care provider would contact the specialist and refer the patient into his care. Often, the specialist may not receive the patient into his care, preferring instead to refer the patient to another healthcare provid-er. The referring provider will indicate the diagnosis and any requested services, and the specialist to

whom the patient is referred will indicate whether the referral will be accepted as specified. Once a patient referral has been accepted by the specialist, the specialist may send out updates to the primary care provider concerning the status of the patient as regards any tests performed, their outcomes, etc.

在一个非自动化的环境下,专科医生应用系统的分析可能就是一个诊断出病人得了什么必须有专家治疗的病的初级保健单位。初级保健单位将和专家取得联系并且推荐病人去他那儿治疗。

经常,专家可能不接收这个病人而是推荐病人去另外一家医疗单位。专科医生将简要说明推荐是否被特别接收的原因。一旦推举的病人被专家所接受,专家将会对初级医疗单位发出关于测试执行情况,它们的结果等等的升级命令。

11.2.2.3 The referred-to provider application role专科医生应用程序规则

A referred-to provider application, in the referral model, is one that performs one or more services re-

quested by another healthcare provider (referring provider). In other words, a referred-to provider applica-tion exerts control over a certain set of services and defines the availability of those services. Because of

this control, no other application has the ability to accept, reject, or otherwise modify a referral accepted by

a particular referred-to provider application.

在转诊模式下,专科医生应用程式应医疗单位的请求执行一个或多个服务。换句话说,一个专科医生应用程式对一系列的服务施加控制,并且定义这些服务的可行性。由于这种控制,没有其他的应用程式能够接收,拒绝或者反过来改变一个已经被一个特别的专科医生说接受的转诊系统。

Other applications can, on the other hand, make requests to modify the status of an accepted referral

“owned by” the referred-to provider application. The referred-to provider application either grants or de-

nies requests for information, or otherwise modifies the referrals for the services over which it exerts con-

Chapter 11: Referral

另一个方面,其他的应用程式能够提出请求去改变一个已经为专科医生应用程式所接收的转诊系统。专科医生应用程式或者接受或者拒绝这种请求,或反过来改变因为它所施加的控制的服务的转诊系统。

Finally, the referred-to provider application also provides information about the referral encounter to other applications. The reasons that an application may be interested in receiving such information are varied.

An application may have previously requested the status of the referral encounter, or it may simply be in-

terested in the information for its own clinical reporting or statistical purposes. There are two methods

whereby the referred-to provider applications disseminate this information: by issuing unsolicited informa-tion messages to auxiliary applications, or by responding to queries made by querying applications.

最后,专科医生应用程式也提供关于偶遇其它应用程式的转诊系统信息。应用程式可能对接收此种信息的原因是多种多样的。一个应用程式可能会提前需要转诊的供需见面的状态,或者它只简单的因为它自己的医疗报告或统计目的而对信息感兴趣。所以专科医生应用系统散布信息有两种方法:一是通过散布简单的消息给复杂的应用系统,二是通过查询的应用程式去对查询作出回应。

The analog of a referred-to provider application in a non-automated environment might be a specialist such as a cardiologist. A patient does not generally go to a cardiologist for routine health care. Instead, a pa-

tient generally goes to a primary care provider, who may diagnose the patient with a heart ailment and refer that patient to a cardiologist. The cardiologist would review the information provided with the referral re-quest and determine whether or not to accept the patient into his care. Once the cardiologist accepts the pa-tient, anyone needing information on the status of the patient must then make requests to the cardiologist.

In addition, the cardiologist may forward unsolicited information regarding the treatment of the patient

back to the primary care provider. Once the cardiologist accepts the referred patient, he/she may determine that additional information regarding the patient is needed. It will often take the role of a querying applica-tion by sending a query message to the patient’s primary care provider and requesting additional inform a-

tion on demographics, insurance information, laboratory test results, etc.

被转诊方应用程序的模拟在一个非自动化环境下可能是一个专家,例如一个心脏病专家。一个病人一般不会经常为了日常的健康检查找心脏病专家。然而病人可以经常去初级医疗单位,诊断病人的心脏疾病并把病人提交给专家。心脏病专家将会使用转诊请求来回顾提供的信息并决定是否接收这个病人。一旦心脏病专家接受了这个病人,任何一个需要的病人状况的信息必须给心脏病专家发出请求。另外,心脏病专家可能会反过来主动发出关于病人治疗的信息给初级医疗单位。一旦心脏病专家接收了转诊病人,他/她可能要决定关于病人需要的附加信息。这个过程经常扮演查询程序的

角色来发送一个查询消息给病人的初级医疗单位和请求的人口附加信息、保险信息、实验室实验结果,等等。

11.2.2.4 The querying application role查询程序角色

A querying application neither exerts control over, nor requests changes to a referral. Rather than accepting

unsolicited information about referrals, as does an auxiliary application, the querying application actively

solicits this information using a query mechanism. It will, in general, be driven by an entity seeking infor-mation about a referral such as a referring provider application or an entity seeking information about a re-ferred patient such as a referred-to provider application. The information that the querying application

receives is valid only at the exact time that the query results are generated by the provider applications.

Changes made to the referral or the referred patient’s status after the query results have been returned are

not communicated to the querying application until it issues another query transaction.

查询应用程序即不运行控制也不请求转变转诊。胜于接收关于转诊主动提出的,就象执行一个辅助的程序,这个查询程序积极的恳求这个查询机制信息。通常,它被一个实体分开寻找关于象一个转

Chapter 11: Referral

诊方程序信息的转诊,或者一个实体寻找关于象一个被转诊方程序信息的转诊。仅在查询结果的准确时间内接收查询程序消息是有效的。

The analog of a querying application in a non-automated environment might be a primary care provider

seeking information about a specific patient who has been referred to a specialist. For example, a patient may have been referred to a specialist in order that a specific test be performed, following which, the pa-

tient would return to the primary care provider. If the specialist has not forwarded information regarding the testing procedures for the patient to the primary care provider, the primary care provider would then

query the specialist for the outcome of those procedures. Likewise, if a specialist received a referred pa-

tient without the preliminary diagnoses of test results, he/she might in turn query the primary care provider for the information leading to the diagnoses and subsequent referral.

在一个非自动的环境下查询程序的相似体可能是一个初级医疗单位寻求关于特定病人的信息,这是一个被专家指定的病人。例如:一个病人可能为了执行特殊的检查转给专家,接下来,病人将返回给初级医疗单位。如果专家没有送来关于病人检查处理的信息给初级医疗单位,初级医疗单位可以询问专家关于这些处理的结果。同样的如果一个专家接收了一个病人,不包括初级的检查结果,他/她可能询问初级医疗单位初级检查的结果。

11.2.2.5 The auxiliary application role辅助程序角色

Like querying applications, an auxiliary application neither exerts control over nor requests changes to a re-ferral or a referred patient. They, too, are only concerned with gathering information about a particular re-ferral. An auxiliary application is considered an “interested third-party,” in that it is interes ted in any

changes to a particular referral or referred patient, but has no interest in changing it or controlling it in any way. An auxiliary application passively collects information by receiving unsolicited updates from a pro-vider application.

象查询程序一样,辅助程序角色即不运行控制也不请求转变转诊。辅助程序角色也仅仅与收集关于特定转诊病人的信息。一个辅助程序被认为是一个“有意义的第三方”,变成特殊转诊或转诊病人是有意义的,但是在所有的情况下不是有意义的。一个查询程序被动的收集信息通过接受主动提出的来自医疗单位程序的升级。

The analog of an auxiliary application in a non-automated environment might be any person receiving re-ports containing referral information. For example, an insurance company may need information about the activities a patient experiences during specific referral encounters. Primary care providers may need to

forward information regarding all referred patients to a payor organization.

在非自动环境下辅助程序的相似体可能是所有的接受包含转诊信息的报告的人。例如:一个保险公司可能需要关于一个病人在特殊转诊过程中经历的活动的信息。初级医疗单位可能需要迅速的把关于所有转诊病人的信息送给付款者机构。

In turn, a primary care provider may have the ability to track electronically a patient’s medical record. She or he would then be very interested in receiving any information regarding the patient (s)he has referred to

a specialist.

实际上,一个初级医疗单位可能有能力记录电子病人检查记录。他或她将对接收任何关于转到专家的病人的消息感兴趣。

Chapter 11: Referral 11.2.2.6 Application roles in a messaging environment消息环境的应用程序角色。

In a messaging environment, these four application roles communicate using specific kinds of messages

and trigger events. The following figure illustrates the relationships between these application roles in a

messaging environment:

在一个消息环境中,这四个应用程序角色通讯使用了特别各种各样的消息和触发事件。下列图形化的例子说明了消息环境的应用程序角色个应用程序之间的关系。

Figure 11-1. Application role messaging relationships

图 11-1. 消息关系程序角色

11.2.3 Glossary术语表

11.2.3.1 Benefits:

The services payable under a specific payor plan. They are also referred to as an insurance product, such as professional services, prescription drugs, etc.

11.2.3.2 Clinical information:

Refers to the data contained in the patient record. The data may include such things as problem lists, lab

results, current medications, family history, etc. For the purposes of this chapter, clinical information is li-mited to diagnoses (DG1& DRG), results reported (OBX/OBR), and allergies (AL1).

Chapter 11: Referral

11.2.3.3 Dependent:

Refers to a person who is affiliated with a subscriber, such as spouse or child.

11.2.3.4 Eligibility/coverage:

Refers to the period of time a subscriber or dependent is entitled to benefits.

11.2.3.5 Encounter:

Refers to a meeting between a covered person and a healthcare provider whose services are provided. 11.2.3.6 Guarantor:

Refers to a person who has financial responsibility for the payment of a patient account.

11.2.3.7 Healthcare provider:

Refers to a person licensed, certified or otherwise authorized or permitted by law to administer health care in the ordinary course of business or practice of a profession, including a healthcare facility.

11.2.3.8 Payor:

Indicates a third-party entity who pays for or underwrites coverage for healthcare expenses. A payor may be an insurance company, a health maintenance organization (HMO), a preferred provider organization

(PPO), a government agency or an agency such as a third-party administrator (TPA).

11.2.3.9 Pre-authorization:

Refers to the process of obtaining prior approval as to the appropriateness of a service. Pre-authorization does not guarantee coverage.

11.2.3.10 Primary care provider:

Indicates the provider responsible for delivering care as well as authorizing and channeling care to special-ists and other providers in a gatekeeper system. The provider is also referred to as a case manager or a ga-tekeeper.

11.2.3.11 Referral:

Means a provider’s recommendation that a covered person receive car e from a different provider.

11.2.3.12 Referring provider:

Indicates the provider who requests services from a specialist or another primary care provider. A referring provider may, in fact, be a specialist who is referring a patient to another specialist.

Chapter 11: Referral

11.2.3.13 Referred-to-provider:

Typically indicates a specialty care provider who provides services at the request of a primary care provider or another specialty care provider.

11.2.3.14 Specialist:

Means a provider of services which are beyond the capabilities or resources of the primary care provider. A specialist is also known as a specialty care provider who provides services at the request of a primary care provider or another specialty care provider.

11.2.3.15 Subscriber:

Refers to a person who elects benefits and is affiliated with an employer or insurer.

11.2.3.16 医疗津贴:

特定付款单位计划内可提供资金的服务。也指保险的产品,如专业服务,处方药物等。

11.2.3.17 临床信息:

指病人病历记录包含的数据。这些数据包括主要的问题清单、实验室检查结果,、目前治疗、家族史等。在本章中临床信息仅限于诊断,检查结果及过敏史。

11.2.3.18 依赖他人者:

指用户家属,如配偶或孩子。

11.2.3.19 资格/范围:

指用户和依赖他人者享受医疗津贴的时限。

11.2.3.20 供需见面:

指在时限范围内用户和提供其医疗服务的单位间的见面。

11.2.3.21 担保人:

指对于病人帐户付款提供金融担保的人。

11.2.3.22 医疗单位:

指注册、认可、授权或法律允许的在业余或职业医疗中提供医疗服务的人。包括医疗机构。

Chapter 11: Referral

11.2.3.23 付款单位:

指负责承担合约中包括的医疗支出的第三方。它可以是保险公司,保健维护组织(HMO),指定提供组织(PPO),政府机构或其他机构。例如第三方管理单位(TPA)。

11.2.3.24 预先认可:

指获取适合服务预先同意的过程,它不保证其同意的范围。

11.2.3.25 初级保健单位:

指负责提供保健,以及在把关系统中认可转到专科或其他医疗单位治疗的提供者。它也指病例管理员及审核员。

11.2.3.26 转诊:

指医疗单位对于处于实现内的人接受其他单位医疗服务的建议。

11.2.3.27 转诊方:

指用于专科医生或其它一级保健员提供服务的提供者。事实上,它也可以为介绍病人给其它专科医生的专科医生。

11.2.3.28 被转诊方:

主要指提供给保健员或另一专科保健提供者所要求的医疗服务的专科保健员。

11.2.3.29 专家:

指能力在一级保健员之上的医务工作者,也指为一级保健员或其他专科保健员提供医疗服务的专科保健员。

11.2.3.30 用户:

指选择医疗津贴,与雇员或保险公司建立联系的人。

11.3 PATIENT INFORMATION REQUEST MESSAGES AND TRIGGER

EVENTS病人信息的请求消息和触发事件

Patient information may need to be retrieved from various enterprises. The definition of these enterprises often varies greatly. Some enterprises may be providers or reference laboratories, while others may be payors providing insurance information. In the first case, the message definitions will focus on patient and provider information, while in the latter case, the message definition will deal primarily with patient and subscriber identification.

Chapter 11: Referral

病人信息可能需要从各种机构中重新获得。这些机构的定义经常有很大的变化。有些机构可能是医疗单位

或涉及到的实验室,而另一些有可能是提供保险信息的付款单位。第一个事件,消息的定义将集中在病人

和医疗单位的信息,而以后的事件,消息的定义将主要处理用户和病人的鉴定。

11.3.1 RQI/RPI - request for insurance information (event I01) RQI/RPI -请求保险

信息(事件101)

This event triggers a message to be sent from one healthcare provider to another to request insurance in-

formation for a specified patient.

这个事件触发了一个消息,它从一个医疗机构发送到另一个,为一个特定的病人请求保险信息。

RQI^I01^RQI_I01 Request Patient Information Chapter

MSH Message Header 2

{

PRD Provider Data 11 [{CTD}] Contact Data 11

}

PID Patient Identification 3

[{NK1}] Next of Kin/Associated Parties 6

[[{GT1}] Guarantor 6

{

IN1 Insurance 6

[IN2] Insurance Additional Info 6

[IN3] Insurance Add’l Info - Cert 6

}

]

[{NTE}] Notes and Comments 2

RPI^I01^RPI_I01 Return Patient Information Chapter

MSH Message Header 2

MSA Message Acknowledgment 3

{

PRD Provider Data 11 [{CTD}] Contact Data 11

}

PID Patient Identification 3

[{NK1}] Next of Kin/Associated Parties 6

[[{GT1}] Guarantor 6

{

IN1 Insurance 6

[IN2] Insurance Additional Info 6

[IN3] Insurance Add’l Info - Cert 6

}

]

[{NTE}] Notes and Comments 2

RQI^I01^RQI_I01 请求病人信息章

MSH 消息头 2

{

PRD医疗单位的数据11 [{CTD}] 相关数据11

}

PID 病人鉴定 3

[{NK1}] 下一个同类的或相关的部分 6

[[{GT1}] 担保人 6

{

IN1 保险 6

[IN2] 保险附加信息 6

[IN3] 保险附加信息-确定的信息 6

}

Chapter 11: Referral

RPI^I01^RPI_I01 Return Patient Information Chapter

[{NTE}] 说明与注释 2

RPI^I01^RPI_I01 返回病人的信息章

MSH 消息头 2

MSA 消息确认 3

{

PRD医疗单位的数据11 [{CTD}] 相关数据11

}

PID 病人鉴定 3

[{NK1}] 下一个同类的或相关的部分 6

[[{GT1}] 担保人 6

{

IN1 保险 6

[IN2] 保险附加信息 6

[IN3] 保险附加信息-确定的信息 6

}

]

[{NTE}] 说明与注释 2

11.3.2 RQI/RPL - request/receipt of patient selection display list (event I02)

RQI/RPL -显示名单(事件I02)

This trigger event occurs when the inquirer specifies a request for a name lookup listing. Generally, this request is used by the responder when insufficient data is on hand for a positive match. In this case, the re-quester may ask for a list of possible candidates from which to make a selection. This event code is also used by the responder to signify that the return information contains a list of information rather than infor-mation specific to a single patient.

当请求者为了一个查询名单中的名字而指定一个请求时,这个事件被触发。通常,当回应者手头上没有某一确定病人足够的数据时,这个请求被使用。既然这样,请求者可以请求一个可能成为候选者的病人名单,并可以从这个名单中作出选择。这个事件编码也可以用在回应者表示回复信息,它包括一个列表,而不是一个特定病人的信息。

RQI^I02^RQI_I01 Request Patient Information Chapter

MSH Message Header 2

{

PRD Provider Data 11 [{CTD}] Contact Data 11

}

PID Patient Identification 3

[{NK1}] Next of Kin/Associated Parties 6

[[{GT1}] Guarantor 6

{

IN1 Insurance 6

[IN2] Insurance Additional Info 6

[IN3] Insurance Add’l Info - Cert 6

}

]

[{NTE}] Notes and Comments 2

RQI^I02^RQI_I01 返回病人的信息章

MSH 消息头 2

{

PRD医疗单位的数据11 [{CTD}] 相关数据11

}

PID 病人鉴定 3

[{NK1}] 下一个同类的或相关的部分 6

[[{GT1}] 担保人 6

Chapter 11: Referral

RQI^I02^RQI_I01 Request Patient Information Chapter

{

IN1 保险 6

[IN2] 保险附加信息 6

[IN3] 保险附加信息-确定的信息 6

}

]

[{NTE}] 说明与注释 2

RPL^I02^RPL_I02 Return Patient Display List Chapter

MSH Message Header 2

MSA Message Acknowledgment 3

{

PRD Provider Data 11

[{CTD}] Contact Data 11

}

[{NTE}] Notes and Comments 2

[{DSP}] Display Data 5

[ DSC ] Continuation Pointer 2

RPL^I02^RPL_I02 返回病人名单章

MSH 消息头 2

MSA 消息确认 3

{

PRD 医疗单位的数据11

[{CTD}] 相关数据11

}

[{NTE}] 说明与注释 2

[{DSP}] 病人列表 5

[ DSC ] 附加部分指针 2

11.3.3 RQI/RPR - request/receipt of patient selection list (event I03)

RQI/RPR - 请求接受病人选择列表(事件 I03)

This trigger event occurs when the inquirer specifies a request for a listing of patient names. This event dif-fers from event I02 (request/receipts of patient selection display list) in that it returns the patient list in re-

peating PID segments instead of repeating DSP segments.

RQI^I03^RQI_I01 Request Patient Information Chapter

MSH Message Header 2

{

PRD Provider Data 11 [{CTD}] Contact Data 11

}

PID Patient Identification 3

[{NK1}] Next of Kin/Associated Parties 6

[[{GT1}] Guarantor 6

{

IN1 Insurance 6

[IN2] Insurance Additional Info 6

[IN3] Insurance Add’l Info - Cert 6

}

]

[{NTE}] Notes and Comments 2

RPR^I03^RPR_I03 Return Patient List Chapter

MSH Message Header 2

MSA Message Acknowledgment 3

{

PRD Provider Data 11

Health Level Seven, Version 2.4 ? 2000. All rights reserved. Page 11-17

Chapter 11: Referral

RPR^I03^RPR_I03 Return Patient List Chapter

[{CTD}] Contact Data 11

}

[{PID}] Patient Identification 3

[{NTE}] Notes and Comments 2

当查询者为了一些查询名单中的名字而指定一个请求时,这个事件被触发。这个事件和事件I02不同,事件I03是在重复PID片时返回病人名单,而不是在重复DSP时返回。

RQI^I03^RQI_I01 返回病人信息章

MSH 消息头 2

{

PRD医疗单位的数据11 [{CTD}] 相关数据11

}

PID 病人鉴定 3

[{NK1}] 下一个同类的或相关的部分 6

[[{GT1}] 担保人 6

{

IN1 保险 6

[IN2] 保险附加信息 6

[IN3] 保险附加信息-确定的信息 6

}

]

[{NTE}] 说明与注释 2

RPR^I03^RPR_I03 返回病人列表章

MSH 消息头 2

MSA 消息确认 3

{

PRD医疗单位的数据11 [{CTD}] 相关数据11

}

[{PID}] 病人鉴定 3

[{NTE}] 说明与注释 2

11.3.4 RQP/RPI - request for patient demographic data (event I04)

RQP/RPI - r请求病人的各项数据(事件I04)

这个事件触发了一个请求,它从一个医疗单位到另一个医疗单位间传递病人详细的信息,包括保险费和帐单。通常,这种事务发生在两个医疗单位之间,但是也可以直接传递给付款者。

RQP^I04^RQP_I04 请求病人的亲属统计章

MSH 消息头 2

{

PRD医疗单位的数据11 [{CTD}] 相关数据11

}

PID 病人鉴定 3

[{NK1}] 下一个同类的或相关的部分 6

[{GT1}] 担保人 6

[{NTE}] 说明与注释 2

RPI^I04^RPI_I04 Return Patient Information返回病人信息章

MSH 消息头 2

MSA 消息确认 3

{

Chapter 11: Referral

RPI^I04^RPI_I04 Return Patient Information返回病人信息章

[{CTD}] 相关数据11

}

PID 病人鉴定 3

[{NK1}] 下一个同类的或相关的部分 6

[[{GT1}] 担保人 6

{

IN1 保险 6

[IN2] 保险附加信息 6

[IN3] 保险附加信息-确定的信息 6

}

]

[{NTE}] 说明与注释 2

This event triggers a request from one healthcare provider to another for patient demographic information, including insurance and billing information. Typically, this transaction would occur between one provider to another, but it could also be directed to a payor.

RQP^I04^RQP_I04 Request Patient Demographics Chapter

MSH Message Header 2

{

PRD Provider Data 11 [{CTD}] Contact Data 11

}

PID Patient Identification 3

[{NK1}] Next of Kin/Associated Parties 6

[{GT1}] Guarantor 6

[{NTE}] Notes and Comments 2

RPI^I04^RPI_I04 Return Patient Information Chapter

MSH Message Header 2

MSA Message Acknowledgment 3

{

PRD Provider Data 11 [{CTD}] Contact Data 11

}

PID Patient Identification 3

[{NK1}] Next of Kin/Associated Parties 6

[[{GT1}] Guarantor 6

{

IN1 Insurance 6

[IN2] Insurance Additional Info 6

[IN3] Insurance Add’l Info - Cert 6

}

]

[{NTE}] Notes and Comments 2

11.3.5 RQC/RCI - request for patient clinical information (event I05)

RQC/RCI -请求病人临床信息(事件I05)

This event is used to request clinical information for a specific patient. Generally, this transaction occurs

between one provider and another (typically a laboratory or radiology, etc.). However, it may also be very useful for a payor-to-provider request for clinical observation information to be used in considering a re-

quest for treatment authorization.

这个事件用在为一个特定病人请求临床信息时。通常,这个事务发生在两个医疗机构之间(一般是一个实验室或放射科)。然而,对于从付款者到医疗单位的临床信息,这个事务可能非常有用,用于请求治疗许可。

RQC^I05^RQC_I05 请求临床信息章

Chapter 11: Referral

RQC^I05^RQC_I05 请求临床信息章

QRD 查询定义 5

[QRF] 查询筛选 5

{

PRD医疗单位的数据11 [{CTD}] 相关数据11

}

PID 病人鉴定 3

[{NK1}] 下一个同类的或相关的部分 6

[{GT1}] 担保人 6

[{NTE}] 说明与注释 2

RCI^I05^RCI_I05 返回临床信息章

MSH 消息头 2

MSA 消息确认 3

QRD 查询定义 5

[QRF] 查询筛选 5

{

PRD医疗单位的数据11 [{CTD}] 相关数据11

}

PID 病人鉴定 3

[{DG1}] 诊断 6

[{DRG}] 诊断相关的组合 6

[{AL1}] 敏感信息 3

[

{

OBR 请求观察报告 4

[{NTE}] 说明与注释 2

[

{

OBX 意见/结果7

[{NTE}] 说明与注释 2

}

]

}

]

[{NTE}] 说明与注释 2

RQC^I05^RQC_I05 Request Clinical Information Chapter

MSH Message Header 2

QRD Query Definition 5

[QRF] Query Filter 5

{

PRD Provider Data 11 [{CTD}] Contact Data 11

}

PID Patient Identification 3

[{NK1}] Next of Kin/Associated Parties 6

[{GT1}] Guarantor 6

[{NTE}] Notes and Comments 2

RCI^I05^RCI_I05 Return Clinical Information Chapter

MSH Message Header 2

MSA Message Acknowledgment 3

QRD Query Definition 5

[QRF] Query Filter 5

{

PRD Provider Data 11 [{CTD}] Contact Data 11

}

PID Patient Identification 3

[{DG1}] Diagnosis 6

[{DRG}] Diagnosis Related Group 6

很实用的PDF文档在线翻译工具,整篇PDF翻译一键搞定

前言: 作为大学生,或者是上班族经常会需要下载一些文献来看,每次开开心心的下载之后,一打开发现是英文的文章,而且还是PDF格式的,这就很头疼了,就算是英文比较好的,看英文版的文献也是够呛啊,那么怎么翻译PDF英文文献?今天呢就来给大家推荐一个很实用的PDF文档在线翻译工具,整篇PDF 翻译一键搞定,还在等什么,一起来看看吧。 有很多种方法都能实现PDF翻译哦,下面就来一一为大家介绍哦。 一、将PDF转Word 可以通过迅捷PDF转换器将PDF文件转换成Word,进入可编辑的状态,打开软件然后将PDF文件添加进去,添加完成之后点击“开始转换”即可。

转换完成之后呢,Word中进行全文翻译,在审阅中,可以看到翻译选项(offi ce版本要高一点,我使用的是office 2016版)。

翻译文档:点击后,会自动跳转自微软翻译的网页,对全文进行翻译; 翻译所选文字:选中后会在右边的框中显示翻译好的内容; 翻译屏幕提示:点击后,只要你选中文字,不管是单词还是段落,都会跳出翻译好的窗口,相当于翻译软件中的选词翻译。 二、在线网站 操作工具:迅捷PDF在线转换器 网址:https://https://www.wendangku.net/doc/ff13589395.html,/ 通过上面的网址进入到迅捷PDF在线转换器网站的首页可点击“文档处理”在其下面的子栏目选择“PDF在线翻译”。

选择“点击选择文件”将要翻译的PDF文件添加进去,添加好之后选择翻译的语音,这里选择英文-简体中文,在对选择转换格式,是否公开文件进行设置,设置好之后点击“开始翻译”即可。

三、百度翻译 其实通过百度也是可以翻译的,直接在百度里搜索就行了,然后可以将要翻译的PDF文档添加进去 虽然也能很快的进行翻译,但是翻译的语句,但是不能批量进行翻译。

如何将整篇英文word文档翻译为中文

如何将整篇英文word文档翻译为中文 小编的英语水平不好,但是工作中又要经常和英文打交道,有时碰到整个Word文档的内容都是英文的,看完真的很吃力,直到有一天小编找到了一个很好的方法,将整篇Word文档的内容都翻译为中的,小编的工作效率得到极大提高,下面小编就来给大家分享这个方法 本经验说明: 小编使用的是2013版本的office 的word,其它版本的word可能有些差异,请根据实际版本来进行操作。 方法/步骤 1.如下图所示,小编这里有一篇英文的文章,我们准备将其翻译为中文的 2.点击菜单栏中的“审核”,打开审核相关的工具栏,点击“语言”,在打开的 语言工具中我们可以看到翻译和语言工具

3.我们先要设置翻译选项,我们是将英文,翻译为中文,所以先要进行下面这些 操作 点击翻译,打开翻译菜单,之后选择“选择转换语言” 4.在打开的“翻译语言选项”中,默认的设置是将当前语言翻译为英文,所以这 是不符合我们的要求的

5.将“选择翻译屏幕提示语言”改为“中文(中国)”,将“选择文档翻译语言” 下面的语言改为“英语(美国)”,将翻译为改为“中文(中国)”,具体设置如下图所示,完成这些设置后,点击右下方的“确定”按钮 6.完成上面的设置后,再选择翻译中的“翻译文档(英语(美国)至中文(中国))”

7.点击“翻译文档(英语(美国)至中文(中国))”后,会弹出如下的联网安 全提示框,在这里不用理会,直接点击“发送”按钮 8.点击发送后,就会自动将文档的内容发送到微软的网站,并打开在线翻译的网 页,自动帮我们翻译为中文的,我们可以将网页的翻译内容复制下来保存在Word文档中,或者直接在线看

相关文档
相关文档 最新文档