《医院信息系统应用实例 检验结果共享用例.doc》由会员分享，可在线阅读，更多相关《医院信息系统应用实例 检验结果共享用例.doc（25页珍藏版）》请在三一办公上搜索。
1、检验结果共享用例LABORATORY RESULT SHARINGUSE CASESBallot Draft for TWG and SC更新记录Document History电子病历委员会用例模型工作组EHR Steering Committee Usage Model Working Group版本Version作者Author审阅者Reviewer / Role变更 / 备注Changes / Notes2007-1-19Draft 1Phenix Pu QINXUE Wanguo / UMWG Co-chairMENG Zhaobin / UMWG Co-chairPropose f
2、or TWG and SC discussion编辑体例Legend样式Style说明Description文字编辑标记名词标识特有名词或文内专有的提法或姓名删除标识准备删除但暂留在文内存储的文本工作组注释工作组注释的内容，未确定是否可作为正式发布内容。灰色表格单元工作组注释内容版权说明Copyright NotesInternal use only目录Table of Contents概述 Introduction2背景 Background2关于本文档 About This Document2范畴 Scope3该用例范畴包括 In-Scope3该用例范畴不包括 Out-Scope3情节图板
3、 Storyboard4情节故事 Stories4用例模型概述 Usage Model Brief5利益人与行为人 Stakeholders and Actors6利益人分析 Stakeholders6行为人与角色 Actors and Roles7前置条件 Preconditions8后置条件 Post-conditions9实现瓶颈 Obstacles to Implementation10患者标识 Patient Identification10医疗服务者识别 Provider Identification10鉴权和授权 Authentication and Authorization1
4、0医生责任 Physician Responsibility and Liability10公用术语服务 Common Terminology Service11详细用例 Detail of Use Case Perspectives and Scenarios12行为人和角色 Actors and Roles12患者视角 Patient Perspective12医生视角 Clinician Perspective13检验室视角 Laboratory Perpective15数据中心视角 Data Repository Perspective15定位服务视角 Locator Service
5、Perspective16概述Introduction背景Background为了在跨医疗机构范畴有效地实施医疗和相关健康服务，不同的服务提供者之间产生交换和共享患者医疗信息的需求。在医疗检验报告的方面，广泛实现检验信息系统（LIS）和电子病历系统（EHR）之间安全可靠的临床信息共享，可以为医疗服务人员提供一个高度集中的临床数据源，并在医疗服务点有效使用这些数据，而不论检验本身是在何时何地进行过的。LIS和EHR系统间的互操作，可以帮助减少医疗差错，减少消耗医疗资源和成本的冗余检验。并改善医疗卫生的服务效率。关于本文档About This Document本文档是电子病历委员会关于以上领域使用
6、期望的书面刻画，其目标是： 作为案例考察、现状研究、期望分析等一系列研究工作的总结文件。 通过情节图板，在电子病历委员会与利益人之间，建立一个非技术性的沟通工具，以说明用例的现实意义，并帮助验证利益人的（潜在）期望是否被该用例正确的捕获。 通过用例，将利益人的（潜在）期望综合为模型化的概括表述。 作为电子病历委员会用例工作组与技术工作组就领域用例模型协同工作的工具。以及作为技术委员会最终发布的互操作规范的依据。工作组注释鉴于国内大多数医疗机构相关利益人，在关于检验结果甚至其他医疗信息共享方面，由于动机和条件所限，尚少有明确的直接需求。本文档所描述的检验结果共享情节和用例，将不仅仅反映现实的状况
7、和直接需求，而一并包含基本符合利益人期望的潜在需求。这种用例刻画工作的可接受程度，将通过本文档同各种利益人作更长期的验证，并在以后的版本中反映这种变化。工作组注释本文档参考HITSP在2006年3月的提供的Harmonized EHR - Lab Use Case Version 1.0文件以及8月的互操作规范中相关的部分。情节图板和分析部分与参考文件不同，用例的结构类似，但其中详细事件和动作的说明条目根据国内的情况和前期的调查研究而有所区别。范畴Scope该用例范畴包括In-Scope在不同的医疗服务提供者（及其信息系统）之间交换和共享检验报告，并满足以下基本要求。 可及性（accessib
8、ility）。一个系统可以访问获取另一个系统的信息。 可管理性（manageability）。共享的行为和策略可以在运行中进行配置和管理。 安全性（security）。原来的信息不会因共享本身到其他系统（期间和之后）而降低其安全性或泄露利益人隐私。该用例范畴不包括Out-Scope本用例在此明确排除以下内容： 检验报告的产生order。关于原始检验报告如何被产生。 转诊referral。关于患者在不同医疗服务者之间转诊本身的业务流程。 付费payment。关于付费内容的细节。 专有性exclusiveness。因采用某种技术或者产品而带来的附加限制。情节图板 Storyboard本节以“情节故
9、事”（story, vignette）描述用例在现实中成功执行的案例，套用医疗实际情境。目的在于独立于技术标准之外，完整而浅显地说明本用例的范畴、假设条件、实现的意图、功能以及主要角色等，并提供一个应用讨论的基础和形式。情节故事不追求用例的完备性，而重在形象地表达。根据情节故事的基本要点，本节将概括出用例模型的主要内容。情节故事Stories以下情节故事是参考现实和利益人潜在期望的虚构内容用于反映符合利益人认可的潜在期望，以及用例的要点内容。故事1 方医生从社康管理中心取得患者唐女士的血糖检验结果情节1.1 某市某小区居民，唐娣霞女士，57岁，退休。情节1.2 唐女士患有II型糖尿病，她的社区
10、卫生健康服务站为她提供了慢性病管理服务，那里的全科医生陈其康大夫一直在定期监测她的血糖指标，并每次将测量的血糖指标和其他一些的化验结果上传存储到在城区社康管理中心的居民健康档案系统中。情节1.3 唐女士最近时常有发烧、痰血、胸闷症状。星期三上午，唐女士到市人民医院看门诊，医院的方进安大夫让唐女士做了痰样化验等检查，发现抗酸杆菌阳性，并根据其他一些临床症状，初步诊断为结核病。在了解到唐女士的糖尿病情况以及在社区参加的慢病管理计划后，方大夫认为很有必要参考一下唐女士近期的血糖变化情况，以进一步诊断是否是糖尿病合并肺结核。情节1.4 方大夫用医生编号和密码登录自己计算机上的人民医院门诊患者电子病历系
11、统，调出了挂号时登记好的记录，唐女士的一些基本信息，包括姓名、身份证号、退休统筹医保号等等。方大夫点选了其中“查询社区居民健康信息”的功能页，在查询表格里面选中了今日门诊患者之一的唐女士，接着询问她家的街道名称等一些其他信息，按下查询按钮后过了一会儿系统显示“找到1条登记记录”，唐女士的名字显示了出来，不过不能查看细节。情节1.5 方大夫向唐女士解释了人民医院是城区社康管理中心的认可合作医院，他要在通过他的系统在管理中心查询是否有唐女士最近的血糖监测检验结果，以便诊断参考。唐女士表示同意，并在方大夫的计算机查询页的病人授权密码处输入了自己在社康站设置的查询密码。提交后，方大夫可以看到唐女士最近
12、的慢病管理计划了，其中列出了多个检验种类和项目。情节1.6 方大夫选中了最近三个月的血糖监测指标检验结果，点击系统上的“导入门诊患者电子病历”选项，系统显示“正在连接数据中心，请稍候”，过了一会儿接着显示“连接成功，正在下载”。几秒钟后，方大夫就在自己电脑上的电子病历系统中看到了所需的检验结果。用例模型概述Usage Model Brief本文档所指的“检验结果共享”用例概述如下：一个医疗服务的提供者或者医学研究者（请求者）希望获得自己的病历系统里所没有，但与医疗服务的接受者（患者）相关的检验数据。检验请求者通过查询一个查找定位服务（可能是直接询问患者本人或者通过某种服务查找），找到相关检验结
13、果内容的所在地或拥有者（应答者、数据中心）。请求者与之建立联络，并将自己标识为合法的请求者。检验结果的请求者与应答者就患者的身份协商达成一致（确保双方谈论的是正确的患者）。请求方说明所需的检验结果，应答方找到所需的内容数据。在患者（或其代理）的授权之下，应答者发放这些检验结果数据给请求方。双方验证数据已经被正确传输，并对这次交易进行记录。利益人与行为人Stakeholders and Actors利益人（stakeholder）指期望该用例成功完成的人或其他实体。行为人（actor）指直接参与用例的人或其他实体。利益人分析Stakeholders利益人不一定会直接参与用例的运作，但是其期望会影
14、响用例的模式和实现，例如监管机构，认证系统等等。有的利益人不参与用例，即不是行为人。但所有的行为人显然都是利益人。如下表 表格中的灰色单元格保留给EHRSC内部讨论使用，一般为草稿内容或者用于举例的内容。灰色单元格内的内容不在最终对外的发布文件中出现。利益人Stakeholder直接角色Direct Role利益或期望Stakeholders Interest利益人举例Example1一般大众患者，定位者改善医疗服务质量社区居民2直接医务人员请求者，应答者改善个人业务效率全科医生3临床研究人员请求者更方便地获取研究所需数据，更好的数据质量医学院4公共卫生机构请求者更方便地获取公共卫生监测所需的
15、数据疾控中心5医务监管政府机构无改善医院的医疗服务质量和效率，不违反现行法律法规和监管条例医政司6付费机构无降低医疗服务费用社保局7电子病历系统厂商无增强产品功能，提高客户满意度社康工作站软件开发商8检验室应答者改善医疗服务质量社康站9标准开发组织无标准被采纳，获取实践需求电子病历委员会10区域医疗信息组织定位者增加覆盖用户数量11医院系统请求者，应答者改善医疗服务质量和效率301医院HIS系统12集成医疗卫生服务系统请求者，应答者，定位者改善医疗服务质量和效率，降低费用某市区卫生信息网13病案保管单位应答者减轻工作负荷医院病案14医生目录组织定位者改善医疗服务质量，减少医疗差错和投诉”导医网
16、“15消费者组织无改善医疗服务质量”导医网“ ”爱康网“16交易组织无改善工作环境中国无明显此项？17循证医学组织无严格检验结果中国无明显此项？18案件管理员（Case Manager）请求者改善个人业务效率中国无明显此项？行为人与角色Actors and Roles用例中直接使用的行为人列表见“详细用例”。前置条件Preconditions本文假设以下内容在该用例之前以下条件已经全部具备：针对角什么色To which roles假设（前置条件）Assumption (Preconditions)国内现状满足难度Hardness to Satisfy in China1请求者，应答者网络基础设
17、施条件（连通性、带宽性能等）对该用例足够。易/Easy2请求者，应答者存在”公共术语服务“，该服务能满足以下条件： 可以从一个或者多个”术语库“，或称”受控词汇表“中获取确定词汇的代码。这样的术语库诸如LOINC, ICD10, SNOMED CT, ICPC 等国际、全国或地区的标准领域术语库。这些代码将用于标识每个检验中用到的各种术语名称，以确定要传输的数据是关于什么的。 可以在多个受控词汇表中之间映射词汇。当传输收发方使用不同词汇表时，词汇将被该服务进行等义转换。难/Hard3请求者，应答者，定位者（非患者或患者代理）所有医疗卫生人员拥有各自行业的合法执业资格，这些资格已经使其具备最基本
18、的合法（指监管）操作条件。中等/Mid4请求者，应答者，定位者（非患者或患者代理）所有系统已经具备病毒及恶意软件保护，与此类性质相同的软件安全问题不在本用例描述范围之内。易/Mid5请求者，应答者，定位者（非患者或患者代理）可以得到医疗服务者的信息，包括足够的标识数据和验证机制。中等/Mid6应答者在用例开始时，需要传输的数据已经以某种电子媒体保存，并可以被应答者获得。这些数据包括但不限于检验结果和解释，患者标识和医疗服务者标识等信息。中等/Mid7应答者应答者已经知道哪些数据是允许发出的。易/Easy8应答者检验结果唯一地关联于一个可标识的个体（患者，其本身的标识也是唯一的）。在用例开始时，
19、 这个唯一标识的个体连同其检验结果一起存在于应答者的电子病历系统和或检验信息系统中。中等/Mid9所有角色所有参与角色已经被正确地授权。易/Easy工作组注释依据国内现状，并不是所有的前置条件都可以直接实现。但本用例试图将焦点放在“当这些条件具备之后，可能的共享情形是什么”，因此后面的用例部分将假设所有这些条件已经被满足。为便于讨论，对于每一项前置条件，根据国情评估一个一般性的难易程度。在各个地区现实和试点项目中，前置条件的难易程度将可能不同。后置条件Post-conditions本文假设以下内容在该用例结束之后将会发生： 请求者收到所请求的电子检验结果，可能将用于临床决策。 检验结果可及时地
20、用于临床医疗。 检验结果被存储于请求者的患者病历中。 请求者“退出”：获得数据以后，请求者不再留在应答者系统的“会话”中，也即在该用例中，只考虑该系统支持逐个交易“会话”模式的情况，不考虑请求者持续地“登录在”应答者系统中的情况。 交易被某系统记录：某一系统（或多个系统）会保存一份关于这次数据传输交易过程的记录。 系统有效性反馈循环：检验结果被查询和访问以后，系统跟踪这些结果使用的有效性和使用效率，例如系统对患者及其检验结果的定位频率（能力）。实现瓶颈Obstacles to Implementation患者标识Patient Identification对于请求者和应答者，检验记录是否都能够
21、被正确地关联到正确的患者身上。当没有全国（或大范围地区）统一的病人标识卡时，这一问题尤为突出。对于每个人群组织（以及存放他们的记录的系统），标识和匹配个体信息的策略有可能不同，各种标识手段的特性和质量也不同。患者标识条件的局限性，可能会导致该用例跨系统和跨组织实现的可能，即被束缚在某一可清晰标识个体的组织（地区）内部。工作组注释在北京市东城区项目中，居民通过项目发放的“社区健康卡”来充当这种标识符。在深圳市福田区社康站，居民则通过社康站预先登记在系统中的信息以及一般身份证件来标识患者。医疗服务者识别Provider Identification类似患者标识，医疗服务者本身也将涉及到身份标识的问
22、题。但具体实现可能和患者识别的注册体系和鉴别方式会有所不同。对于双方医疗服务者同属于一个组织的情况（如社区医院医生是检验所在医院的派出医生），这一问题将相对简化。鉴权和授权Authentication and Authorization鉴权（Authentication）指确定参与会话并标识自己的医疗服务者确实是其本人而不是别人误用或伪装。授权（Authorization）指确定参与会话的行为人拥有访问指定数据的权利。关于参与用例的各个行为人，有以下几种情况： 鉴别请求检验数据的医疗服务者并确定其有权得到数据位置信息。 患者授权检验室发放自己的检验数据给当前的医疗服务者。 共享双方确定是否讨论
23、的确实是同一个患者（综合鉴权、授权及上文患者标识问题）。医生责任Physician Responsibility and Liability请求者作为医疗服务的提供者，访问并取得另一个医疗服务提供者（应答方）关于其患者的检验结果并可能用于临床参考。其中如何界定和跟踪双方医生的医疗责任、患者隐私保护责任，仍需要进一步的讨论。公用术语服务Common Terminology Service共享双方可能是在不同组织、不同系统甚至不同领域之间交换检验数据。为了解读数据的语义并保证双方在语义的沟通上取得一致，将需要一个双方公共的词汇表（包括领域通用术语表和各自本地的其他代码含义表）。当双方的词汇表不同时
24、，还需要有一个词汇表映射和转换的机制。可能有几种不同的情况： 双方同属一个组织，使用完全相同的词汇表和语汇。 双方使用不同的词汇表，但拥有和掌握对方的词汇表和解读方式。 双方使用一个公用的术语服务来进行领域术语的映射翻译，并在术语服务上维护自己的代码表，以保持和其他术语映射。详细用例 Detail of Use Case Perspectives and Scenarios行为人和角色Actors and Roles编号行为人交互角色描述1.1患者患者或患者代理。1.2医生请求者可能是人、组织或者系统。代表正在对患者施治的医生。更进一步，医生可以划分为发出查询检验结果请求的“请求方医生”和直接
25、对患者施治的“责任医生”，责任医生可以从定位服务被动地接收“新检验结果可用”的通知。1.3检验室生成检验结果。拥有检验科室的诊所或医院也可以充当这一角色。1.4数据中心应答者存储检验室产生的检验结果数据实体，在收到请求时负责向授权的医生提供共享的检验结果数据。可能也会存储其他数据。1.5定位服务定位者索引所有检验结果数据的位置信息，负责检验结果的查询。工作组注释 很多关于该用例的实现都会倾向于把数据中心和定位服务融为一体，或者从属与同一个组织。 其他利益人有可能拥有定位服务和数据中心的功能，包括患者本人和共享的信息机构。 检验结果数据共享之后，其语义的解读可能有赖于公共的术语服务机制。患者视角
26、Patient Perspective编号描述（x.x.x.0 项为事件，其他为动作）说明1.1.1.0提供患者身份标识提供患者个人的标识信息，并在必要时进行更新。1.1.1.1提供标识数据例如，患者（或者其代理如家属）告诉医生患者的姓名、身份证号码、住址、社康卡号、统筹医疗卡号等身份信息。1.1.2.0列出可能的检验医疗服务者患者提供（如向医生说明）为自己提供医疗服务的服务者名录，并在必要时更新。该列表可以帮助指出最初的检验结果可以在何处查询，例如确定是在什么医院进行的检验。1.1.2.1提供接受过服务的医疗单位和服务者列表医疗服务者列表可能来自患者提供的就医医院列表，或本人的所有看病记录中
27、的医疗服务者名单，或自己参加的其他卫生保健相关的服务者列表。如所属在什么社区的诊所、最近看病的医院和科室医生、自己单位所参加的医保医院、社会保障大病统筹的定点医院等等。医生视角Clinician Perspective编号描述（x.x.x.0 项为事件，其他为动作）说明1.2.1.0在本地电子病历系统中查看检验结果本事件用于医生在自己的医生工作站端电子病历上查询和接收患者的检验结果数据并整合到本地的患者电子病历中。1.2.1.1接收检验结果接收检验结果。接收完成时，可能直接发送到请求医生的电子病历系统中（本地的或者远程的），而不再进行中间请求。1.2.1.2检查接收数据的完整性接收完成后，电子
28、病历系统确认确认所接收的数据是完整并未经非法更改的。1.2.1.4合并数据到电子病历集成检验结果数据到电子病历系统中。电子病历系统中关于一个患者的电子病历聚合了来源于多个数据源的医疗数据。接收到的检验结果数据经过处理后，与正确的患者相关联。当检验结果不能正确地匹配到患者时，应生成一个异常列表供人工解决。1.2.1.4a异常：数据不完整，请求重新接收1.2.1.5标记新的检验结果电子病历系统用清晰的标识标出新的检验结果，以便请求方医生查看。1.2.1.6确认数据已接收请求方向应答方的检验数据仓库发回一条确认消息，表示检验结果已经接收并处理，并指出所有没有无法被接收或处理的检验结果。1.2.2.0
29、查询共享的历史检验结果医生通过定位服务查询患者以往的检验结果数据。1.2.2.1发送请求者自身验证信息请求者发送能够表明自身真实性的验证信息。1.2.2.2验证确认患者身份请求方医生和定位服务系统必须确定他们所讨论的是同一个患者。为此进行患者标识的验证。患者标识可能有多种方式进行验证。有的定位服务可能会使用特征信息（姓名、生日、性别等）组合来进行查询并列出命中的结果以便请求者可以查看确认，这种组合可以是在区域范围内预先定义好的一组规则。更好的情况是，请求者和定位服务系统之间能够共用一套患者标识符，这样患者身份可以直接通过该标识符确定。这种情况的一个例子是：人民医院的患者管理系统，而请求查询的医
30、生是这家医院的派出驻社区医生，能够预先知道其使用的病案编号。另一个例子是，在整个城市或者辖区使用的社康卡号、社保号等。1.2.2.2a异常：请求者验证失败，查询结束请求者未能通过鉴权和查询登录授权。1.2.2.3查询检验项目请求方医生在定位服务上查找患者先前做过的检验项目记录（非检验结果内容），或者通过检验报告的编号请求获得检验结果。这一查询可能通过登录在定位服务所提供的浏览查询界面来进行，也可能通过请求者自己的电子病历系统向定位服务发出的请求表单来进行。1.2.2.3a异常：患者身份无法识别，查询结束可能由于该定位服务上没有该患者的索引资料，或者由于换镇身份匹配不正确。1.2.2.3b异常：
31、请求者无权查看该患者资料，查询结束由于患者隐私设置或者存储患者检验结果的数据中心的设置。请求者不具备查看患者资料的权限。1.2.2.4接收共享检验结果的存储位置信息请求者从定为服务得到关于所选检验的存储位置（例如链接或者引用信息）。请求者将从这一位置访问检验结果内容的存储数据源，即数据中心。1.2.2.4a异常：无可用的检验结果。查询结束1.2.2.5记录本次查询请求者记录使用定位服务进行查询的本次交互。1.2.3.0在远端系统上浏览检验结果本事件用于没有本地电子病历系统的医生在其他远端系统上查看患者的检验结果。1.2.3.1向数据中心发送查询请求向远端的数据中心发送查询请求。1.2.3.2发
32、送请求自身验证信息验证请求者自身的身份。此时请求者可能是医生本人（如直接在远端Web程序上登录），也可能是其组织（如诊所或医院）或者其计算机系统（如医生工作站）。1.2.3.3验证确认患者身份1.2.3.3a异常：请求者验证失败，查询结束1.2.3.3b异常：请求者无权查看该患者资料，查询结束由于患者隐私设置或其他授权设置，请求者不具备查看患者资料的权限。1.2.3.4查看检验结果内容异常：患者身份无法识别，查询结束可能由于该数据中心上没有存储该患者的资料，或者由于换镇身份匹配不正确。1.2.3.5接收共享检验结果包括远端查看、打印或接收存储到本地系统上。1.2.3.5a异常：无可用的检验结果
33、。查询结束1.2.3.6记录本次查询检验室视角Laboratory Perpective编号描述（x.x.x.0 项为事件，其他为动作）说明1.3.1.0处理检验单生成检验结果报告，并把检验结果数据发送到数据中心，以供其他医疗服务者请求共享之用。1.3.1.1生成检验结果生成过程的细节在本用例之外。1.3.2.0发送检验结果到数据中心数据中心可能和检验室在一起（检验科自己的LIS系统），也可能是其他部门（医院数据中心）或者其他组织的系统（独立的检验数据中心或临床数据仓库）。1.3.2.1记录检验结果处理情况数据中心视角Data Repository Perspective编号描述（x.x.x.
34、0 项为事件，其他为动作）说明1.4.1.0存储检验结果1.4.1.1从检验室接收新的检验结果检验结果的内容数据，关于患者的标识数据、隐私设置等元数据。1.4.1.2验证检验室身份以及检验数据验证是否检验室正确地标识了自己，验证所接收数据的完整性1.4.1.3确认检验结果已接收1.4.1.4存储检验结果存储检验结果数据，并标记所有使用限制信息（如授权的医疗服务者列表、患者授权和隐私设置等）。1.4.1.5记录新检验结果的接收和存储1.4.2.0通知定位服务关于新的检验结果1.4.2.1向定位服务验证检验室身份1.4.2.2发送检验结果数据位置和其他元数据包括患者的标识信息以及附加的准用条件信息
35、（如果有的话）。1.4.2.2a异常：验证失败。通知失败1.4.2.3记录本次交互1.4.3.0处理检验结果共享请求1.4.3.1接收并验证共享请求解析、验证并确认数据查询请求。1.4.3.2验证请求者身份可能包括请求者的身份验证信息，具有相关授权访问的证明信息。1.4.3.2a异常：共享请求不正确。通知请求者更正并重新发送请求共享请求的格式不正确等原因。1.4.3.2b异常：数据已不存在。共享失败并通知请求者和定位服务如果确定请求者是通过定位服务找到的该位置信息，说明定位服务的该信息未能及时更新。此时数据中心将告知请求者数据不存在，并通知数据中心更新位置信息。1.4.3.3授权检验结果发放根
36、据请求者的授权信息，准许请求者访问检验数据内容。1.4.3.3a异常：请求者权限不足。共享失败并通知请求者1.4.3.4传输检验结果传输方式取决于请求者是否具有电子病历系统，可能的方式包括将数据发送给请求者以供电子病历集成，或发送给其他信息系统（包括数据中心端的查看系统）直接供请求者浏览查看。1.4.3.4a异常：授权未通过。共享失败并通知请求者1.4.3.5记录本次交互定位服务视角Locator Service Perspective编号描述（x.x.x.0 项为事件，其他为动作）说明1.5.1.0发布检验结果位置信息1.5.1.1接收更新的检验结果数据位置信息接收来自检验室生成或更新的检验
37、结果数据及其位置信息。1.5.1.2检查位置信息及数据完整性检查位置信息是否准确，数据格式是否完备正确。1.5.1.3索引检验结果根据患者或其他分类方式进行索引。1.5.2.0处理位置查询请求1.5.2.1验证发出查询请求的医生身份对应1.2.2.1。1.5.2.2验证确认患者身份对应1.2.2.2。1.5.2.2a异常：请求者验证失败，查询结束请求者未能通过鉴权和查询登录授权。对应1.2.2.2a。1.5.2.3处理关于检验项目的查询对应1.2.2.3。1.5.2.3a异常：患者身份无法识别，查询结束可能由于该定位服务上没有该患者的索引资料，或者由于换镇身份匹配不正确。对应1.2.2.3a。1.5.2.3b异常：请求者无权查看该患者资料，查询结束由于患者隐私设置或者存储患者检验结果的数据中心的设置。请求者不具备查看患者资料的权限。对应1.2.2.3b。1.5.2.4授权检验结果位置信息发放1.5.2.4a异常：请求者权限不足。共享失败并通知请求者1.5.2.5发送检验结果位置信息提供请求这指向检验结果数据源的引用或链接信息。1.5.2.5a异常：无可用的检验结果。查询结束1.5.2.6记录本次查询交互
