提供转介服务的方法、装置、系统和计算机可读介质的制作方法
【专利摘要】本发明披露了一种提供医学会诊的系统，包括第一装置和第二装置。所述第一装置接收优先级的选择和从可用的会诊者列表选择的至少一名会诊者(基于信息的优先级和会诊者的有空状态实时获得)并生成会诊信息，所述会诊信息包括患者的元数据、接收到的优先级、和接收到的选定的会诊者的身份。第一装置根据传送的会诊信息接收解释信息。第二装置分析会诊信息，其中根据所执行的事件识别可用的建议并生成解释信息，所述解释信息包括从由会诊者识别的可用建议选项选择的建议。根据设置的优先级和会诊者的当前有空状态实时从存储的多个会诊者生成可用的会诊者列表。
【专利说明】提供转介服务的方法、装置、系统和计算机可读介质
相关申请的交叉引用
[0001]本申请依据35U.S.C.§ 120要求申请日为2012年4月27日的美国临时申请N0.61/639，613的优先权,其发明名称为“Referral System and Method”,该专利文献的内容在此以其全文形式被援弓I加入本文。
【背景技术】
1.
【技术领域】
[0002]与示例性实施例一致的方法、装置、系统和计算机可读介质大体上涉及提供会诊服务/审阅服务，并且更具体的说由会诊者/审阅者提供早期诊断。
2.【背景技术】
[0003]在【背景技术】中，个人到验光师、医生和/或牙医处作定期检查。在这些就诊期间，可能会发现问题或不确定因素，需要专科医生/专家的会诊/审阅。在【背景技术】中，医生然后会转诊给所需的专科医生。患者随后会找到专科医生或接触由主治医生建议的专科医生。患者随后会与专科医生预约(由于专科医生繁忙的日程安排可能需要很长的时间)，向专科医生告知转诊，并去会诊。这个过程是耗时的、昂贵的、低效的，并且去拜访专科医生的办公室可能花时较长并且也是种负担。因此，患者经常可能不跟进专科医生，除非存在实际的问题或有伤。
[0004]例如，有人可能患有糖尿病。糖尿病患者同时可能有眼睛方面的问题并不罕见。因此，医生可能建议患有糖尿病的患者去看视网膜专科医生，以确定是否确实存在眼睛方面的问题。不过，如果患者没有遭受任何急性眼睛方面的问题，他或她可能由于上述问题而决定不去看专科医生，疾病可能无法诊断和治疗。
[0005]近2600万美国人患有糖尿病，并且7900万美国人有前期糖尿病。大约45_65%被诊断患有糖尿病的患者并不每年进行眼科检查。80%的糖尿病患者最终发展成视网膜病，这是美国引起失明的第一原因。因此，在不需负担冗长的转诊过程或患者不遵医嘱的情况下，需要提供积极的护理/治疗并对这些病人尽早治疗，以避免失明。
[0006]另外，估计糖尿病人数到2050年会翻倍，而视网膜专科医生的数量到2050年估计仅增3%。因此，可用的专科医生的数量与患者的数量之间的缺口会增长，导致看专科医生会出现甚至更长的等待时间。
[0007]如上文所解释的，在目前的医疗体系中转介/转诊的过程大部分是基于书面预约的。转诊医生填写书面转诊表，包括任何他们认为可能对于专科医生有帮助的发现(检查结果)/说明。转诊医生的办公室人员随后会将转诊书面资料传真给专科医生的办公室人员，通常并不确认专科医生的办公室是否成功地收到了转诊资料。转诊单包含专科医生办公室信息，包括患者预约电话号码，然后给患者。患者有义务联系专科医生办公室并预约看诊。一旦患者打电话给专科医生办公室并证实专科医生已收到了正式的转诊表并且接受转诊，则专科医生看诊预约成功。患者随后会去请专科医生看诊，并证实转诊医生不确定的具体情况。
[0008]目前对于专科医生存在三种情形。
[0009]第一种情形:看了转诊医生识别并发出的转诊单的具体情况，并证实了专属于专科医生专业的疾病状况。随后由专科医生来治疗疾病，患者获得了对该疾病的护理。专科医生随后能够对专属于他们的专业服务开具帐单。希望这种情况是最为普遍的。
[0010]第二种情形:情况未被核实，没有涉及专科医生专业的具体疾病状况被证实，患者回到转诊医生处。专科医生在专科医生特定文档中记录检查结果，并且专科医生办公室人员将检查结果回传到转诊医生办公室。就此，患者随后被通知回到转诊医生处，并且患者现在回到了转诊医生处。专科医生对简单的检查开具帐单，给患者带来了不便，并且还增加了潜在的不必要的医疗费用。这第二种情形显然不富有成效并对医生和患者来说导致浪费了时间、精力和额外费用。不幸的是，这种情形的发生率取决于转诊医生的专业技能(随专业技能而变化)以及专科医生的能力，以便对医生设定期望值和尽职调查要求，试图确保这种情形不发生。在本领域需要试图避免第二种情形或使第二种情形降至最低。
[0011]第三种情形:疾病处于晚期，与若在早期诊断出疾病状况相比，使得目前需要更为积极的治疗方案。第三种情形也应该被避免或降到最低。
[0012]在【背景技术】中，可能存在另一问题，因为一般的医生担心失去患者而不想将患者转诊给专科医生。例如，验光师可能看到患者的视力检查并检测到视网膜的问题。验光师可能试图自己来解决这问题，而不是将患者转诊到专科医生例如眼科医生，因为担心失去患者。也就是说，患者可能与眼科医生建立关系并到眼科医生那里进行年检而不是去验光师那里。
[0013]在当今的技术时代，许多系统现在是电子的并在金融业、营销业、汽车工业等在线可用。由于各种隐私问题和HIPAA法规，将目前的技术应用到医学领域具挑战性。
[0014]在本领域需要解决上述问题并提供更为有效的专科医生服务。
【发明内容】
[0015]通过阅读本文的示例性实施例的说明会变得显而易见，本发明的一个方面提供一种系统，通过便于专科医生解读和会诊/审阅来克服上述问题。
[0016]本发明的一个方面提供自动化电子系统，其中向转诊医生提供及时的电子会诊/审阅，而非与患者直接交互。
[0017]本发明的一个方面在主治医生和专科医生之间提供完美衔接地和前后一致地，也许甚至持续不断的交互。
[0018]本发明的一个方面通过由专科医生进行远程转诊前的会诊/审阅以确定是否有必要与专科医生预约，使上述第二种情形的发生降到最低。
[0019]说明性的而非限制性的实施例可克服上述缺陷以及现有技术的问题，并且也可被开发用于对上文未提及的其它缺点和问题提供解决方案。不过，根据本发明的教导运行的方法、装置、系统和计算机可读介质不必然需要克服任何上述的特定问题或缺陷。应当理解，一个或多个示例性实施例并不要求克服上述的缺点，并且可能不克服任何上述的问题。
[0020]根据一个示例性实施例，本发明披露了一种方法、系统、装置，包括存储器和处理器和非暂时性计算机可读介质，用于提供医学会诊/审阅(review)。
[0021]根据示例性实施例的一个方面，一种方法包括:由用户从可用的会诊者/审阅者(reviewer)名单中选择至少一位会诊者/审阅者；设置答复的优先级；由计算机生成会诊信息/审阅信息，包括患者的元数据(由在患者方面执行的多个事件获得)、设置的优先级、和所选定的会诊者/审阅者的身份；通过有保障的网络传送所生成的会诊/审阅信息(review message);和,根据所传送的会诊信息/审阅信息通过有保障的网络接收解释信息(interpretat1n message)。可用的会诊者/审阅者名单基于设置的优先级和当前可用的会诊者/审阅者实时生成。
[0022]根据另一示例性实施例，一种提供医学会诊/审阅的方法包括:接收会诊/审阅信息，所述会诊/审阅信息包括患者的元数据(包含在患者方面执行的多个事件)、优先级和至少一个会诊者/审阅者的身份；由计算机分析会诊/审阅信息，其中根据所执行的事件识别可用的建议；生成解释信息，包括从由会诊者/审阅者识别的可用的建议选项选择的建议；和，通过网络传送生成的解释信息。
[0023]根据示例性实施例的另一方面，生成会诊/审阅信息的装置包括:存储多个会诊者/审阅者的存储器；通信界面，所述通信界面被设置成接收从可用的会诊者/审阅者列表中选择的至少一个会诊者/审阅者和由用户选择的答复的优先级；和，处理器，所述处理器被设置成生成会诊信息/审阅信息，所述会诊信息/审阅信息包括患者的元数据(通过在患者方面执行的多个事件获得)、接收到的优先级、和接收到的选定的会诊者/审阅者的身份。通信界面通过有保障的网络传送生成的会诊信息/审阅信息并且根据所传送的会诊信息/审阅信息通过有保障的网络接收解释信息。可用的会诊者/审阅者列表基于设置的优先级和当前可用的会诊者/审阅者从所存储的多个会诊者/审阅者实时生成。
[0024]根据示例性实施例的另一方面，本发明披露了一种提供医学会诊/审阅的装置，包括:通信界面，所述通信界面被设置成接收会诊/审阅信息，所述会诊信息/审阅信息包括患者的元数据(包含在患者方面执行的多个事件)、优先级、和至少一个会诊者/审阅者的身份；处理器，所述处理器被设置成分析会诊信息/审阅信息，其中根据所执行的事件识别可用的建议，并被设置成生成解释信息，所述解释信息包括从由会诊者/审阅者确定/识别的可用的建议选项中选择的建议。通信界面可通过网络传送生成的解释信息。
[0025]根据示例性实施例的另一方面，本发明披露了一种提供医学会诊/审阅的系统，包括:第一装置，所述第一装置用于生成医学会诊/审阅信息；和，第二装置。第一装置包括:第一通信界面，所述第一通信界面被设置成接收从可用的会诊者/审阅者列表中选择的至少一个会诊者/审阅者和由用户选定的答复的优先级，被设置成通过有保障的网络传送会诊信息/审阅信息并通过有保障的网络基于所传送的会诊信息/审阅信息接收解释信息，并且第一处理器被设置成生成会诊信息/审阅信息，所述会诊信息/审阅信息包括患者的元数据(通过在患者方面执行的多个事件获得)、所接收到的优先级、和接收到的选定的会诊者/审阅者的身份。第二装置包括第二通信界面，所述第二通信界面被设置成接收来自第一装置的会诊信息/审阅信息并通过有保障的网络传送解释信息来响应会诊信息/审阅信息；和，第二处理器，所述第二处理器被设置成分析会诊信息/审阅信息，其中根据所执行的事件识别可用的建议，并被设置成生成解释信息，所述解释信息包括从由会诊者/审阅者确定/识别的可用建议选项中选择的建议。可用的会诊者/审阅者列表可从所存储的多个会诊者/审阅者基于设置的优先级和当前可用的会诊者/审阅者实时生成。
【专利附图】
【附图说明】
[0026]被结合入说明书并构成说明书一部分的附图例示了示例性实施例，并同说明书一起用于说明和阐述示例性实施例。具体地说:
[0027]图1是框图，示出了根据示例性实施例的用于提供医学会诊/医学审阅的系统。
[0028]图2是流程图，示出了根据示例性实施例利用？觀系统获得会诊/审阅的方法。
[0029]图3是框图，示出了根据示例性实施例的会诊系统/审阅系统的组成部分。
[0030]图4是框图，示出了根据示例性实施例的会诊系统/审阅系统的各层。
[0031]图5的视图示出了根据示例性实施例的眼科会诊/审阅系统。
[0032]图6是流程图，示出了根据示例性实施例生成新的会诊信息/审阅信息的方法。
[0033]图7八-70的视图示出了根据示例性实施例用于生成新的转诊/转介信息的示例患者信息输入屏。
[0034]图8的视图示出了根据示例性实施例为会诊信息/审阅信息设置优先级。
[0035]图9是流程图，示出了根据示例性实施例生成可用的专科医生列表的方法。
[0036]图10的视图示出了根据示例性实施例选择专科医生的方法。
[0037]图114-110的视图示出了根据示例性实施例用于输入转诊/转介相关信息的用户界面。
[0038]图12的视图示出了根据示例性实施例在？觀系统中生成的会诊信息/审阅信息的用户界面。
[0039]图13八和8的视图示出了根据示例性实施例用于管理会诊信息/审阅信息的用户界面。
[0040]图14的视图示出了根据示例性实施例用于设置专科医生状态的用户界面。
[0041]图15是流程图，示出了根据示例性实施例的解释会诊信息/审阅信息的方法。
[0042]图16的视图示出了根据示例性实施例专科医生分析会诊信息/审阅信息的用户界面。
[0043]图17是流程图，示出了根据示例性实施例获得可能的诊断结果的方法。
[0044]图184-180的视图示出了根据示例性实施例选择至少一个建议的用户界面。
[0045]图19是流程图，示出了根据示例性实施例生成解释信函的方法。
[0046]图20的视图示出了根据示例性实施例的生成的解释信函。
【具体实施方式】
[0047]现在将结合附图详细描述示例性实施例。示例性实施例可以通过多种不同的形式体现，并且不应被视为受限于本文所述的说明性示例实施例。而是，本发明所提供的示例性实施例使得本发明的公开内容是充分和全面的，并且将说明性构思完全传达给本领域技术人员。另，可能省略了已知的功能或结构，以便清楚简洁地说明示例性实施例。应参照权利要求及其等同物以确定本发明构思的真实范围。
[0048]在一个示例性实施例中，披露了一种新的电子系统，其允许实时远程会诊/审阅(1-6^16^)。在一个示例性实施例中，转诊丨转介用户例如主治医生可利用在线系统请求专科医生的服务。示例性实施例提供了基于兼容的云的诊断转诊网络，其中转介人/转诊人可实时获得专科医生的专家意见，并可避免与专科医生非必要的预约。在一个示例性实施例中，转诊前在线会诊/审阅通过确定是否确实需要实际转诊/转介可节约时间和费用。主治医生可获得专科医生的建议，而不需担心失去患者，并且也不需使患者遭受冗长的转诊过程，除非真的有必要(避免【背景技术】中所述的第二种情形)。
[0049]在一个示例性实施例中，早期会诊/审阅还会避免疾病的发展并能够更早地检测到疾病。因此，避免了第三种情形。
[0050]图1是框图，示出了根据示例性实施例用于提供医学会诊/医学审阅的系统。
[0051]示例性系统包括一个或多个用户装置100a-100n。用户装置10a-1OOn可由转诊/转介实体例如主治医生或其他需要专科医生进行会诊/审阅的医务人员使用。医疗领域的技术人员会理解，转诊实体/转介实体根据所提供的信息发出转诊前核实。转诊前核实可用于确定是否确实需要转诊给专科医生，如下文所述。专科医生解读转诊实体的检查结果，以帮助转诊实体确定是否需要转诊。在一个示例性实施例中，专科医生会诊/审阅转诊实体的检查结果并确定是否需要与专科医生预约进行医疗诊断。在一个示例性实施例中，专科医生确认或拒绝转诊实体的发现/检查结果(findings)。
[0052]转诊实体/转介实体利用用户装置例如用户装置10a-1OOn生成会诊信息/审阅信息(将在下文进一步详细描述)。例如，用户装置可以是计算机，例如个人计算机100a、便携式电脑、平板电脑和/或笔记本电脑100b、电话10c例如LAN线电话、移动终端例如智能手机，和IPTV 10d例如具有机顶盒(STB)的TV。用户装置可具有外围设备，例如显示器(例如，阴极射线管(CRT)、等离子体显示器、或液晶显示器(LCD))、鼠标、键盘、遥控、数据源，等等。
[0053]示例性系统还包括类似的装置300a...300η。这些装置类似于上述的用户装置10a-1OOn,因此省略了细节描述。这些装置300a...300η为会诊实体/审阅实体即专科医生而设置。会诊/审阅实体分析会诊/审阅信息并根据会诊/审阅信息提供他们的会诊意见/解读/专家意见，这将在下文详细描述。
[0054]示例性医学会诊/审阅系统还可包括一个或多个后端服务器200a_200n，可被分布在云环境中。这些后端服务器200a-200n可与客户端装置10a-1OOn和300a_300n交互以生成会诊/审阅信息，以便生成解释信息并管理会诊/审阅的流程。根据一个示例性实施例，后端服务器200a-200n可形成医生转诊网络(PRN)系统。
[0055]示例性用户装置100a-100n、300a-300n和示例性服务器200a-200n可包括数据总线或其它通信机制，用于跨装置/服务器的不同部分和在装置/服务器的不同部分之间传递信息，和通信界面，用于传递装置/服务器之外的信息，和与总线连接的处理器，用于处理信息并执行其它计算和控制任务，易失性存储器例如随机存取存储器(RAM)或其它动态存储装置，连接至总线用于存储各种信息以及由处理器执行的指令，和非易失性存储器例如只读存储器(ROM或EPR0M)或其它静态存储装置，连接至总线用于存储对处理器的指令。持久性存储装置例如磁盘、光盘、或固态闪存装置被设置并连接至总线用于存储信息和指令。每一个服务器200a-200n可包括处理器、输入/输出单元，和存储器，并且可选地还包括显示器。
[0056]单独的数据库(数据源)400a_400n可被设置用于存储关于转介实体/转诊实体、专科医生、相应的提供者组织、会诊/审阅信息、诊断信息等等的信息。这些数据库400a-400n可包括一个或多个存储器和一个或多个物理界面，以便通过网络N提供信息，所述网络可能是有线或无线网络。
[0057]用户装置10a-1OOn和300a_300n可连接至包括服务器200a_200n的PRN系统并通过各种不同的网络彼此连接，所述网络可包括有线或无线网络(光纤、电缆，等)、数据网络例如互联网、公用电话交换网络，等等。用户装置10a-1OOn和300a-300n可具有通信接口，例如网络接口卡。通信接口提供双向数据通信，连接至网络链路，所述网络链路被连接至本地网。例如，通信接口可以是综合业务数字网络(ISDN)卡或调制解调器以提供数据通信连接至相应类型的电话线。作为另一个示例，通信接口可以是局域网接口卡(LAN NIC),以提供数据通信连接至兼容的LAN。也可以使用无线链接例如802.lla、802.lib,802.1lg和蓝牙。
[0058]例如，用户终端10a和300a是PC，利用各种类型的网络例如LAN连接到互联网、公用电话交换网(PSTN)等等连接至网络，与服务器200a-200n或其它用户装置进行通信。用户终端10b和300b是笔记本电脑，利用网络(可包括无线通信例如WIF1、蓝牙，或通过有线通信例如电缆和调制解调器将笔记本电脑连接至互联网)连接至网络。用户终端10c和300c是智能手机，通过基站利用蜂窝网络/移动网络例如GSM、CDMA等等彼此连接或与服务器200a-200n连接来进行通信。用户终端10d和300d可以是电视例如IPTV，利用电缆网络和/或数据网络例如互联网连接到网络，与其它用户终端或后端服务器200a-200n进行通信。
[0059]用户装置10a-1OOn和300a_300n可通过网关/防火墙连接至网络，其中网络可以是广域网或全球网络。
[0060]根据一个示例性实施例，医生转诊/转介网络(PRN)系统可体现为软件应用程序，并可存储到各种计算机可读介质上。本文所用的术语“计算机可读介质”是指参与上述进程的任何介质。计算机可读介质可以是计算机可读信号介质或计算机可读存储介质。
[0061]计算机可读存储介质可以是，例如但不限于，电子、光学、磁性、电磁、红外线或半导体系统、装置或设备，或前述的任何合适的组合。计算机可读存储介质更为具体的示例(非穷尽性列表)可包括下述:便携式计算机磁盘例如软盘或软磁盘、磁性介质、硬盘、ROM、EPROM(闪存)、RAM或任何其它存储芯片或盒式存储器、光纤、便携式光盘只读存储器(CD-ROM)、任何其它的光学介质、磁带、穿孔卡、纸带、集成电路、任何其它具有孔型式(图案)的物理介质、或任何其它已知或将来开发出来的计算机可用的介质。计算机可读存储介质可以是任何有形的非暂时性介质，所述介质可包含或存储供指令执行系统、装置或设备使用或与指令执行系统、装置或设备连接的程序，或包含或存储用于程序或指令执行系统的数据。
[0062]计算机可读信号介质可包括其中嵌入有计算机可读程序程序代码的传播数据信号，例如，以基带或作为载波的一部分。体现在计算机可读信号介质上的程序代码可利用任何适当的介质传送，包括但不限于无线、有线、光纤电缆、RF等，或任何前述的适当组合。
[0063]尽管可执行软件可能被“写到(written on) ”磁盘上、被“存储在(stored in) ”集成电路中、或通过通信电路“输送(carried over) ”，应当理解，为了本发明的目的，计算机可读介质会被称作“包括(including)”软件。因此，术语“包括(including)”旨在涵盖上述和所有的等同方式，其中软件与计算机可用介质关联。
[0064]—个说明性的非限制性的实施例是PRN系统，所述系统提供会诊/审阅实体的会诊意见/诊断来响应转介/转诊实体的请求。PRN系统可表现为软件应用程序，并且可通过基于网络的图形用户界面被传递给用户。PRN软件应用程序还可部署在专用计算机网络上(例如，LAN或WAN)，或通过具体公司的独立计算机系统部署，例如内联网安装，或通过一些其它方式部署。为了简化并易于讨论，各种说明性的非限制性的实施例会结合互联网/基于万维网的系统进行描述，应当理解，与互联网类似但不相同的网络或通信系统当然是可以利用的。
[0065]在实践层面，PRN应用程序的软件使计算机系统能够执行下文更进一步详细描述的操作，并且可被提供在各种介质的任何一种上。此外，示例性实施例的方法和运行/操作的实际实施实际上是写成编程语言的语句。所述编程语言语句当由计算机执行时，使得计算机按照具体的语句内容运行。此外，使计算机系统按照示例性实施例运行的软件可被设置成任何数量的形式，包括但不限于，原始源代码、汇编码、目标代码、机器语言、前述的压缩或加密版本，以及任何和所有的等同物。
[0066]PRN应用程序可体现为在线软件，可通过网络和/或移动设备访问，允许转介/转诊实体生成会诊/审阅信息并允许会诊/审阅实体提供会诊意见/解释。在一个示例性实施例中，会诊/审阅实体对转诊/转介实体的检查结果/发现提供其专家意见。在一个示例性实施例中，可提供专科医生的服务而不需患者经历冗长的转介/转诊程序，医生或转诊/转介实体不会担心失去患者，并且使得疾病的早期检测成为可能，否则的话患者不会得到专科医生的专家意见。PRN应用程序是安全的、实时的并且HIPAA兼容的。
[0067]图2是流程图，示出了根据示例性实施例利用PRN系统获得会诊/审阅意见的方法。
[0068]在步骤21，转诊/转介实体获得患者数据。例如，获得患者数据可包括图像/影像、观察结果、检验结果等等，可能与待会诊/审阅的状况相关。在步骤22，转介/转诊实体生成会诊信息/审阅信息，所述信息会包括会诊者/审阅者为计费的目的所需的特定医学元数据。会诊/审阅信息在下文更详细的进行描述。在步骤23，转诊/转介实体选择会诊者/审阅者(例如，专科医生)并对信息设置优先级(这两个内容会在下文更详细的进行描述)。举例来说，转诊/转介实体可指定一位具体的专科医生或两位专科医生或可指定一个或多个专科医生团体进行专科医生服务。在步骤24，转诊/转介实体随后提交转诊/审阅信息。
[0069]在步骤25，转诊/审阅系统根据由转诊/转介实体设置的优先级状态分析信息的优先级来确定是否有至少一个被选定的专科医生可以处理所生成的信息。在步骤26，如果根据由转诊/转介实体指定的优先级没有专科医生可以提供解释和他或她对会诊/审阅信息的分析，则生成错误信息，并且所生成的信息返回到转诊/转介医生处供进一步编辑。错误信息可显示在屏幕上或放在转诊/转介医生的收件箱中，例如，可能写道“对不起，没有专科医生可在指定的时间段内会诊/审阅数据”。所提供的上述输出信息意在示例而非限制。在其它示例性实施例中，信息可以按视频、SMS、传真、语音信息等等的形式输出。信息的内容也可以不同。
[0070]在步骤27，如果在步骤25中至少有一位专科医生可用(Yes)，信息会被发送至该至少一位可用的专科医生并放在他们的收件箱中(意在示例)。这仅在示例而非限制。在一个示例性实施例中，该至少一位可用的专科医生可通过自动呼叫、传真、语音信息、SMS、视频、呼叫等方式被通知。专科医生被通知有新的会诊信息丨审阅信息并等待其会诊丨审阅。根据信息的优先级也可以设置不同的通知方法。例如，紧急优先级的信息可能需要呼叫至少一位可用的专科医生，而普通优先级的信息可只是放在专科医生的收件箱中。会诊信息/审阅信息被设置为“已发送”状态。
[0071]在步骤28，一旦专科医生决定会诊/审阅信息，信息的状态变更为“已分配”。这样如果存在其他可用的专科医生，他们会根据信息的状态知道信息已有人处理，避免重复的工作。此外，转诊/转介实体也可以根据其状态知道信息当前正在被分析。
[0072]在步骤29，专科医生分析会诊/审阅信息所提供的数据并生成解释信息/解读信息。根据会诊/审阅信息中的数据自动生成解释信息。在一个示例性实施例中，根据会诊/审阅信息指定的检查类型和/或其它信息自动生成专科医生的域和可采取的行动。相应的，在步骤30，专科医生选择建议，作出评论并提供他们的检查结果/发现/解释，即，填写生成的解释信息。在步骤31，专科医生随后可提交填写的解释信息。例如，在步骤32，当提交了解释信息，会诊/审阅信息的状态变更为“已会诊/已审阅”。另外，在步骤32，会诊/审阅系统生成带有专科医生的信头和电子签名的信函，包括由专科医生填写的至少一些信息。在步骤32，信函作为附件或作为解释信息的一部分并提供/发送给转诊/转介实体。
[0073]相应的，在一个示例性实施例中，获得了专科医生的诊断，而转诊/转介实体不需担心失去患者，并且患者不需经历在【背景技术】部分所述的冗长的转诊/转介程序，除非在转诊/转介程序期间发现了状况。在一个示例性实施例中，在【背景技术】部分所述的情形二得以处理，而没有浪费患者的时间以及所涉及实体的资源。此外，通过获得专科医生对转诊/转介实体的检查结果/发现的意见可使早期检测成为可能。
[0074]图3是框图，示出了根据示例性实施例的会诊/审阅系统的组成部分。
[0075]在一个示例性实施例中，转诊系统丨审阅系统35是基于互联网的云系统，允许创建转诊(转介)实体和会诊(审阅)实体转诊(转介)池，其中定义并存储了专科医生(会诊/审阅实体)和他们的转诊/转介实体之间的转诊/转介关系。此外，在一个示例性实施例中，会诊/审阅系统允许创建转诊/转介前咨询服务，包含由不同的医疗设备在转诊/转介实体的办公室获得的图像/影像和其他度量、音频/视频数据，连同任何转诊/转介前注释/说明。另外，最初的请求可包含预先填写的患者信息和基本数据集，例如，具体诊断代码，表示所进行的检查、提供的诊断，等等。一个转诊/审阅信息可随后生成并提供给会诊/审阅实体供解读/会诊(审阅)。
[0076]根据一个示例性实施例，用户(转诊/转介实体和会诊/审阅实体)可利用工作站和/或智能手机，以便方便地创建、会诊/审阅和显示解释结果(转诊/审阅信息和解释信息/解读信息)。
[0077]根据一个示例性实施例，用户被通知收到新信息(会诊/审阅信息和解释信息)。可设置闹铃、提示等等，以帮助提醒用户收到的新请求和返回的解读(解释)/检查结果(发现)。
[0078]在一个示例性实施例中，设置了转诊/转介实体单元36和会诊/审阅实体单元37，被设置成处理会诊/审阅信息和解释信息/解读信息，在下文将进一步进行详细描述。
[0079]根据一个示例性实施例，会诊/审阅系统允许用户审阅他们迄今为止的活动。所述活动可通过报告单元3?进行处理。所述报告单元3?被设置成允许用户追踪通过特定用户、通过状态、基于优先级等等提供的转诊/转介请求和/或诊断的如度量一样的数值。在示例性实施例中提供了各种过滤和颜色编码技术，以审阅迄今为止的转诊/转介活动。
[0080]根据一个示例性实施例,会诊/审阅系统还可包括审计单元38b。审计单元38b追踪每个用户的所有活动，确保满足服务级协议以供审阅。计费单元38c追踪交易并应用计费规则为两种类型的用户创建月度账单。还应有能力建立通过信用卡的自动账单支付，按照在线计费协议。
[0081]根据一个示例性实施例，会诊/审阅系统还可包括存档单元38d。存档单元38d允许输出数据以供长期存储在用户的辅助计算机系统。存档的文档包括转诊前注释/说明和关于转诊/审阅信息的信息、结果报告和关于解释信息/解读信息的信息，以及嵌入在文档中的任何图像/影像(以无损的JPEG压缩格式)和在进程中生成的所有正式信函。
[0082]在一个示例性实施例中，不同的单元38a_38d与各自/相应的实体单元36和/或37通信，以提供所需的信息。为了便于不同单元之间的通信，可设置管理单元(未示出)，以协调不同单元的功能。
[0083]在一个示例性实施例中，会诊/审阅系统还可包括安全单元38e和临床单元38f。安全单元38e会管理关于转诊/转介实体和专科医生的(身份)认证信息。安全单元38e可与各自的实体单元36和/或37进行通信，以确保安全访问各自的用户账户。例如，安全单元38e可管理用户账户和密码。另外，安全单元38e可管理加密和解密会诊信息/审阅信息和解释信息/解读信息例如患者信息的不同域。在一个示例性实施例中，会诊/审阅系统还可包括临床单元38f。临床单元38f会管理会诊/审阅系统的所有临床/医学信息。临床单元系统会与各自的实体单元36和/或37通信，以确保检查结果/发现、建议和解释/解读之间的适当的临床表现得以保持。
[0084]上述的示例性单元本身可以是软件或可包括硬件和软件的组合例如FPGA和ASIC0
[0085]图4是框图，示出了根据示例性实施例的会诊/审阅系统的各层。如图4所示，会诊/审阅系统包括呈现层41、服务端点层42、业务逻辑层43、数据访问层44、和数据存储层45。
[0086]呈现层41可包括富客户端401a。富客户端401a包括在用户装置(例如装置10a-1OOn和300a_300n)上的必要单元。尽管在示例性实施例中，在客户端运行的PRN应用程序可通过互联网自动更新，示例性富客户端401a是安装在用户装置上的独立应用程序。呈现层还可包括瘦客户端401b。瘦客户端401b是基于网络的客户端，其中工作量通过后端服务器来处理并且瘦客户端被配置成生成请求至服务器并输出结果。
[0087]服务端点层42可包括HTTP、HTTPS和/或队列服务端点。在示例性实施例中，这些端点可允许用户装置(例如装置10a-1OOn和300a_300n)请求处理PRN应用程序所需和请求的某些业务功能。
[0088]根据一个示例性实施例，业务逻辑层43可包括业务管理器、用户管理器、检查管理器、人员管理器和/或访问管理器，以及分布式缓存管理器。在一个示例性实施例中，这些业务管理器代表上述服务端点层42的服务端点动作，处理PRN应用程序所需的某些业务功能。
[0089]根据示例性实施例，数据访问层44可包括某些数据访问对象，如用户管理、检查人员、访问和地址。在一个示例性实施例中，这些数据访问对象代表业务管理器作用，以处理PRN应用程序所需的某些业务功能。
[0090]根据示例性实施例，数据存储层45可包括某些数据库管理服务器。在一个示例性实施例中，这些数据库管理服务器代表数据访问对象作用，按PRN应用程序的要求持续将某些业务功能存储到非易失性存储器。
[0091]眼科会诊/审阅系统的一个示例性实施例在下文更详细地进行说明。本领域技术人员会容易地理解，所述的眼科会诊/审阅系统仅是意在示例说明。其它的会诊/审阅系统例如在皮肤病学、心脏病学、乳房X线照相术等领域的系统在本发明的保护范围内。本领域技术人员会易于理解，上述系统也可应用于这些领域的专科医生。例如，转介实体/转诊实体可能是主治医生，而会诊实体/审阅实体可能是皮肤科医生。这仅是意在通过示例进行说明。
[0092]根据一个示例性实施例，眼科会诊(审阅)系统还包括医学设备例如眼底图像捕获装置，如在下文中详细描述的。图5的视图示出了根据示例性实施例的眼科会诊系统/眼科申阅系统。
[0093]在如图5所示的示例性实施例中，设置了另外的医学装置501a...501η。这些医学装置501a...501η可设置在转诊/转介实体的办公室。在另一个示例性实施例中，这些医学装置或这些医学装置中的一些设置的地方可能与转诊/转介实体的办公室距离很远，或这些医学装置均不与转诊/转介实体的办公室相距远。举例来说，医学装置501a可以是眼底图像捕获装置，例如NidekAFC-330。医学装置501a输出眼底检查的医学图像/影像。医学装置501b可以是眼压测量装置，例如眼压计。医学装置501b输出度量值，例如以mmHG值表示的眼内压。由医学装置501a...501η采集的结果可由后端服务器503a...503η处理并存储在分布式数据库504a...504ηο在一个不例性实施例中，后端服务器503a...503η可分析来自医学装置501a...501η的输出，将它们转换成标准格式并储存经转换的值和原始值。例如，由各种不同类型的眼底图像捕获装置捕获的图像可被转换成jpeg格式。例如，度量值可被转换成一种标准并存储为XX _HG。
[0094]在一个示例性实施例中，另一医学装置可以是手持式视频红外间接检眼镜，它直接从装置连接并传送图像和患者信息到一个或多个后端服务器503a...503η。
[0095]在眼科护理领域，绝大多数的转介/转诊来自于验光师转诊/转介给玻璃体视网膜外科医生。在正常眼科检查过程期间，验光师可能在眼科检查过程中、或可能从家庭史或患者陈述发现眼睛状况，授权咨询/会诊玻璃体视网膜(VR)专科医生。由于VR状况是复杂的，涉及微米量级的结构，并需要专业训练和医学装置来治疗和诊断，大多数验光师转介/转诊给VR医生的患者甚至丝毫未表现出异常症状。这可能导致VR专科医生接收到大量几乎不需要专科医生护理/治疗或完全不需要专科医生护理/治疗的患者，导致不太有成效的执业，以及患者方面的烦恼和沮丧。还可能导致对他们的转诊/转介验光师的能力和专业水平缺少信任或信心。
[0096]退一步说，一般的眼科医生如白内障或LASIK外科医生，对于通过早期诊断似乎表现有VR疾病的任何患者，也将患者转诊/转介到VR专科医生。这种转诊的来源较少出现不存在VR疾病的情况，并且也表示小的多的百分比的患者去看VR专科医生。此外，主治医生可以要求VR专科医生会诊/审阅，并且不同的医学机构例如医院和诊所可能要求由VR专科医生会诊/审阅。
[0097]根据一个示例性实施例，眼科会诊/审阅系统提供会诊/审阅服务。会诊/审阅是一种机制，多个(通常两个)医生/提供者通过所述机制可以会诊/审阅针对一名具体患者的案例。通常，转诊/转介医生例如验光师遇到这样的情形，他们不能确定对于他们并不熟悉的状况的诊断、也没有受过训练或被认证进行诊断或进行他们能够确定但不能对该状况提供患者护理/治疗的诊断。转诊/转介实体在那时希望咨询专科医生(会诊/审阅实体)，所述专科医生在诊断和治疗具体的疾病方面具有专业技能并且与转诊/转介实体有转诊/转介关系。该专科医生随后会同意会诊/审阅并确定是否需要实际的转诊。如果需要，会启动将患者转诊到专科医生的程序，并且专科医生会进行其它的程序以确定诊断结果。专科医生在同意转诊后承担对于该具体疾病状况的患者护理/治疗的责任，并对指定治疗的结果负责。在一个示例性实施例中，由专科医生提供的解释信息确认或拒绝转诊/转介实体的检查结果/发现。相应的，在一个示例性实施例中，对转诊/转介实体而言患者保留。
[0098]专科医生可利用装置505a...505η中的一种提供解释信息，所述信息包括专科医生基于会诊/审阅信息中的检查结果/发现和向转诊/转介实体的可行性治疗建议。转诊/转介实体、专科医生、医学设备和后端服务器503a...503η可利用网络506相互通信，所述网络506可包括多种网络。
[0099]在一个示例性眼科会诊系统中，待确定不必要完全转诊的情形2。在一个示例性实施例中，专科医生对转诊/转介实体的检查结果/发现进行会诊，这是一个专科医生通过审阅图像/影像、患者人口统计资料和/或患者部分病史确定是否需要转诊到专科医生来诊断患者状况的过程。换句话说，在一个示例性实施例中，转介/转诊实体请求“预先审阅/预先会诊”可用的数据以确定是否需要与专科医生预约/转诊到专科医生。相应的，在患者没有状况时将患者转诊到专科医生的情形进一步地降到最低。结果，节省了患者和医生(转诊医生和专科医生)的时间和精力。此外，通过避免不必要的转诊和看诊专科医生，也使支出降到最低。
[0100]会诊/审阅-转诊实体/转介实体
[0101]根据示例性实施例，转诊/转介实体生成会诊/审阅的一个示例性实施例现在将进行详细描述。本领域技术人员会易于理解，这仅是意在示例而非限制。
[0102]图6是流程图，示出了根据示例性实施例的一种生成新的会诊/审阅信息的方法。
[0103]在步骤601，用户(可以是主治医生或其办公室工作人员)选择以生成新的会诊/审阅信息。为了生成新的会诊/审阅信息，例如，用户可首先选择图标“G”。在步骤602，用户随后可能需要选择已经存在于系统中的患者或输入新患者的信息。例如，一旦用户开始输入患者的名字，可能出现带有建议的下拉框。建议来自于已存储在系统中的主治医生的现有患者。例如，如果主治医生选定了建议中的一个，患者的剩余部分被自动填写，并且主治医生只需要点击“ok”或“确认(confirm) ”按钮来确认信息。
[0104]图7A-7D的视图示出了根据示例性实施例用于生成新的转诊信息的示例患者信息输入屏。在图7A中，用户界面(显示各种患者信息)由用户输入。用户界面可以是弹出框或可以是标签栏，用于生成会诊/审阅。例如，用户可输入患者的名(域A)、患者的姓(域B)、患者出生日期(域C)、男/女(域D)、地址(域E)。一旦信息输入，用户可点击“ok”或“提交(^油!!!^)”(域？)进入下一个页面或退出到主页面生成会诊/审阅。
[0105]在图78中，下拉框(域701)设置有按患者名字的可能的建议。可设置其它的信息例如社保号(域702)、电话号码(域703)、电子邮箱(域704)和短信地址/传真(域705)。
[0106]在图7(2中，用户可通过滚动列表711或输入名712、姓713、出生日期714和性别715的变量并提交进行搜索来选择现有的患者。为了响应选择要素716，在域711中可提供针对输入搜索条件的列表。此外，用户可选择添加新的患者717。一旦选定/找到了患者，用户可通过点击例如“提交”或“仏” 718选择继续进行生成新的会诊/审阅信息。
[0107]此外，如图70所示，用户还可输入保险信息。用户可检查患者是自费(域721〉。用户可输入保险公司名称、群组号、群组10、卡上出现的患者名字、和保险地址(域722),并选择为主要保险或第二保险(域723)。可能设置有其它的域，以选择第二保险与主要保险相同，以及是否在新生成的会诊/审阅信息中包括主要保险或第二保险或两者。
[0108]这些域仅通过示例的方式提供。对于本领域技术人员显而易见的，患者信息的许多其它域在本发明的保护范围内。
[0109]回到图6，一旦患者信息被选定或输入，在步骤603，用户可设置会诊/审阅的优先级。由于可用的专科医生可能取决于信息的输入优先级，系统可建议用户首先设置信息的优先级。在一个示例性实施例中，选择专科医生的选项直到用户设置了会诊/审阅的优先级才可用。在另一个示例性实施例中，可基于由用户设置的优先级即时建议专科医生。
[0110]在另一个示例性实施例中，用户首先选择专科医生并当用户试图设置与选定的专科医生不一致的优先级时，可输出错误信息。在另一个示例性实施例中，用户可以按任何顺序设置优先级和/或选择专科医生。不过，如果专科医生对于用户设置的优先级不可用，一旦用户试图提交会诊/审阅信息时会输出错误信息。
[0111]图8的视图示出了根据示例性实施例为会诊/审阅信息设置优先级。如图8所示，优先级可通过从下拉菜单中选择在域801中设置。例如，优先级可包括常规-例如在一天内，八3八？-在六小时内会诊/审阅，和例如在一小时内会诊/审阅。具体的值仅意在示例，并且可由用户预设或由系统基于多种因素例如使用的域(例如，测试/检查的类型)等预先设置。在一个示例性实施例中，设置优先级801可影响域802中的可用选项。
[0112]在一个示例性实施例中，与转诊/转介实体关联的专科医生列表被存储在系统中。举例来说，转诊/转介实体可添加新的专科医生到他或她的网络。？觀系统也可建议要添加到转诊/转介实体的网络的专科医生。不过，在一个示例性实施例中，可用的专科医生的列表取决于转诊/转介实体的网络。每个转诊/转介实体可具有其自己的专科医生列表或可选择让？陬系统推荐该领域的专科医生。
[0113]在一个示例性实施例中，回到图6，在步骤604，基于设置的优先级生成可用专科医生的列表。图9是流程图，示出了根据示例性实施例的一种生成可用专科医生列表的方法。
[0114]在图9中，在步骤901，取回转诊/转介实体的专科医生的网络。应当指出，网络可包括来自不同领域的专科医生。相应的，转诊/转介实体然后会首先对网络选择领域。示例性实施例涉及眼科会诊系统。相应的，在一个示例性实施例中，假设专科医生网络全部在视网膜专科医生领域。
[0115]在步骤902，核实在取回的网络中是否每个专科医生能够满足由用户指定的会诊/审阅信息的优先级。在一个示例性实施例中，对照会诊/审阅信息的优先级来核实相应专科医生的状态。专科医生的状态将在下文更详细地进行描述。不过，简要解释来说，每个专科医生可设置他或她的状态，例如，当前可用、常规、或不可用。举另一示例来说，一旦专科医生登录，他的状态可由系统自动变更为“当前可用(currently available)”。如果专科医生每天登录，他的状态可被设定默认为“常规(regular)”。如果专科医生休假离开，他可设置他的状态为“不可用(not available)”。在另一示例性实施例中，如果检测到数天没有登陆(没有活动)，PRN系统可自动设置专科医生的状态为“不可用”。根据专科医生的状态与状态信息的优先级的匹配，系统可提炼(refine)可用专科医生的列表。另外，在示例性实施例中，可由会诊系统自动实时生成可用的专科医生的更新。
[0116]在步骤903,核实是否经提炼(refined)的列表包含至少一名专科医生,如果不是，则系统在步骤904可向用户输出错误信息。例如，可设置弹出框，表示“对不起，我们无法找到任何专科医生可匹配您的会诊信息中所述的条件”。错误信息还可提供建议。例如，“您网络中的专科医生不能进行紧急会诊，而仅可以进行ASAP会诊或常规会诊”。该信息意在示例而非限制。如果在步骤903有至少一名专科医生留在列表中，则在步骤905列表输出为下拉框。
[0117]回到图6，用户随后可在步骤605通过下拉菜单选择专科医生，如图8所示的元素802。在一个示例性实施例中，用户可通过下拉菜单或通过弹出窗口选择组织例如视网膜组织或组织中的特定医生。图10的视图示出了根据示例性实施例的一种选择专科医生的方法。在图10中，下拉框1001显示可用的专科医生和执业的混合。用户选择这些选项中的一个并接下来继续提供对会诊/审阅信息的解释/解读/分析必要的医学信息。
[0118]在步骤606，用户输入对会诊所必要的医学信息。图11A-11C的视图示出了根据一个示例性实施例输入会诊相关信息的用户界面。如图1lA所示，用户选择所提供的图像/影像的类型和所完成的检查的类型，见域1001。域1102设置斯内伦视力表(Snellen Chart),以便用户可进行视力检查。图1lB的视图示出了具有示例性斯内伦视力表的用户界面，可由用户利用域1103重新生成。此外，域1104表示视敏度值。图1lC的视图示出了根据示例性实施例用于选择视敏度的用户界面。如在域1104所示，除了选择度量值之外，用户可选择测数指、手动和光感。这些仅意在示例而非限制。用户随后可在域1105输入眼压(1P)，如图1lA所示，并在域1106输入检查的日期。这仅是意在示例。可能至少一些所述的值可由医学设备直接自动填充。在一个示例性实施例中，医学设备可测量值并将所述值提供给PRN后端服务器，然后可根据存储在PRN后端服务器中的信息自动填充域例如1P和日期。用户可通过操纵域1106和1107选择不包括其中的一只眼睛。
[0119]图1lD的视图示出了根据示例性实施例用于输入图像/影像的用户界面。如图1lD所示，用户对于每只眼睛1108可上传可达到四幅的图像/影像。这仅意在示例而非限制。图像/影像可从本地驱动器或从PRN数据库上传。在另一个示例性实施例中，会诊信息/审阅信息可根据患者信息和由用户选择的检查自动填充有图像/影像。用户还可从下拉菜单中选择最初的诊断。也就是说，转诊实体/转介实体可输入他们怀疑患者可能具有的状况，需要由专科医生来确认。设置其它的域，以便用户输入意见。
[0120]回到图6，一旦输入了必要的医学信息，在步骤607，PRN系统等待用户提交生成的会诊信息/审阅信息。用户可随时返回并修改任何输入的信息。一旦提交了生成的会诊信息(在步骤607为是(yes))，在步骤608可生成正式的信函并附于会诊信息。在一个示例性实施例中，正式的会诊信函可包括信头和转诊实体/转介实体的电子签名。根据所生成的会诊信息，信函还可填有a)患者信息，b)请求会诊的原因，c)待会诊/审阅的一个或多个状况，和，d)当前日期。在一个示例性实施例中，正式的会诊信确认患者和转诊/转介实体，并请求解释/会诊由转诊/转介实体发现的可能状况。当会诊信息成功提交后，在步骤609,向用户输出信息。在一个不例性实施例中，信息可被输出到显不屏上，表不生成的会诊信息已被传送给指定的一名或多名专科医生供审阅/会诊。
[0121]PRN系统然后可返回到显示生成的会诊信息及其相应状态的用户界面。图12的视图示出了根据一个示例性实施例在PRN系统中所生成的会诊信息的用户界面。如图12所示，每个审阅/会诊信息可包括提交日期和时间1201、患者的名字1202、生成的会诊信息的优先级1203、其状态1204，和生成的会诊信息所发送给的专科医生1205。用户可打开并审阅信息1206。用户可选择编辑/更改某些域并重新提交。在这种情况，生成新的会诊信息并添加至列表。此外，生成的会诊信息1204的状态可包括“草稿” 一在提交给专科医生之前，“已提交” 一在用户将生成的会诊信息提交给专科医生之后，和“已审阅/已会诊” 一如果用户已收到回复/结果/解释信息(解读信息)。
[0122]图13A和B的视图示出了根据示例性实施例用于管理会诊信息的用户界面。如图13A所示，用户可选择在不同文件夹中搜索。用户可选择在他或她的会诊/审阅1301间进行搜索或可选择对具体患者或患者组1302搜索会诊/审阅。用户可输入社团1303、开始日期1304和结束日期1305，并然后选择搜索1306。搜索结果出现在框1307中。
[0123]如图13B所示，用户可通过选择由患者或患者组1302进行搜索，访问存档的会诊信息。用户可输入患者的名1308、姓1309、出生日期1310和性别1311，作为一些示例性搜索条件项。用户随后可选择搜索1312。结果可显示在框1313中，用户然后可选择一个或多个会诊信息1314并删除、审阅或编辑即生成具有选定信息的信息的新信息。
[0124]在一个示例性实施例中，转诊/转介实体例如主治医生可因此提交图像/影像和其它检查结果供专科医生审阅/会诊，以确定是否有必要转诊到专科医生。在一个示例性实施例中，情形2转诊可因此降到最低并且可提高疾病的早期诊断。
[0125]解释/解读-会诊/审阅实体
[0126]会诊/审阅实体例如专科医生需要登录系统以便审阅生成的会诊信息。每次专科医生登录，他们设置他们的状态，所述状态可随时在专科医生登录系统的时候被改动。图14的视图示出了根据一个示例性实施例用于设置专科医生的状态的用户界面。如图14所示，专科医生可设置他的可用性1401，设置离开办公室1402。尽管没有示出，专科医生还可设置自定义的时间表用于预定天数、星期数或月，表示他每天不同时间的可用性。例如，专科医生可选择他的有空状态(可用性)为仅在周一例行/常规审阅/会诊信息(因为周一可能是他的手术日)。此外，专科医生可设置例如周二早上9:00am-l:30pm仅对常规(routine)和ASAP有空，因为他可能在这个时间段授课，等等。本领域技术人员会易于理解，这仅意在示例而非限制。
[0127]在一个示例性实施例中，专科医生可能是不同团体的成员和/或具有若干项单独执业。相应的，专科医生可在PRN系统具有若干个账户，这使得专科医生能够分析不同的会诊信息，所述会诊信息可能被提交至一项具体的执业。专科医生可对每个帐户设置他的不同的可用性(有空状态)，或对所有账户具有一个可用性(有空状态)。PRN系统是灵活的，以允许专科医生对于不同的账户设置不同的可用性/有空状态或一个状态适用于一个或多个账户。
[0128]在另一个示例性实施例中，专科医生可登录、选择可用性/有空状态，并然后选择组织，专科医生为所述组织分析会诊信息。相应的，一次登录可访问专科医生参与的多个账户/团体。专科医生随后可按需在不同的组织之间转换。
[0129]图15是流程图，示出了根据示例性实施例的一种解释会诊信息的方法。在图15中，在步骤1501，专科医生选择提交的会诊信息。在步骤1502，提交的会诊信息的状态更改为“进展中(in progress) ”,向其他专科医生和转诊/转介实体表示该信息当前正在由专科医生审阅/会诊。在步骤1503，向专科医生显示提交的会诊信息。
[0130]图16的视图示出了根据示例性实施例专科医生分析会诊信息的用户界面。会诊信息被显示在左手侧1601。专科医生可通过标签分别为每只眼睛1608和1609解释信息。专科医生可在会诊信息中选择待审阅/会诊的图像/影像1602。专科医生可根据需要放大、改变颜色、对比度、亮度，以便准确地审阅图像/影像1602。专科医生还可解释转诊/转介实体1603提出的可能的状况或诊断以及和任何其它意见1604。专科医生还可审阅不同检查的结果和患者的视力等等。专科医生可决定他在这个时候不能完成会诊/审阅，并且可能不认领会诊信息1605。会诊信息然后可返回到收件箱，由另一专科医生认领(主张确认)。在一个示例性实施例中，会诊信息1601可被操纵但其实质不能改变。发现的情况/检查结果(findings) 1606用于生成解释信息并可由专科医生操作。
[0131]回到图15，在步骤1504，专科医生然后可选择诊断结果。如图16所示，用于生成解释信息的域被设置在显示屏1606的右手侧。这仅意在示例而非限制。本领域技术人员会易于理解，构造向专科医生呈现信息的其它方式显然在本发明的保护范围内。可由专科医生从可能的诊断/发现(检查结果)的下拉菜单中选择解释/发现(检查结果)。在一个示例性实施例中，PRN系统会诊/审阅由转诊/转介实体完成的检查并根据完成的检查选择不同的可能发现(检查结果)/状况呈现在下拉框中。
[0132]也就是说，如图17所不，在步骤1701, PRN系统解析会诊/[目息，以提取彳目息中明确提出的检查。在一个示例性实施例中，PRN系统提取由转诊/转介实体选定的检查。在步骤1702，PRN系统然后核实是否指定/明确提出了至少一项检查。如果没有提取到检查，在步骤1703可输出错误信息，并且诊断下拉框不能被填充并保持空白。专科医生然后可决定继续分析信息或可决定对会诊信息作出回应表示没有指定检查并提炼/改进会诊信息。这仅意在示例而非限制。
[0133]如果在步骤1702提取了至少一项检查结果，在步骤1703，PRN系统利用后端服务器在映射表中搜索提取的检查结果。也就是说，PRN系统查阅了知识库以便为每一个提取的检查结果寻找可能的发现(检查结果)/状况(图17中的诊断结果)。PRN系统利用后端服务器访问存储在数据库中的一个的映射表。应当指出，系统可存储多个映射表，并且可基于专科医生的专业领域选择映射表。映射表列举了每个检查结果以及可基于检查结果做出的相应的可能检查结果(发现)/诊断结果。相应的，PRN系统利用后端服务器中的一个，在映射表中搜索每个提取的检查结果。在步骤1704，如果找不到检查结果，输出错误信息 1703。
[0134]如果在映射表中找到检查结果，在步骤1705，存储在映射表中的相应的可能状况/诊断结果被添加至列表。也就是说，当在映射表中找到检查结果时，相应的可能状况/诊断结果被储存在列表中。在一个示例性实施例中，映射表存储每个检查结果和可基于检查结果所作的相应的可能状况/诊断结果。相应的，当在映射表中找到检查结果时，与检查结果关联的诊断结果被提取并被存储在列表中。在步骤1706，PRN系统核实是否存在还未被核实的至少一个其它提取的检查结果。如果是，程序返回到步骤1703，以便在映射表中搜索该检查结果。
[0135]如果利用映射表将每一个提取的检查结果映射到可能的状况/诊断结果(在步骤1706中为No)，则在步骤1707，从存储的列表中排除重复的诊断结果。例如，PRN系统核实以便利用标记排除任何相同诊断结果的重复列表。在步骤1708，列表然后用于填充诊断结果1606的下拉框1607。相应的，仅向专科医生提供会诊信息的相关诊断。
[0136]回到图15，在步骤1504，专科医生从自定义填充下拉菜单选择诊断中的一个。在一个示例性实施例中，贯穿生成解释信息的过程，多个诊断可被选择和/或添加/删除。在步骤1505，专科医生还可选择一个或多个建议。
[0137]图18A-18D的视图示出了根据示例性实施例用于选择至少一个建议的用户界面。如图18A所示，专科医生可从下拉框1801选择建议中的一个。建议1801可包括:1)重复做检查、2)需要其它的检查、3)复诊(跟进)、4)需要更多信息、5)不需要采取任何措施，和，6)需要转诊。
[0138]在一个示例性实施例中，如果专科医生建议(I)重复做检查，可在1802和1803进一步指定期限，如图18B所示。还可在1804输入其它的意见。例如，专科医生可要求在一年内重复做检查作为预防或在一周内重复做检查，例如如果图像/影像未被正确上传。
[0139]如果专科医生建议(2)作其它的检查1801，专科医生还可从下拉菜单中选择检查的类型1805，并输入其它的意见1804，如图18C所示。
[0140]如果专科医生建议(3)复诊(跟进)，可输入与图18B所示类似的期限。在其它的意见1804中，专科医生还可解释为何需要复诊(跟进)，以及在复诊(跟进)期间想要观察什么和哪项检查要重复(如果有的话)。例如，专科医生可建议在三个月作重复检查，即，提到特定非临床意义状况，但需要通过在其它的意见1804中记录来监控，并然后建议作重复检查，以便转诊/转介实体可核实问题是否从基线发生变化，并因而可保证在以后到转诊/转介实体的就诊中可转诊给专科医生。
[0141]专科医生建议(4)需要更多的信息。专科医生然后会在意见栏1804中指出所需的其它信息。例如，专科医生可指出右眼的图像/影像是模糊的并需要重拍。
[0142]专科医生建议(5)-不需要采取任何措施。由此，可避免在【背景技术】部分所讨论的情形2。也就是说，基于检查结果/发现，专科医生相信不需要进一步的措施，并且没有需要专科医生关注的情况。专科医生还可在1804中包括意见。
[0143]专科医生建议(6)需要转诊。如图18D所示，专科医生可对转诊1802和1803输入期限。用户还可输入一些提议的治疗选项1806并提供其它的意见1804。
[0144]回到图15，现在专科医生完成了解释信息。在步骤1506，专科医生然后可选择预览信函。在一个示例性实施例中，可基于在前述步骤1504-1506的检查结果/发现输入生成信函。
[0145]图19是流程图，示出了根据示例性实施例生成解释信函的一种方法。如图19所示，在步骤1901，确认专科医生是否是专科医生团体中的一员。如果专科医生是专科医生团体中的一员(1901-是)，在步骤1902，一个示例性实施例要求专科医生选择具体的团体，希望设置用于本会诊的上下文，包括要使用的具体团体的信头和提供者数字签名。在一个示例性实施例中，在步骤1903，根据选定的团体或根据专科医生是否是个体医生从数据库取回信头和数字签名。
[0146]信头可能对于执业的每个专科医生团体可以是自定义的或可能对于执业是一种?目头。
[0147]在步骤1904，信函然后根据会诊信息中提供的信息填充有患者信息和检查类型。图20的视图示出了根据示例性实施例的生成的解释信函。如图20所示，列出了检查类型2001和患者信息2002。
[0148]在步骤1905，信函可填充有由专科医生输入的来自诊断、意见和建议的信息。如图20所示，例如，可在2003提供专科医生意见；可能另外的自动文本可被添加到意见栏，例如“感谢会诊的机会”或“感谢使用PRN”，等等。此外，信函可包括检查结果2004 (基于会诊信息)、诊断结果2005和建议2006的表示。此外，每只眼被单独提到，如图20所示。对于每只眼,如在本示例性实施例中所述,记录了转诊/转介实体最初对会诊的标示(对检查的标示)，以及由专科医生所确定的印象。另外，每只眼还可包含由专科医生在会诊过程中详述的任何意见。
[0149]在步骤1906，信函被转换为预定的格式，例如.pdf并添加签名。相应的，根据账户预先储存的信息(执业团体或个体专科医生)、在收到的会诊信息中所提供的信息、和由专科医生输入的检查结果/发现生成解释信函。
[0150]专科医生可能不需要预览信函并在步骤1507可简单地提交检查结果而不预览，如图15所示。当检查结果被提交，在步骤1508生成解释信息。为了生成解释信息，会诊信息、检查结果和生成的信函的信息被添加到信息(message)，并且信息被提交到PRN系统。在步骤1509，会诊信息的状态被变更为“已审阅/已会诊”。
[0151]在一个示例性实施例中，转诊/转介实体通过预定的方法例如SMS、自动电话、在收件箱改变会诊信息的表现形式，例如，以粗体呈现会诊信息以表示已添加了检查结果，被通知信息的状态变更。当转诊/转介实体打开会诊信息，两侧(会诊/审阅侧和检查结果)均完成。转诊/转介实体不能改变会诊信息的任何一侧，但除审阅他或她的检查结果/发现外还可选择查看/打印由专科医生生成的信函。用户然后将会诊信息的状态变更为“完成”。一旦会诊信息被标记为完成，其从收件箱中被删除并存档到存档数据库中的一个。
[0152]在一个示例性实施例中，会诊信息包括保险信息，可被转诊/转介实体和/或专科医生使用以便为提供的服务开具帐单。另外，在一个示例性实施例中，可能一个实体可具有双重角色:转诊/转介实体角色和会诊/审阅实体角色。例如，双重角色实体的收件箱可被分开，使得屏幕的一部分提供待办事件列表，填有双重角色实体需要分析和解释的会诊信息。屏幕的另一部分可提供生成的或由双重角色实体的生成过程中的会诊信息。相应的，在一个示例性实施例中，双重角色实体可查看两者:已提交的生成的会诊信息和需要待分析的会诊信息。
[0153]在一个示例性实施例中，会诊/诊断由专科医生远程进行，以确定是否需要转诊。在【背景技术】部分所述的情形2被最小化。另外，转诊/转介实体保持与患者的接触，并因此较少担心失去患者并且根据需要咨询专科医生。此外，患者获得最初专科医生的专家意见，而无需冗长的转诊过程。此外，提高了疾病的早期诊断。
[0154]不同的会诊(PRN)系统的示例性组成部分已在上文的不同示例性实施例中进行了描述。会诊(PRN)系统可以是一体的系统或每个组成部分可以单独与其它系统一起使用。在一个示例性实施例中，系统的特定组成部分可嵌入在另一系统中。
[0155]附图中的流程图和框图示出了根据不同示例性实施例的体系结构、功能、以及系统、方法和计算机程序产品的可能实施的运行。就此来说，流程图或框图中的每个方框可表示模块、分段、或部分代码，其包括一个或多个可执行指令用于实施所指定的逻辑功能。还应当指出，在一些可替换的实施例中，方框中所注的功能可能不按图中所记录的顺序发生。例如，两个示出为连续的方框实际上可基本上同时执行，或两个方框有时可按相反的顺序执行，这取决于所涉及的功能。还应当指出，框图和/或流程图示图中的每个方框、框图和/或流程图示图中的方框的组合可通过专用基于硬件的系统实施，所述系统执行特定功能或动作，或专用硬件和计算机指令的组合。
[0156]所附权利要求中的相应的结构、材料、动作以及所有装置或步骤加功能特征的等同旨在包括与所具体要求保护的其它权利要求特征结合用于执行功能的任何结构、材料，或动作。为说明和描述的目的已呈现了示例性实施例的说明，但并不旨在穷尽或限制所披露的形式。在不偏离本发明的精神和范围的情况下，多种改动和变化对于本领域技术人员来说是显而易见的。选择并描述示例性实施例是为了更好的解释原理和实施本发明，并且使本领域的其他技术人员能够理解本发明的构思，以便具有不同改动的多个实施例适于具体的使用。
[0157]一个示例性实施例部署在计算机系统中。这里，术语“计算机系统”应当理解为包括至少一个存储器和处理器。一般，存储器会在此时或彼时存储至少部分的可执行程序代码，而处理器会执行包括在该可执行程序代码中的一个或多个指令。应当理解，术语“可执行程序代码”和术语“软件”对于本说明书表示基本相同的事物。对于实施一个或多个示例性实施例，存储器和处理器不必要在物理上位于相同的位置。也就是说，可以预见处理器和存储器可能位于设备的不同物理部分或甚至位于不同的地理位置。
[0158]一个示例性实施例还具有用户界面，可由应用程序调用。用户界面可被理解为表示任何硬件、软件，或硬件与软件的组合，允许用户与计算机系统交互。为了说明的目的，用户界面可被理解为包括一个或多个用户界面对象。用户界面对象可包括显示区域、用户可激活区域等等。应当理解，显示区域是用户界面的区域，向用户显示信息。用户可激活区域是用户界面的区域，例如按钮或菜单，允许用户对于用户界面采取一些动作。
[0159]用户界面可由应用程序调用。当应用程序调用用户界面时，通常是为了与用户交互的目的。不过，为了本发明构思的目的，不必然实际用户与用户界面进行交互。为了本发明构思的目的，也不必然由实际用户进行与用户界面的交互。也就是说，可以预见用户界面可与另一程序进行交互，例如利用宏编程语言语句创建的程序，模拟用户相对于用户界面的动作。
[0160]选择并描述示例性实施例是为了解释运行和实践应用，并使本领域的其他技术人员能够理解具有不同改动的不同示例性实施例，适于具体使用。也就是说，对这些示例性实施例的不同改动对于本领域技术人员来说会变得显而易见，并且本文所定义的一般性原理和具体示例可应用于其它的实施例，而不需要创造性的劳动。例如，上述的一些或所有的不同示例性实施例的特征可被结合入单个实施例中。反之，上述单个示例性实施例的一些特征可从该实施例中删除。因此，本发明的构思不旨在限于本文所述的示例性实施例，而是按照权利要求及其等同的限制所限定的最宽的保护范围。
【权利要求】
1.一种提供医学会诊的方法，所述方法包括: 由用户从可用的会诊者的列表中选择至少一名会诊者； 设置答复的优先级； 通过计算机生成会诊信息，所述会诊信息包括患者的元数据，通过在患者方面执行的多个事件获得、设置的优先级、和选定的会诊者的身份； 通过有保障的网络传送生成的会诊信息；和 根据传送的会诊信息通过有保障的网络接收解释信息， 其中，根据设置的优先级和当前可用的会诊者实时生成可用的会诊者的列表。
2.根据权利要求1所述的方法，其中生成可用的会诊者的列表包括: 实时确定用户目录中多个会诊者的每一个的状态；和 基于确定的状态确定多个会诊者的每一个是否能够生成解释信息以满足设置的优先级。
3.根据权利要求1所述的方法，其中解释信息包括由选定的会诊者根据会诊信息中所提供的数据由建议和方案列表生成的解读信息。
4.根据权利要求3所述的方法，其中建议选自根据会诊信息中提供的事件识别的可用建议选项列表。
5.根据权利要求1所述的方法，其中患者的元数据包括在患者方面进行的检查的类型以及显示检查的结果的度量数据和图像的至少一个。
6.根据权利要求1所述的方法，其中患者方面是至少一只眼睛，并且其中多个事件包括与眼相关的检查。
7.一种提供医学会诊的方法，所述方法包括: 接收会诊信息，所述会诊信息包括包含在患者方面执行的多个事件的患者的元数据、优先级和至少一个会诊者的身份； 由计算机分析会诊信息，其中根据执行的事件识别可用的建议； 生成解释信息，所述解释信息包括由会诊者从识别的可用建议选项中选择的建议；和 通过网络传送生成的解释信息。
8.根据权利要求7所述的方法，其中分析会诊信息还包括:对接收到的会诊信息自动分配状态标识， 其中，如果在会诊信息中识别到一个会诊者，将已分配状态分配给会诊信息并通知会诊者接收到的会诊信息，和 其中，如果在会诊信息中识别到至少两个会诊者，将已提交状态分配给会诊信息并通知至少两个会诊者接收到的会诊信息，并且其中当至少两个会诊者中的一个主张确认了会诊信息，将已分配状态分配给会诊信息。
9.根据权利要求8所述的方法，还包括: 接收来自至少两个会诊者中的会诊者关于会诊信息的输入； 根据会诊者的输入将会诊信息的状态变更为分配状态；和 在生成解释信息之后将会诊信息的状态变更为已会诊状态。
10.根据权利要求9所述的方法，其中会诊信息的状态变更实时更新并且更新的会诊信息显示在会诊者用户界面和提交实体用户界面。
11.根据权利要求7所述的方法，其中: 患者身体方面包括至少一只眼睛并且多个事件包括至少一个与眼相关的检查， 元数据还包括至少一种类型的与眼相关的检查； 识别可用的建议包括: 在映射表中搜索至少一种类型的与眼相关的检查中的一个； 如果在映射表中找到一种类型的与眼相关的检查，获得至少一个相应的可用建议； 将获得的至少一个相应的可用建议添加为识别的可用建议。
12.根据权利要求7所述的方法，其中生成解释信息还包括添加治疗信息，表示是否有必要转诊给会诊者。
13.根据权利要求7所述的方法，其中生成解释信息还包括从可用的治疗列表中选择至少一种治疗，所述可用的治疗列表包括没有必要转诊、在预设时间段内需要复诊、需要更多信息、多个事件中的至少一个需要在预设时间段内重复、和需要转诊，所述需要转诊包括提议的治疗选项。
14.根据权利要求7所述的方法，其中生成解释信息包括生成信函，所述信函包括来自会诊信息的至少一部分元数据、来自生成的解释信息的至少一部分信息、和会诊者的元数据，所述会诊者的元数据包括自定义的信头和电子签名的至少一个。
15.一种生成会诊信息的装置，所述装置包括: 存储器，所述存储器存储多个会诊者； 通信界面，所述通信界面被设置成接收从可用的会诊者列表中选择的至少一个会诊者和由用户选择的答复的优先级；和 处理器，所述处理器被设置成生成会诊信息，所述会诊信息包括患者的元数据，通过在患者方面执行的多个事件获得、接收到的优先级、和接收到的选定的会诊者的身份； 其中，通信界面通过有保障的网络传送生成的会诊信息并通过有保障的网络基于传送的会诊信息接收解释信息，和 其中，基于设置的优先级和当前可用的会诊者从存储的多个会诊者中实时生成可用的会诊者列表。
16.根据权利要求15所述的装置，其中处理器实时确定用户目录中多个会诊者的每一个的状态，并基于确定的状态确定多个会诊者的每一个是否能够生成解释信息以满足设置的优先级。
17.根据权利要求15所述的装置，其中解释信息包括由选定的会诊者基于在会诊信息中提供的数据由建议和方案列表生成的解读信息。
18.根据权利要求17所述的装置，其中建议选自基于在会诊信息中提供的事件识别的可用建议选项的列表。
19.根据权利要求17所述的装置，其中患者的元数据包括在患者方面进行的检查的类型和显示检查的结果的度量数据和图像的至少一个。
20.根据权利要求17所述的装置，其中患者方面是至少一只眼睛并且其中多个事件包括与眼相关的检查。
21.一种提供医学会诊的装置，所述装置包括: 通信界面，所述通信界面被设置成接收会诊信息，所述会诊信息包括包含在患者方面执行的多个事件的患者的元数据、优先级、和至少一个会诊者的身份； 处理器，所述处理器被设置成分析会诊信息，其中根据所执行的事件识别可用的建议；并且，所述处理器被设置成生成解释信息，所述解释信息包括从由会诊者识别的可用建议选项选择的建议， 其中，通信界面通过网络传送生成的解释信息。
22.根据权利要求21所述的装置，其中处理器向接收到的会诊信息自动分配状态标识， 其中，如果在会诊信息中识别到一个会诊者，处理器将已分配状态分配给会诊信息，并控制通信界面以便通知接收到会诊信息的会诊者的至少一个装置，和 其中，如果在会诊信息中识别到至少两个会诊者，处理器将已提交状态分配给会诊信息，并控制通信界面以便通知接收到会诊信息的至少两个会诊者的每一个的至少一个装置，并且当至少两个会诊者中的一个主张确认了会诊信息，处理器将已分配状态分配给会诊信息。
23.根据权利要求22所述的装置，其中通信界面接收来自至少两个会诊者中的会诊者关于会诊信息的输入， 其中，处理器根据会诊者的输入将会诊信息的状态变更为分配状态；并且在生成解释信息之后将会诊信息的状态变更为已会诊状态。
24.根据权利要求23所述的装置，其中: 处理器实时变更会诊信息的状态， 患者身体方面包括至少一只眼睛并且多个事件包括至少一个与眼相关的检查， 元数据还包括至少一种类型的与眼相关的检查，和 处理器通过下述识别可用的建议: 在映射表中搜索至少一种类型的与眼相关的检查中的一个； 如果在映射表中找到一种类型的与眼相关的检查，获得至少一个相应的可用建议；和 将获得的至少一个相应的可用建议添加为识别的可用建议。
25.根据权利要求21所述的装置，其中处理器添加治疗信息，表示对于会诊信息是否有必要转诊给会诊者。
26.根据权利要求21所述的装置，其中处理器从可用的治疗列表中选择至少一种治疗，所述可用的治疗包括没有必要转诊、需要在预设时间段内复诊、需要更多信息、多个事件中的至少一个需要在预设时间段内重复、和需要转诊，所述需要转诊包括提议的治疗选项。
27.根据权利要求21所述的装置，其中处理器生成信函，所述信函包括来自会诊信息的至少一部分元数据、来自生成的解释信息的至少一部分信息、和会诊者的元数据，所述会诊者的元数据包括自定义的信头和电子签名的至少一个并将生成的信函附于解释信息。
28.一种非暂时性计算机可读介质，其中存储有权利要求1所述的方法。
29.一种非暂时性计算机可读介质，其中存储有权利要求7所述的方法。
30.一种提供医学会诊的系统，所述系统包括: 第一装置，所述第一装置用于生成医学会诊信息，所述第一装置包括: 第一通信界面，所述第一通信界面被设置成接收从可用的会诊者的列表中选择的至少一个会诊者和由用户选择的答复的优先级，并被设置成通过有保障的网络传送会诊信息并通过有保障的网络基于传送的会诊信息接收解释信息，和 第一处理器，所述第一处理器被设置成生成会诊信息，所述会诊信息包括患者的元数据，通过在患者方面执行的多个事件获得、接收到的优先级、和接收到的选定的会诊者的身份；和 第二装置，所述第二装置用于提供医学会诊来响应会诊信息，所述第二装置包括:第二通信界面，所述第二通信界面被设置成接收来自第一装置的会诊信息并通过有保障的网络传送解释信息来响应会诊信息；和 第二处理器被设置成分析会诊信息，其中根据所执行的事件识别可用的建议，并且所述第二处理器被设置成生成解释信息，所述解释信息包括从由会诊者识别的可用建议选项中选择的建议； 其中，根据设置的优先级和当前可用的会诊者由存储的多个会诊者实时生成可用的会诊者的列表。
【文档编号】G06Q50/22GK104335240SQ201380028247
【公开日】2015年2月4日 申请日期:2013年4月29日 优先权日:2012年4月27日
【发明者】D·S·戴尔, J·W·希金斯 申请人:Prn公司