专利名称：处方管理系统的制作方法
技术领域：
本发明通常涉及用于在配药业中处理定单的一种图像和工作流程方法、系统和介质。特别是，本发明涉及一种用于在邮寄配药业中处理药物处方的方法、系统和介质。
背景技术：
在邮寄配药业中，需要提高医学处方的处理质量和效率。邮寄配药业每天都收到巨大数量的定单，并且每个药房所在地在一周内收到250,000到275,000个处方并不是罕见的。典型地，医学处方必须以非常有时效的方式来配药。此外，由于在给病人的处方中的错误可能能危及生命，所以在整个处方配药过程中必须保持一个高水平的质量控制。
从病人那收到的定单经常不是处于不需要任何另外的处理而直接配药的状况。例如，由于开药者的书写难以辨认，处方可能难以理解。阻碍定单周转时间的其它条件包括，例如，丢失的优惠计划会员号码或者错误的或无效的优惠计划会员号码；解决在现有病人状况或药物疗法下服用一个新处方时可能出现的任何药物相互作用；付款遗漏；重要的病人信息遗失；处方不处于病人的优惠计划内；以及不正确的剂量或其它剂量或用量矛盾。为了解决任何上述示例中的问题，时常需要为处方配药的药剂师或其它技师联络，例如，开药者、病人、会员、客户或其组合。
目前，配药业在处方配药的过程中使用物理纸张定单文件来处理处方。对物理纸张文件的依赖是很不方便的，并且导致处方处理延迟。在目前的配药模型下，当处方的定单到达时，它们被复核并被分配到一个盘子中。盘子是物理托盘，所有定单文件都放置在其上面。盘子典型地用颜色编码，以对应一周的每一天或与收到定单的顺序有关的一些其它纪年法。因此，例如如果一个定单在星期一被收到并且被打开，则它将被放置在红色托盘中，在这个示例中该红色托盘就是星期一托盘。为解决与定单关联的任何错误、问题和/或条件可能要求与开药者、病人、会员、客户或其组合的联系。开药者是负责书写包含在一个定单中的处方的个人，并且通常是医生。会员是持有优惠计划的个人。病人可以是一个会员但也可能是被会员指定的个人，如一个家庭成员，并包括在优惠计划内。客户向邮寄定单药房完全或部分支付与药物有关的帐单和管理费，并且通常是负责为会员提供优惠计划的公司或个人。例如，如果由于药物剂量难以辨认，一个处方要求呼叫开药者，就要试图联系开药者。如果联系开药者的尝试失败，则可给开药者办公室留消息。当开药者回复这个呼叫时，开药者通常须经过一定的等待时间，而药剂师或其它技师搜查大堆盘子以找到相应的定单。结果的等待时间通常导致开药者一方失望。
目前基于纸张的配药系统还苦于不能对任何一个定单的精确位置进行定位。例如，如果病人打电话给药房，请求更新他们的定单，或如果病人需要修订定单的送货地点，则以一种让病人满意的有效方式来定位定单是麻烦的。当病人打电话询问他们的处方与定位定单之间的延迟时间造成病人对药房的坏印象。
当前邮寄定单配药方法造成药房处理定单缓慢的错误印象，其另一方面源自于病人和药房的地理位置完全不同。例如，如果邮寄定单药房位于华盛顿的西雅图，病人位于纽约(NY)，则仅仅邮递时间就损失好几天——到西雅图需要几天和从西雅图到纽约又需要几天。能够把待处理的处方邮递到离纽约较近的药房如新泽西的某个地方，以缩减邮递时间，这将是有利的。
而且，邮寄定单配药业的当前方法不能获得定单处理中所涉及的各种系统组件的状态或健康的信息。尤其是，当前方法不能提供实时系统状态信息。
因此，我们已确定，对目前系统的改进将提供关于系统或系统的任何子组件的状态，在处理过程内在任何时间和任何位置定位定单的能力，以及在不同于配药药房的位置处理定单的能力的实时状态信息。
发明内容
因此，本发明的一个特点和优点是，提供一个为从通信通道或其它定单进入过程/系统收到的至少一个医学处方自动处理定单的方法。
本发明的一个额外和可选的特点和优点是提供一个自动处理从通信通道或其它定单进入过程/系统收到的至少一个医学处方的定单的系统。
本发明的另一个可选的特点和优点是提供一个图形用户界面，用于实时输入、显示、验证和管理一个处方执行系统，其中图形用户界面产生系统报告和定单统计。
减少对纸质文件和手工文件及传送文件的依赖性也是本发明的一个可选特点和优点。
为至少一个医学处方的定单自动处理的执行提供计算机可读介质仍是本发明的另一可选特点和优点。
本发明的另外一个可选特点和优点是为被用户界面分割程序访问的至少一个医学处方的定单的自动处理提供计算机可读的数据结构。
在对详细描述、附图和所附权利要求检查的基础上，本发明的这些和其它目标和优点对于本领域的普通技术人士将是显然的。
例如，本发明使用成像技术提高质量和加速邮寄定单处方的处理时间。本发明的自动成像环境确保处方的及时和准确处理和处方复核，以及更容易检索完整的工作例文件。应用于处方定单的灵活的和可配置的关系数据库减少了整个处方定单处理时间。
本发明还降低了人工劳动成本，因为本发明优选地不需要人工劳动在配药处理过程中传送和分类定单。此外，本发明通过减少用户在系统中处理定单不得不通过的屏幕数量，在每个定单所花费的时间和为系统培训新用户所需要的时间两方面最好地减少劳动成本。
扫描仪用于把通过邮寄收到的信息读取到计算机文件和/或存储器，在其中可选择地存储永久相同的数据。创建的定单永久记录使得容易检索定单。
数据库参数被人工键入到定单记录，并用来把不同类型的输入的定单文件编入索引。不同参数用于区别不同类型的定单文件。例如，付款优惠券区别于实际处方。
本系统、方法和介质的其它特点包括数据库表，它们将执行定单的动作类型和序列识别为应用程序处理逻辑。在特定实例中，这些序列被自动执行。能在任何系统级上跟踪生产率、质量和性能的系统级报告也被生成。
符号和术语随后的详细描述用在计算或处理系统(例如，独立的游戏机、计算机或计算机网络)上执行的程序过程来表示。这些程序描述和表示是本领域技术人士所使用的方式，以最有效地向本领域其他技术人士传达他们工作的实质内容。
这是一个过程，并通常被认为是导致一个预期结果的前后一致的连续步骤。这些步骤是那些要求物理量的物理操作的步骤。通常，尽管不必要，这些量采取能够被存储、传送、混合、比较和不同地操作的电或磁信号的形式。主要由于共同使用的原因，把这些信号称为比特、值、元素、符号、字符、术语、数字等等，有时证明是方便的。然而，应该指出的是，所有这些和类似的术语将与恰当的物理量相关联，并仅仅是应用于这些量的方便标签。
而且，执行的操作经常以术语的方式被提及，如增加或比较，它们常与操作人员执行的智力操作相关联。在这里描述的构成本发明一部分的任何操作中，操作人员的这种能力不是必要的，或在大多数情况下不是期望的；操作是机器操作。执行本发明的操作的有用机器包括通用数字计算机或类似设备。
在阅读下面的详细描述和参考附图的基础上，本发明的这些和其它方面、优点和新特点将是显然的，其中图1是一个示出本发明的定单处理系统的一个实施例的体系结构的块图。
图2是一个示出成像的定单文件的屏幕捕获图。
图3是一个高级块图，表示本发明的定单处理系统的一个实施例的整个流程控制。
图4描述处理一个定单的高级流程图。
图5描述一个表示定单的迭代应用和分解的流程图。
图6描述标题输入(Header Entry)的流程控制图。
图7A和7B描述预处理在邮寄通信通道中收到的定单的流程控制图。
图8是一个表示非临床数据输入/核实的屏幕捕获图。
图9描述定单完成(Order Completion)的流程控制图。
图10描述联系管理(Contact Management)的流程控制图。
图11描述传真过程(Fax Process)的流程控制图。
图12是一个表示临床数据输入/核实的屏幕捕获图。
图13A～13E描述联系管理(Contact Management)的一个重叠实施例的流程控制图。
图14A～14E描述管理维护(Managed Care)定单的分解的流程控制图。
图15A和15B描述管理维护定单的分解的一个重叠实施例的流程控制图。
图16A和16B描述管理维护定单的分解的一个重叠实施例的流程控制图。
图17描述到命令和控制(Command and Control)的信息流的示意图。
图18描述来自命令和控制界面的仪表面板屏幕的一个示例。
图19描述来自命令和控制界面的条形图队列总数屏幕的一个示例。
图20描述来自命令和控制界面的队列数据表格屏幕的一个示例。
图21描述来自命令和控制界面的队列数据表格屏幕的一个示例，其中表格的纵列是表示有关定单总体在一个特定队列中的时间长度的时间片。
图22描述来自命令和控制界面的混合队列数据表格和条形图队列群屏幕的一个示例。
图23表示根据本发明的系统的一个可能的硬件和网络配置。
具体实施例方式
系统概览图1是实践本发明的医学处方定单处理系统10的一个示例。特别地，一个医学处方定单(也称为定单)通过到系统的许多通信通道中的至少一个被系统收到。通信通道既包括纸张文件通道，例如邮件(U.S.Post，如联邦快递的商业速递)、人工传真等等；又包括无纸或电子通道，如电子传真、电子邮件、电话等等。定单进入系统的定单入口点或通信通道在纸质定单的标准切割机处理器(Slitter Processor)15、标准传真处理器(Facsimile Processor)20和标准的进入无纸定单处理器(Incoming Paperless Order Processor)25被发现。
接收的邮件被适当处理和放置以被扫描进入系统。例如，邮件在切割机处理器15进入系统。切割机处理器15打开信封并给信封盖上预定信息，其包括例如每个信封被切割机处理器15打开时的日期。
一个类似的预处理步骤在通过到达传真处理器20的人工传真通信通道接收的人工或纸质传真上执行。根据本发明的一个替代实施例，接收的人工传真与接收的邮件一起捆扎为纸张捆。
在文件准备处理器(Document Preparation Processor)30，纸张捆中的每个信封的内容被复核并准备扫描。一个信封的全部内容组成一个定单。打开的信封组成预定数量的信封捆。这些捆然后变成纸张捆。每个纸张捆包括一捆所有的文件和所有关联的准备表格。关联的准备表格包括，例如，一张位于纸张捆上面的捆首单，用于分隔定单的定单隔离物和位于每个纸张捆尾部的捆尾单。当在系统协议下可适用时，每个信封的内容被分配到预定文件类型或类别中。每个文件被贴上一个预先印好的条形码标签，其标识带有这种标签的文件属于一个特定的文件类型。文件类型包括，例如，信封——在系统信封和非系统信封之间有区别；EasyRX/Universal Order Form(UOF，通用定单表格)；便条——包括，例如，会员或病人已经在其上写有信息的任何东西；处方再配药；处方更新；付款优惠券；付款——包括例如现金、支票和汇票；健康、过敏和药物调查表(HAQ)——任何类型的会员或病人健康简要描述表格；新处方；不可扫描的表单——表示不可扫描的定单中的文件的表单；和其它——包括不适合预定类别或文件类型的任何东西。曾经订购并贴有适用条形码标签的定单文件被发送到高速扫描仪40用于成像。
如果一个定单的文件的内容或成分不符合预定标准，就从定单中抽出这样的文件，用不可扫描的表单替代，并可选地发送到异常处理处理器(Exception Handling Processor)35。发送到异常处理处理器35的文件包括，例如现金、三维物体如空的处方瓶、难以读取的条目、难以扫描的文件或高速扫描仪处理器40不能扫描的其它文件。如果一个定单包含现金，则该现金被计算并至少记录一式两份。现金和至少一份记录存放在现金盒子40或储蓄帐户中，且至少一份与组成现金所源自的定单的文件一起存放。不是扫描包括在定单中的现金，而是扫描记录的付款表格。接收现金的其它表格可选择地使用。如果定单包含一个三维物体，如空的处方瓶，则该物品被发送到异常处理处理器35。异常处理处理器35考虑到该物品，并把异常物品的记录发送给定单，因此包含在该物品中的信息对定单是可用的，用于进一步的定单处理。图像显示器36与异常处理处理器35通信，用于监控异常处理处理器35所捕获的图像。
图像显示器45与高速扫描仪处理器40通信，用于监控捕获的图像的质量。根据预定的复核审计程序表，复核扫描纸张捆。根据本发明的一个重叠实施例，预定复核审计程序表是基于随机选择的，其中只有随机选择的扫描纸张捆被发送到图像质量控制处理器50，用于图像复核。替代地，可利用所有扫描的纸张捆。没有被选择发送到图像质量控制处理器50的纸张捆被存储到计算机可读介质55，如计算机存储器、计算机硬盘驱动器、磁带驱动器，和/或计算机可读的光介质。对应于定单图像的硬拷贝被存储或存档在文件室60中，其存储方式是把它们编索引为它们的电子图像的预定方式。根据本发明的一个替代实施例，纸张捆中的每个扫描文件已经附有或关联一个文件标识号，它链接到其对应的纸张捆首标识号，借助于标识号，纸张捆存档在文件存储室60中。
被选择复核的纸张捆被系统用户复核。如果发现扫描图像中存在缺陷，且缺陷数超过一个预定阈值，则整个纸张捆被发送到重扫描/异常处理处理器35。如果被图像质量控制处理器50复核之后，发现图像是可以接受的，则图像被存储到计算机可读介质，如计算机存储器、计算机硬盘驱动器、磁带驱动器，和/或计算机可读的光介质。对应于定单图像的硬拷贝以把它们编索引为它们的电子图像的预定方式，存储在文件室60中。
先前已经被扫描和批准的纸张捆被发送到系统队列，用于进一步的定单处理。
根据定单的内容，定单将通过定单标题处理器65、定单完成处理器70和/或定单复核处理器75中的至少一个。定单标题处理器65、定单完成处理器70和定单复核处理器75各自彼此通信，并与管理协议分解处理器80(Administrative Protocol Resolution Processor)和专业协议分解处理器85(Professional Protocol Resolution Processor)通信。
定单标题处理器65处理与定单关联的非临床数据。非临床数据包括，例如定单中的处方数量；处方分类；会员号——因为它涉及优惠计划，组号——因为它涉及优惠计划，和子组号——因为它涉及优惠计划；支付的数额和类型；病人/客户通信；开药者名字；病人/客户名字和处方的发出日期。
定单完成处理器70处理与定单关联的临床数据。临床数据包括，例如药物信息、药物浓度、药物使用说明、允许的再配药次数、要配发的药物数量和每日剂量。
定单复核处理器75复核定单的所有元素，以确定定单元素是否正确。离开定单复核处理器75的定单被发送到高速打印处理器90，在那里打印处方标签和其它伴随的定单资料。然后药物在定单配发处理器95处实际配发，并被发送到送货站处理器100，以给病人发货。对于处理器90、95和100的示例，请参见美国5,771,657号专利，其标题为“AUTOMATIC PRESCRIPTION FILLING，SORTING ANDPACKAGING SYSTEM(自动处方配药，分类和包装系统)”，在此引用作为参考。
命令和控制处理器101与每个系统处理器通信，并提供一个界面，通过它显示、管理和处理关于例如系统队列、定单位置、系统资源和系统生产的实时信息。在替代实施例中，可使用分布式控制系统和/或并行处理系统。在本发明的另一个实施例中，命令和控制处理器101与除了系统处理器90、95和100之外的每个系统处理器通信。
工作流程处理器102与每个系统处理器通信，并指引定单流通过不同的系统处理器和工作队列。工作流程处理器102还给命令和控制处理器101提供信息。
成像的定单文件图2示出一个被本发明捕获的成像定单文件的屏幕捕获图。一旦被捕获，就可以以许多方式来操作成像的定单文件，例如，扩大或放大成像定单文件的选定部分；和同时观察成像定单文件的前面和背面，其中两个表面出现在图像显示器的分开区域。此外，成像的定单文件可直接接收注释。成像定单文件可被直接更新，以反映与开药者的讨论，如处方澄清和利用复核讨论。被直接注释的成像定单文件变为合法的处方。
定单处理流控制图3是一个高级控制流程图，示出通过本发明的定单处理方法的一个定单的整个流程的示例。病人分别在200和205以非电子格式(例如纸张)或以电子格式(例如无纸的)提交一个定单。在210，非电子格式定单的内容，例如被准备成像和成像。在215，随定单接收的付款被处理并被发送到储蓄帐户。不能成像或为了成像要求在220特殊处理的定单的内容可选地发送到在221的特殊处理区域。系统接收定单图像，并基于定单图像，通过填写对应于定单的至少一个数据域，定单在225进入到系统。根据本发明的一个替代实施例，在步骤205进入系统的定单被处理，而没有进行步骤225。根据这个实施例，不要求步骤225的定单包括，例如从IVRU、万维网、因特网和其它电子通信通道提交的处方替换。
在235通过传真通信通道接收的定单或定单相关信息在225被输入。如果确定在225定单完成步骤中定单图像是不能读取的或不能分辨的，则在226定单被发送到一个工作队列，以分辨图像。
在205接收的传真定单和随后的定单信息被传真服务器捕获并被复制到图像库，然后被发送到至少一个工作队列以进行处理。
一旦定单文件被成像并被系统接收，在230定单图像就被分配给至少一个工作队列。定单在工作队列中的位置至少部分取决于，例如(i)什么操作必须应用于定单以使定单从至少一个初始队列前进到定单发货队列；(ii)定单的优先级，其中优先级由用户或系统指定；和(iii)定单的目标发送日期，它部分基于例如定单的接收日期、客户和接收定单的通信通道。当在230生成和在240确定时，该方法应用所有必要的适用协议，以分解定单和使定单从至少一个初始队列前进到一个定单发货队列。加入的定单然后在250被复核，与成像定单进行对照。
在对照成像定单核实加入的定单后，该方法锁定处方数据不再接受进一步的更新，并在255打印一个对应于定单的标签组。通过锁定处方数据不再接受进一步的更新，用户从这点向前负责解释处方数据。标签组例如以传统的标签打印方式被打印，在这里标签首先被打印，然后被填充，或者一个电子数据流被发送到自动配药药房。例如参见美国5,771,657号专利，其标题为“AUTOMATIC PRESCRIPTIONFILLING，SORTING AND PACKAGING SYSTEM”，在此引用作为参考。标签组包括，例如实际的处方标签和任何其它与定单有关的病人信息。定单在260被配药，紧跟着就是核实步骤265，以确定是否配发了正确药物。紧跟核实步骤265是包装步骤270和自动生成药物清单275，然后是到病人的定单实际发货280。
根据本发明的一个实施例，在定单可被锁定和配药之前，需要分解所有协议。一旦所有协议被分解，一组发送逻辑规则就确定哪个药房或哪些药房将给处方配药。发送逻辑规则考虑例如，客户优惠计划、契约服务级别和配发药物的类型，比如它是否是一种受控制的药物或它是否是温度敏感药物并要求特殊运送预防措施。
根据本发明的另一个实施例，一个定单的配药顺序取决于定单的指定优先号。例如，优先号可基于客户契约服务保证来指定，其中与客户服务保证关联的定单具有比不与客户服务保证关联的那些定单高的优先级，因此被首先配药。
图4表示与接收定单的通信通道无关的本发明的方法的整个流程控制的高级示意图。在300定单被接收，并在305进入到系统。包含在定单中的处方在310被验证。验证步骤在315从至少一个数据库接收输入。验证步骤所涉及的数据库例子包括，例如临床数据库316、优惠计划数据库317、规则数据库318和/或联系数据库319。根据本发明的一个替代实施例，验证步骤所涉及的数据库例子包括临床数据库、计划数据库、规则数据库、联系数据库、应收帐款数据库、处方集数据库、定价数据库、客户简要描述数据库、病人历史数据库和它们的组合。
在验证处方之后，该方法在320检查是否存在定单的任何适用协议。如果任何协议适用，则在325，与至少一个数据库对照来分解适用的协议。分解步骤所涉及的数据库例子包括，例如，临床数据库316、优惠计划数据库317、规则数据库318和/或联系数据库319。根据本发明的一个替代实施例，协议分解步骤所涉及的数据库例子包括临床数据库、计划数据库、规则数据库、联系数据库、应收帐款数据库、处方集数据库、定价数据库、客户简要描述数据库、病人历史数据库和它们的组合。表1包括本发明能够分解的一些协议的示例。
在325分解所有的适用协议之后，定单在330被复核，以确定每个定单元素是否正确。正确的定单在335被发送到一个配药队列。根据本发明的一个重叠实施例，配药队列可位于与定单进入、核实处方、分解协议和定单复核步骤被完成的位置在地理上不同的位置。根据本发明的一个重叠实施例，定单进入、核实处方、分解协议、定单复核和发送到配药队列步骤中的每一个可在彼此地理上不同的位置执行。
图5示出分解应用于一个定单的协议所涉及的迭代过程。定单在350被接收，并在355被分配给至少一个初始队列。定单通过至少一个中间队列前进到配药队列，其中对于定单位于的每个队列，该方法在360确定，若有的话，什么协议应用于定单。该方法继续这个过程，直到所有适用协议在365被分解为止。该方法还提供一个正向控制机制，防止定单丢失或由于不能分解协议而被固定在任何单一队列中。当定单逗留在任何一个队列中超过预定的时间周期时，该方法在370发送一个警报。在365分解所有适用协议之后，定单被复核，以核对查看所有定单元素是否是正确的，如果正确，则在380被发送到一个配药队列。
标题输入图6描述标题输入(Header Entry)的流程控制示例。标题输入提供在定单域中输入与定单有关的非临床数据的各个步骤。在标题输入过程中核实和/或输入的数据通常来自于成像定单文件或其它电子和/或非电子定单文件。核实和/或进入过程包括在400复核成像定单文件或其它的捕获数据，以核对数据域或在要求的但目前空的数据域中输入数据。图8示出本发明的一个实施例的屏幕捕获图，其中成像定单文件与会员、地址和付款数据输入域并置。被输入标题中和/或核实的数据示例包括，例如，病人名字、开药者名字、发送地址、支付款额和/或信用卡号。每个定单图像在400被复核，紧跟是在405的图像分类。包含在定单中的每个文件在410被核实和说明。出现在一个定单中的处方总数在415被核实。每个处方在420复核，以确保它已被分配到正确处方分类中。如果没有处方分类出现，则在420输入。定单在425被核对以核实它已被指定了正确的优惠计划会员号、组号和子组号。如果没有优惠计划号码出现或仅出现部分号码，则在425输入这些号码。支付数额和类型在430被核实。如果没有提供支付数额和类型，则在430输入支付数额和类型。病人提供的通信信件在435被核实。如果没有输入病人通信信件，则在435输入病人提供的通信信件。根据本发明的一个替代实施例，如果没有提供病人通信信件，则该处理继续到步骤440，病人通信信件域为空。
一个处方要被更新或再配药的次数在440被核实。如果更新或再配药次数还没有输入，但更新或再配药次数在定单中出现，则在440输入更新或再配药次数。开药者名字在445被核实。如果没有输入开药者名字，则在445输入开药者名字。在本发明的一个替代实施例中，核实或输入开药者名字中的至少一个步骤额外包括下列步骤中的至少一个从一个将病人与他们的开药者匹配的历史列表中选择开药者；从开药者数据库中选择开药者；输入新开药者；或编辑现有的开药者信息。病人名字在450被核实。如果病人名字还没有输入，则在450输入病人名字。每个处方的处方发布日期在445被核实。如果处方发出日期还没有输入，则在455输入发出日期。在460核实和/或输入所有或预定集合的标题输入数据之后，定单在465被提交到一个工作流队列，以确定定单的下一个目的地。
邮寄定单的预处理流程控制图7A和7B示出当定单通过邮寄发送时，定单预处理的流程控制的一个示例。定单在500被接收。如果接收的定单不是一个邮寄定单505，则定单在510通过其它系统通信通道中的一个进入系统，并被恰当发送到标题输入(Header Entry)、定单完成(Order Completion)或协议。邮寄定单与其它接收的邮寄定单合并。包含定单的信封在520被撕开，在525被加盖日期戳。撕开的信封在530被捆扎为预定的大小。每捆然后在535被转换为一个纸张捆。在540，纸张捆内的所有适用文件上被放置条形码。纸张捆中的每个文件不必要适合接收条形码。文件接收条形码的合适性是基于预定的标准。
如果一个纸张捆内的文件在545不满足预定标准，则那个文件被发送到一个可选的异常处理区域，以确定，例如文件是否是假处方(在550)，是否是现金付款(在555)，是否是不可扫描的(在560)，或不可读的。如果定单在550被确定是假的，则定单在560被取消。如果定单是现金支付，则在570现金收据被填写一式两份，并且在575，现金支付连同其中一份现金收据放在储蓄帐户中。另一份现金收据在580被返回到其对应的定单文件。如果定单是不可扫描的，则创建、扫描表示不可扫描文件或包含在其中的信息的文件并返回到其对应的定单文件。能被扫描的异常处理文件在586利用平板扫描仪被扫描。
满足预定标准的纸张捆中的文件在585被排序，在纸张捆顶上放置一个捆首，每个定单之间放置定单隔离物，和在纸张捆尾端放置捆尾。有序的纸张捆在590被放置在例如一个折叠式文件夹中，并在595被复核组织的正确性。在成功复核纸张捆之后，纸张捆在600被扫描，且付款文件在600与定单文件分隔开。如果纸张捆在595被发现不在正确的顺序中，则纸张捆在545被发送到异常处理用于重排序。
扫描过程在605将一个纸张捆标识号附于每个纸张捆上，和在605将一个文件标识号附于纸张捆中的每个文件图像上。根据本发明的一个替代实施例，文件标识号包括儒略(Julian)日期和唯一的标识号。
扫描处理器最好是捕获定单文件的彩色图像并同时成像每个定单文件的两个面。
从纸张捆中捕获的扫描图像根据一个预定的复核进度表被复核。如果复核后，捕获的图像在610被认可，则在615图像被写入磁盘或其它计算机存储介质。同样，在认可图像之后，在600被分离出的付款在620被发送到一个储蓄帐户。然而，如果以前根据预定复核进度表复核的图像没有被认可，则纸张捆在600被重新扫描。
在610认可被扫描的图像之后，用于创建扫描图像的纸张捆在625被存档。纸张捆在625以对扫描的图像编索引的预定方式被存档，这样纸张捆在处理基于扫描图像的定单的过程中一直是可检索的。如果在基于扫描图像的定单的处理过程中需要访问纸张捆，则在630一个任务请求可以被提交，在635对纸张捆执行请求的任务。
对应于一个纸张捆中的所有文件的整个扫描图像组，在640基于一个预定的复核进度表进行质量控制而被复核。根据本发明的一个替代实施例，预定复核进度表是基于最近完成的被扫描的纸张捆的随机选取。如果在645选择一个纸张捆进行复核，该捆中的每个图像可以选择地被复核。如果在650该纸张捆通过了复核，在655该纸张捆在至少一个系统工作队列中排队以进行进一步的定单处理。在650没有通过复核的纸张捆被发送到在545的异常处理。没有被选择复核的纸张捆直接在至少一个系统工作队列中排队以进行进一步的定单处理。
定单完成图9描述包含在定单完成中的一般步骤的一个示例。定单完成步骤包括临床数据的核实和/或输入。核实和/或输入过程部分地包括，复核成像定单文件或其它捕获的数据以对照数据域来检查或输入数据。图12表示本发明一个实施例的屏幕捕获图，其中成像处方定单文件与药物选择数据输入域并置。在700从一个工作队列得到一个定单。在705确定病人信息是否正确。如果病人信息是不正确的，在710相应地更新病人信息。在715下一个药物信息被复核以确定它是否正确。如果该药物信息是不正确的，则选择正确的药物，相应地在720更新该定单。然后在725复核被指定的药物浓度。如果浓度是不正确的，则在730选择正确的药物浓度。然后在735确定关于药物的使用说明是否正确的。如果说明是正确的，在740选择正确的说明。通过人工输入相应的正确信息或通过从下拉菜单中选择正确信息可以改正任何不正确的输入。进一步，上面列出的步骤并不必须是以上述的顺序来执行。根据本发明的一个替代实施例，步骤715和对应的步骤720可以与步骤735和对应的步骤740互换。一旦所有的临床数据被核实和/或输入，就在745复核该特定处方的定单，以在750保证每个定单元素是正确的，因为定单元素和单个定单相关。如果特定处方的定单元素是不正确的，则重复步骤705至735直到正确。如果特定处方的所有定单元素是正确的，则在755为另外的处方而检查定单。如果另外的处方出现在同一定单中，重复步骤705至750，直到单个定单中的所有处方被分解。在完成一个定单中的所有处方和/或发现所有定单元素是正确的之后，在760定单被提交给配药队列。根据本发明的一个替代实施例，在760在给配药队列发出个别的处方之前，包含多个处方的定单不需要具有被处理的定单中的所有处方。
此外，根据本发明的一个替代实施例，定单完成过程中的每个步骤是由帮助用户完成定单完成过程的一组工具支持的。例如，这些工具包括一个药物使用说明的创建程序，它允许用户通过从至少一个下拉菜单词组和/或词汇中选择而创建药物使用说明；一个拼写检查器，和看上去/听起来功能上相似的药物。
协议协议是一组规则或集合的多组规则，它们用来分解定单的元素。一个协议的分解可导致需要分解另外的协议。例如，如果来自一个定单的元素丢失或不清楚，则协议用于丢失或不清楚的元素，并且跟踪元素的分解。跟踪包括，例如，指明哪个用户执行核实，与谁联系来分解元素。
根据本发明的一个实施例，本发明的方法和系统提供了帮助用户分解协议的一组向导程序和工具。向导程序引导用户一步一步地通过一个协议或过程，并显示如何分解一个特定协议。通过提供一系列的系统提示，向导程序预演协议的分解。工具包括，例如添加协议，它允许用户添加协议到一个定单；暂停定单，它允许用户暂时地终止定单的处理；停止/取消处方，它允许取消定单中的一个处方，同时仍允许定单中的其它处方继续；停止/取消定单，它允许用户完全地取消整个定单，撤出处方和插入，它允许用户在药物失去专利保护时来标记一个定单，以便在再配药时，同类品牌可用于再配药；新处方复制，它允许一个定单或处方被复制成新发货单；和定单复核，它允许立即进行定单复核。
联系管理图10描述联系管理的一般流程控制的一个示例。在800，做出关于任何适用协议是否适用的决定。如果一个协议适用，则在805确定在不联系开药者情况下是否可以分解该协议。如果没必要联系，在810分解该协议，和在810提交到用于进一步处理的一个工作队列。如果需要一个联系人以分解该协议，则在815做出一个决定，即关于给开药者发出的传真件是否将分解该协议或是否需要给开药者打电话。对于可以由发出的传真可选地分解的协议，在820可选地产生一个传真件，该传真填充有分解协议所必须的适当的域，一旦被填充，在820该传真件被发送给开药者。根据本发明的一个替代实施例，传真的发送启动了一个等待队列的运行，它测量从发送传真到从开药者返回联系之间的时间长度。在开药者回复联系开始之前，如果测量的时间超过一个预定值，则定单被放置于发出的呼叫队列。
如果需要电话呼叫来分解一个协议，在830联系请求被发送到一个发出的呼叫队列，在835安排一个呼叫。在840电话呼叫在预定时间被发给开药者，如果在845联络到开药者，发出呼叫的用户在850从虚拟架上检索具有待分解协议的定单。然后，在855用户以开药者要求的来自开药者的必要信息来复核定单，以分解协议。一旦在860协议被分解，定单在865被放置到工作队列中用于进一步处理。
替代地，如果发出一个电话呼叫，但用户在870没有收到回答，则定单返回到发出的呼叫队列，在835安排另一个呼叫——重复步骤835至845。如果在875发出一个电话呼叫，并给开药者留下一条消息，则更新发出的呼叫队列，以反映有消息留给开药者，在880设定一个预定时期，在这段时间内可以接收来自开药者的呼叫或其它通信。如果在885作出回复呼叫之前，超过了预定的时期，则可以安排另一次呼叫。
在885来自开药者的回复的电话呼叫或传真在890启动一个搜索的例行程序，以定位系统上的定单。如果来自开药者的回复呼叫在预定的时间内被收到，则在890定位系统上的定单，且该呼叫在850被传递给系统上的用户，该用户在850检索虚拟架上的定单。然后用户在855，以开药者要求的来自开药者的必要信息来复核定单，以分解协议。一旦协议在860被分解，定单在865被放置到工作队列中用于进一步的处理。
如果在885收到来自开药者的传真，该传真件被连接到定单，用户复核该传真件中包含的信息，以分解协议。协议分解之后，定单被放置到一个工作队列中用于进一步的处理。
可替代地，可以发出一个呼叫到联系人，而不经过发出呼叫队列的步骤。用户在870简单地选择联系人，和在875启动一个呼叫到选择的联系人，而不是发送定单到发出的呼叫队列。如果在880联系到了联系人，用户以联系人所要求的来自联系人的必要信息来复核定单，以分解协议。一旦协议被分解，定单就被更新，并被放置到一个工作队列中用于进一步的处理。如果没有联系到联系人，则定单被发送到发出呼叫的队列中。
传真联系管理图11表示传真联系管理的流程控制的一个示例。在900选择要分解的协议。在905分解协议所必需的域在传真件内填充。在910选择联系的人员。采取进一步的行动之前接收响应的时间在915被选择。在920做出决定，即是否发送人工传真或系统产生的电子传真。如果在925在选择的时间内从联系人员收到响应，则根据传真件包含的信息更新定单。通过这一过程接收的传真成为定单的一部分，根据接收传真的模式这一过程有所不同。如果传真件是手工的或纸张传真930，则定单在950是位于系统上，且传真中的信息在955被输入。然后手工或纸张传真件在960被扫描，并在965被插入到至少一个成像的定单文件或存档的纸张捆中的定单文件中。可替代地，扫描图像被插入到成像的定单文件和存档的纸张捆中。如果传真是电子版或从一个传真处理系统到另一个传真系统产生的，则基于传真中包含的信息更新定单，且接收的传真在970成为成像定单文件的一部分。
如果到达的手工或电子传真件，在选择的时间内没有被接收，则定单在975被发送到发出呼叫队列，随后是图10中的步骤830至845。如果为联系的一个发出传真被接收，但定单要求与联系人的实际联系，则定单在940被发送到发出呼叫队列。
图13A～13E表示图10和图11中的替代实施例，它们描述了根据特定协议分解的背景的联系管理的流程控制。在定单完成的过程中，复核定单以确定要求的处方元素是否出现。要求的处方元素代表处方的关键元素，其必须出现并对处方配药有效。如果要求的所有元素出现，定单就被复核。但是如果要求的元素没有出现，定单就被提交给至少另一个工作队列以进行另外的处理。然后做出决定即是否只有Alpha或“Routers，Counters，and Flags”协议仍未分解。Alpha协议被创建并被自动地分解和存在于每个定单中，直到定单准备被锁定以防止另外的定单编辑和被发送到配药药房。
定单完成包括分解属于定单的任何适用协议。如果不能通过根据关系数据库的检查而分解一个协议，则它可以在1025要求联系开药者或开药者的办公室里的人，以分解协议。如果在1025开药者联系对于分解一个适用协议是必须的，则定单在1030被发送到发出呼叫队列。在1035系统用户可以检索定单，在1040做出决定，即协议是否能够通过给开药者传真要被分解的重要协议而被分解。如果协议通过在1040给开药者发传真而可分解，则传真在1045被发给开药者。发送传真给开药者创建了系统内的一个时间标记。对照预定值从时间标记的时间在1050被测量。如果从时间标记测量的时间超过了一个预定的值，则传真等待时间超时，定单在1030被发送到发出呼叫队列，在其中重复步骤1030至1040。
然而，如果在1055到达的传真在预定值内被接收，则自动的匹配过程在被1060被启动，尝试把输入的传真与定单匹配，该定单产生一个原始的输出传真，输入的传真是对原始输出传真的响应。如果在1065发现定单，系统用户在1070把包含在输入传真中的信息输入到定单中。然后在1070定单被复核，并在1075提交给分解过程。可替代地，如果在1065通过自动匹配过程没有发现定单，则在1080定单通过标准的操作程序而被处理。标准的操作程序包括，例如用户对照系统上的定单的当前状态复核接收到的响应。例如，如果定单已被取消，就不采取进一步的行动。如果定单已经被传输给配药房，则被传真的响应与系统数据相比较，以确定正确的信息被处理。如果系统上的数据与传真的数据相同，则不采取进一步行动，但是如果存在差异，则定单被用户复核以进行进一步的处理和分解。在1056在从发送被测量的预定值内没有接收的响应，在1030被发送到发出呼叫队列。
如果到达的传真响应在1250在一个传真服务器上被接收，传真服务器就在1255基于传真响应标识发送响应到工作队列。所有定单对象在1260从工作队列中被检索，传真响应在1265被添加到定单。在1056在从发送被测量的预定值内没有接收的响应，在1030被发送到发出呼叫队列。
如果用户在1040通过发送传真给开药者确定协议是不可分解的，用户在1085通过在1090打电话给开药者而启动一个电话呼叫。在1095接通拨打的号码后，用户在1100尝试联系开药者或其他决策人。如果在1100联系上开药者或其他决策人，则用户在1105引入要被分解的协议，在1100把呼叫转移给药剂师。然后，呼叫转移跟随或与用户在1115放置定单以及把定单发送给药剂师同时进行。药剂师在1120从架子上获取定单和在1125与开药者一起复核插入项及分解协议。然后定单在1130被提交给一个工作队列以进行进一步的处理。
如果发出呼叫后在1095没有答复，则回电消息便条在1135被完成，且重新安排呼叫，相应地在1140更新发出的呼叫队列。在1145打印一个回电消息便条，在1030定单被发送到发出的呼叫队列。可替代地，如果呼叫要求答复，但开药者或其他决策人在1100不在，则在1150完成一个回电消息便条，定单识别信息在1150被留在开药者的办公室。发出的呼叫队列相应地在1140被更新。在1145打印一个回电消息便条，在1030定单被发送到发出的呼叫队列。
图13C表示当开药者在1155对通过发出的呼叫队列处理留下的消息做出响应时，开药者回电过程的一个示例。呼叫在1160被发送到用于回复的指定的搜索群。系统用户在1165接收呼叫，获得最初的信息。如果在1170开药者具有定单发货单信息，则系统用户在1175利用发货单号码或其它协议分解应用程序来检索定单。可替代地，系统用户在1180利用病人的姓从发出呼叫队列程序中检索生成的回电消息便条。先前定位定单的系统用户在1100把呼叫转移给药剂师。然后，呼叫转移跟随或与用户在1115放置定单以及把定单发送给药剂师同时进行。药剂师在1120从架子上检索定单和在1125与开药者一起复核插入项并分解协议。然后定单在1130被提交给一个工作队列以进行进一步的处理。
可替代地，如果适用协议可以在1190被一个管理协议分解，而不与开药者或开药者的办公室联系，则在1195可以把适用的管理协议应用于来自管理或规则关系数据库的定单。如果定单在1190不能通过应用管理协议而被分解，则在1200确定定单是否具有任何重要的呼叫给开药者或开药者的办公室，并且如果没有，那么定单在1205是否利用专业的协议关系数据库而被分解。在至少一个专业协议在1250已经被应用于定单的分解后，在1210确定与开药者或开药者办公室的联系是否对分解任何另外的重要适用协议是必须的。如果开药者呼叫在1215被确定不是必须的，药剂师在1220指出哪些定单项要被回答，且在1030发送定单到发出呼叫队列。如果确定呼叫是必须的，定单在1225被更新，并在1230被发送到一个工作队列用于进一步的处理。
然而，如果定单有一个给开药者或开药者办公室的重要呼叫与之关联，则定单在1050在一个等候队列排队，直到开药者或开药者办公室在指定的等候时间内响应，或直到定单在等候队列花费的时间超过预定值。
图14A～14E描述利用管理维护协议分解定单的一个示例。一个管理维护协议存在于专业协议中，且当治疗上等效的替代药物可用时出现。治疗上等效的替代药物的可用性带来一个“互换机会”。开药者可以通过电话或传真联系，以确定开药者是否将批准这一互换请求。
药剂师在1300复核编辑，在1305和在1310分别做出最初决定，即处方是通过屏幕显示出来或通过传真发送。如果处方是“屏幕显示出来(screen out)”，药剂师在1315按照每个标准操作程序分解定单，然后在1320发送定单到一个工作队列，以在1325进行进一步的处理。屏幕显示是由不足的系统资源或时间产生的，以寻求管理维护机会或互换机会。标准的操作程序包括，例如更新系统屏幕，指出定单没有被寻求作为一个互换。如果处方没有在屏幕显示出来，但代之以通过传真发送，则发送自动传真。接收呼叫回复或响应发出传真的其它联系的日期和时间在1330被添加到定单上。系统在1335被更新以反映已经发出自动传真，进一步分解定单。定单在1340被放在等候队列中直到在1343在预定的时间内接收响应，或在1350定单花费在等候队列的时间超过预定的时间。如果在1341定单花费在等候队列的时间超过预定的时间，定单在1400被发送到发出呼叫队列。
发出呼叫队列是针对不可通过传真发送的定单或定单花费在等候队列的时间已超过预定值的定单。在发出队列中的定单在1405由用户从队列中检索。在定单从队列中被检索之后，用户在1400呼叫定单开药者。如果发出的呼叫在1415被答复，用户就在1420尝试联络开药者或其他决策人。如果联系上开药者或其他决策人，用户在1425引入问题，如果在1430联系开药者的号码是安全的传真号码，用户在1435更新开药者的主文件信息，并在1325开始一个自动传真。
可替代地，如果开药者被联系的号码不是安全的传真号码，用户在1440转移呼叫到药剂师。与之同时或晚于给药剂师的转移呼叫，用户在1445发送定单到药剂师的虚拟货架。药剂师在1450从虚拟货架检索定单，在1455与开药者讨论要分解的协议。如果在1460一个呼叫回复是必需的，药剂师在1465在开药者联系跟踪屏幕和联系系统屏幕中输入呼叫回复的日期、时间和意见，在1470指定一个可见性协议添加，并完成呼叫回复消息便条。如果进行呼叫回复的时间在1475超时，则定单在1400被发送到发出呼叫队列，并重复图14C中的步骤1400至1415。
在1480在预定的时间内接收的输入呼叫在1485被发送到它们的呼叫回复的指定搜索群。一位非药剂师在1490接受呼叫，得到有关定单的初始信息。最初，非药剂师在1495尝试通过其发货单号码定位定单。但是，如果呼叫者没有发货单号码，非药剂师在1500就尝试利用病人的姓、呼叫回复消息便条或其它协议分解应用程序来定位定单。如果呼叫者没有发货单号码，非药剂师尝试利用协议分解程序来定位定单，如有需要，协议分解程序允许用户逐步通过各个屏幕。
图12A和12B根据本发明的一个替代实施例描述定单分解的一个示例，该定单具有附加在该定单的管理维护协议。根据该实施例，批准药物互换(转为通用的药物)发生在一个处方被处理之后。被批准的定单在系统上做出标记，以使药物互换在再配药时发生。对定单的编辑在1600被复核，以确定定单与处方集顺应性许可是否匹配。如果互换许可在1605在任何其它的药房是可用的，定单在1610被发送到一位管理员。该管理员在1615与其他管理员联系。指出处方集顺应性的传真在1620被接收。处方集顺应性信件被扫描，在1625被插入到定单中。定单在1630被发送到发出呼叫队列。在1635进行核实呼叫，如果互换在1640被核实，药剂师在1645在阴影文件中对处方加以说明，在1650在应用程序中手工输入非首选的处方，该应用程序打印法律所要求的病人和开药者的信件。该应用程序被称为半圆拱形活动房屋(Quonset hut)。处方集顺应性信件的传真的硬拷贝然后在1655被销毁，定单在1660被放到一个工作队列中，以进行进一步的定单处理。如果互换在1640没有被核实，定单在1655依据管理维护标准操作程序被处理，在1670被发到一个工作队列中，以进行进一步的定单处理。标准操作程序包括，例如当互换没被批准，并允许系统文件更新以使定单处理能够继续时，随后的人工程序。
但是，如果互换许可在1605是不可得的，在1675尝试匹配处方集顺应性信件。非首选的处方在1680人工地被输入到Quonset hut。处方集顺应性信件和处方硬拷贝在1685被扫描到系统中。被扫描的图像在1690被插入到其它图像定单文件中。定单在1695被放到一个工作队列中，以进行进一步的定单处理。原始的处方集顺应性信件在1700依据标准操作程序被撕碎。
图13A～13B根据本发明的一个替代实施例描述定单的协议分解示例，定单附有管理维护协议。协议在1900被添加到管理维护定单。在1905管理维护定单被复核以确定定单是否与最近的传真匹配。如果在1910互换许可存在于另一个药房，定单在1915被发送到管理员，该管理员随后在1920联系其他管理员。传真在1925被接收，最近的传真被成像，在1930被插入到定单图像定单文件中。然后定单在1935被发送到用于核实呼叫的发出呼叫队列中。核实呼叫在1940被执行，如果互换在1945被核实，处方的再配药以新处方号码在1950利用下拉和复制(PULLC/PULLN)功能被输入到系统中。下拉和复制功能把一个处方复制为一个新发货单。然后在1955定单被发送给一位药剂师，在1960根据管理维护标准操作程序处理互换。非首选处方在1965被人工输入到Quonset hut。在1970生成开药者信件，最近的传真复制件在1975按照标准操作程序被销毁。定单被放到一个工作队列中，以进行进一步的定单处理。如果互换在1945没被核实，定单在1946根据管理维护标准操作程序被处理。
如果在1910在另一个药房没有互换许可存在，定单在1916被发送给一位非药剂师，在1917最近的传真被扫描和成像。成像的最近传真在1918被附到成像的定单文件，且在1919对处方做出注释。处方的再配药带着新处方号码在1950利用下拉和复制(PULLC/PULLN)功能被输入到系统中。然后定单在1955被发送给一位药剂师并在1960根据管理维护标准操作程序处理互换。非首选处方在1965被人工输入到Quonset hut。在1970产生开药者信件，最近的传真复制件在1975按照标准操作程序被销毁。定单在1980被发布到一个工作队列，以进行进一步的定单处理。
命令和控制图17描述到命令和控制模块的信息可见度的示意图。命令和控制模块是位于命令处理系统之上的一个用户界面。命令和控制模块跟踪工作队列活动、单个用户活动、处理控制信息、系统生产和系统资源可用性。命令和控制模块能够在任何单个的队列或队列群中抽取信息，并通过标准的数据库查询工具对抽取的数据执行操作，以产生有关系统的任何单一方面或组合方面的状态报告。作为结果报告中的数据超链接到用于产生它们的底层数据。
图18描述仪表面板的一个示例，仪表面板是命令和控制模块的用户界面的一部分。图18描述包含仪表面板的一个屏幕，仪表面板表示所选择的系统队列的状态。仪表面板的量规指出出现在仪表面板中的每个选择队列的定量载荷。每个量规也通过其颜色提供每个被代表的队列的健康的指示。每个量规呈现的颜色的范围是预定的，并被选择以指出至少三种队列健康状态。第一种颜色指出，队列是健康的并且没有超载。第二种颜色指出告警，以及队列正在接近一个临界载荷点。第三种颜色指出队列已经超出其临界载荷点，系统必须调整以使载荷重新平衡，降低队列级别到一个可接受的操作范围内。
每个量规超链接到负责量规表示的底层数据。选择一个特殊的量规深入到代表量规的队列中的所有定单。在选择的队列内的定单可以被配置为显示在图19所示的图形中，或显示在图20所示的表格中，其中任何图形形式的纵坐标和横坐标或表格的行与列可以由用户通过许多变量来配置，以表示一个队列中的定单，这些变量包括，例如把从队列中最新到达的定单时间到同一队列中保持时间最长的定单之间的时间切割成预定的时间间隔，以显示队列中定单沿时间的分布。一个示例表示在图21中。
图19描述选择系统队列的一个图形表示。图19是一个条线图，其中每个条图表示一个特定的队列，条的高度表示队列中定单的数量。条线图中的每个条超链接到其底层的队列，且和底层数据的连接提供了选择的队列中的所有定单的清单。
图20以表格形式表示选择系统的队列，其中每个队列被分为包含在队列中的定单的种类或类型，在任何一个队列中的系统定单的总数，以及总的系统定单的百分比在任何一个队列中。队列种类包括，例如，定单是否是一个新处方、一个再配药处方或以上二者的混合，有多少定单是只有付款而没有定单，以及有多少定单是在混杂的所有类别中。表格项超链接到它们的支持数据，并允许用户连接或深入到底层的数据。
图22代表一个组合的屏幕，其中既提供了选择队列的条线图又提供了选择队列的一个表格。条线图中出现的队列并不必然是表格中出现的相同队列。
本发明的命令和控制模块也提供几种正向控制机制，用于跟踪定单处理系统中的定单。一种正向控制机制和本发明的一个替代实施例包括，每个系统队列确认从先前的队列接收一个定单，其中定单是立即被接收的。另一种正向控制机制和本发明的一个替代实施例包括当定单在一个特定的队列超过预定时间时，本发明的定单处理系统给用户发送一个警报或寻呼用户。正向控制也给用户提供在系统中定位任何定单和复核其经过药房或定单处理系统的路径的能力。在正向控制数据库中查询以复核定单的方式包括，例如，通过发货单号码、通过处方号码、通过会员号码和通过工作定单ID。始于上述信息中的任何一个，用户可以识别下面的内容例如定单当前所在的队列，定单曾处于的队列，定单在每个队列花费的时间量，以及定单已经在药房消耗的总时间。
本发明的命令和控制模块可以被配置为提供基于浏览器的功能，并能够在任何适合的个人计算机或工作站上操作。
网络配置图23表示根据本发明的一个系统的可能的硬件和网络配置。PC工作站2300连接到数据服务器2305，数据服务器2305连接到局域网(LAN)2310。数据服务器2305与LAN上的其它服务器以及一台主机系统2315通信，以给用户呈现工作例。也连接到PC工作站2300是一个生物测定捕获设备2316，它控制对PC工作站2300的访问，以及对数据服务器2305、LAN2310和系统主机2315的访问。一个光学扫描仪2320(它可以包括条形码读取能力)连接到图像服务器2325，图像服务器2325连接到LAN2310。工作流程服务器2330连接到LAN2310，管理定单流。光盘服务器2335和自动光盘机2340连接到LAN2310，用于图像存档。也连接到LAN2310的是关系数据库2345的一个系统，关系数据库2345识别系统处理逻辑。连接到LAN2310的组件的全部组合代表一个单个的HUB2350或定单处理中心。本发明的一个网络配置包括地理位置不同的HUB2351、2352和2353的系统，它们分别连接到一个中心系统主机2315。
分布式定单处理根据本发明的一个替代实施例，图1中的每个处理器执行的功能可以跨几个HUB(集线器)分布。例如，HUB1进行所有输入邮件的预处理和扫描，而HUB2负责输入所有非临床数据，HUB3只执行临床定单输入和/或核实。HUB4然后执行实际的配药和发货。可替代地，处理的任务可以基于前端任务和后端任务跨HUB分配。例如，单个HUB可以执行所有定单处理步骤，直到和包括发送定单到一个药房或多个药房，而第二个HUB将执行所有的定单配药和发货步骤。
可替代地，每个HUB将接收和处理来自其指定的地理区域的定单。例如，一个纽约HUB将接收和处理来自美国东北部各州的定单，而一个加州中部的HUB将接收和处理来自美国西南各州的定单。
本发明不限于包括处理医疗处方的应用，还可以应用于邮件定单业希望减少其对纸张文件和人工文件传送方法的依赖的任何情况。这里所描述的各种处理和流程图可以被改变和/或顺序上有所不同。
总之，应该强调的是，本发明的实施例的各种组件可以在硬件、软件或其组合中实现。在这些实施例中，各种组件和步骤将在硬件和/或软件中实现，以执行本发明的功能。任何现有的或将来开发的计算机软件语言和/或硬件组件可以在本发明的这些实施例中使用。例如，至少这里提到的一些功能可以利用C或C++程序语言来实现。
现在已经详细描述了本发明的优选和替代实施例。但是需指出，这些特定实施例的描述只是为了说明构成本发明概念的原理。因此，可以设想，在不背离本发明的精神和范围的情况下，公开的实施例可以有各种改变，这对本领域普通的专业人士是显而易见的。
主协议清单(按字母顺序)
砜膜。其优点是可以共价连接蛋白。反应结果与使用纤维素膜的结果类似。但是，我们发现超结合膜的表面不如纤维素膜平整，而且散射光非常强。此外，与纤维素膜不同，吐恩20不能有效地洗脱超结合膜膜表面非特异结合造成的背景。
玻璃和硅片都要求经过表面修饰后才能结合蛋白；与玻璃片相比，玻璃纤维滤膜和硅片的多孔结构可以提供更大的结合表面积，因此可以固定更多的蛋白。图1b所示的硅片曾用于过滤型基因芯片技术。但是，与修饰过的玻璃片类似，其疏水表面不适合与蛋白结合。而且，玻璃或硅片的表面修饰不稳定，也不容易保持各批产品间的一致性。
表1.比较不同蛋白结合表面
聚偏二氟乙稀(PVDF)也是免疫杂交中常用的膜。但是，它具有很强的疏水作用，需要用有机溶剂预先湿润后才可以结合蛋白，而打印过程中不可能保持这一点。尼龙膜具有较强的蛋白结合能力，但是也通常具有很高的非特异性背景。除多聚物膜外，聚丙烯酰胺也可以镀在玻璃片上来固定蛋白。珀金-埃尔默公司拥有对这一技术的专利。聚丙烯酰胺胶基质的缺陷是它机械强度非常差，需要用别的材料来加固。与这些材料相比，纤维素具有高的蛋白结合能力，高度亲水的表面，以及比较好的强度。
除了具有不同的机械性能，纤维素膜和硅片具有截然不同的微孔形态。图1中的电子显微镜结果表明，纤维素膜中的纤维结构是随机的(图1a)，而硅片中的微孔是垂直于滤片表面的(图1b[35])。实际上，纤维素膜和硅片通常分别被称作深度过滤器和膜过滤器。一般来说，深度过滤器允许较快的流速，而且不容易被大的颗粒
号为2和5上的漆含有2％的防粘添加剂，而桶号为3和6上的漆不含防粘添加剂。在桶中装入食品级的维生素E乙酸酯(BASF Aktiengesellschaft；PN 074099)。
将桶1、2和3在80℃的炉中加热约16小时。其后将桶从炉中移出，将内容物倒出，时间为1分钟。在再等候3分钟后，另外清空2分钟，然后确定残留量。
实施例15桶的维生素A棕榈酸酯的排空程度测试如上所述将每个净容量为25kg的钢桶(Gottlieb Duttenhfer GmbH &Co.KG，Hassloch，德国)涂上添加和未添加防粘添加剂的烘烤清漆Goldlack WL-105700(基于环氧化物(MG＞700)/酚醛树脂的内保护漆，制造商Rembrandtin Lack Gesellschzft mbH，维也纳，奥地利；编号210097；供给形式的漆)。桶号为1和4上的漆含有1％的防粘添加剂，桶号为2和5上的漆含有2％的防粘添加剂，而桶号为3和6上的漆不含防粘添加剂。在桶中装入ph级的维生素A棕榈酸酯1.6百万(BASFAktiengesellschaft；PN 073930)。将桶1、2和3在60℃下在炉中加热约16小时。其后将桶从炉中移出，将内容物倒出，时间为1分钟。在再等候3分钟后，另外进一步清空2分钟，确定残留量。
实施例16桶的维生素A棕榈酸酯的排空程度测试如上所述将每个净容量为25kg的钢桶(Gottlieb Duttenhfer GmbH &Co.KG，Hassloch，德国)涂上添加和未添加防粘添加剂的烘烤清漆
权利要求书(按照条约第19条的修改)117、一种处理医疗处方定单的系统，包括一个定单接收模块；一个定单成像模块；一个特殊处理模块；一个定单存档模块；一个定单输入模块；一个传真接收模块；一个定单分配模块；一个协议分解模块；一个数据核实模块；和一个发货模块。
118、一种处理医疗处方定单的系统，包括一个计算机网络；连接到所述计算机网络的一个主机；连接到所述计算机网络的至少一个集线器，所述集线器包括一个定单接收模块；一个定单成像模块；一个特殊处理模块；一个定单存档模块；一个传真接收模块；一个工作流程模块；一个协议分解模块；和一个发货模块。
119、一种用于至少一个医疗处方的定单处理系统，包括一个计算机网络；连接到该网络的一个计算机处理器；连接到该计算机处理器的储存器和内存，以存储定单、定单图像和软件模块；连接到该计算机处理器的至少一个扫描仪，用于扫描文件；
连接到该计算机处理器的通信链接，用于与用户通信；连接到该计算机处理器的至少一个显示器，用于显示定单图像；连接到该计算机网络的至少一个协议分解数据库；与网络进行通信的至少一台传真机；一个图像质量控制处理模块，存储在计算机可读存储介质中，所述图像质量控制处理模块在所述计算机处理器中是可执行的，配置所述质量控制处理模块以复核、接受和/或拒绝所述的至少一个扫描仪所捕获的图像；一个定单标题处理模块，存储在计算机可读存储介质中，所述定单标题处理模块在所述计算机处理器中是可执行的，配置所述定单标题处理模块以复核和接收与所述定单相关的非临床数据；一个定单完成处理模块，存储在计算机可读存储介质中，所述定单完成处理模块在所述计算机处理器中是可执行的，配置所述定单完成处理模块以复核和接收与所述定单相关的临床数据；一个协议分解处理模块，存储在计算机可读存储介质中，所述协议分解处理模块在所述计算机处理器中是可执行的，配置所述协议分解处理模块以分解与所述定单相关的适用协议；一个医生呼叫处理模块，存储在计算机可读存储介质中，所述医生呼叫处理模块在所述计算机处理器中是可执行的，配置所述医生呼叫处理模块以接收有关所述定单的信息；一个命令和控制处理模块，存储在计算机可读存储介质中，所述命令和控制处理模块在所述计算机处理器中是可执行的，配置所述命令和控制处理模块以监测和接收到所述系统的输入；一个定单配药模块，存储在计算机可读存储介质中，所述定单配药模块在所述计算机处理器中是可执行的，配置所述定单配药模块以给所述定单配药。
一个发货处理模块，存储在计算机可读存储介质中，所述发货处理模块在所述计算机处理器中是可执行的，配置所述发货处理模块以处理所述定单的发货清单。
120、一种用于为至少一个医疗处方自动处理定单的方法，该方法包括以下步骤a.接收所述定单，其中所述定单是通过一个预定的通信通道接收的；b.分配所述定单给至少一个队列，其中所述队列是从多个队列中选择的；c.处理所述定单，其中处理所述定单的所述步骤包括，执行必要的动作，以使所述定单通过至少一个中间队列从至少一个初始队列前进到一个最终队列，其中所述最终队列导致所述定单发货到病人；和计算一个定单什么时候需要被配药；其中计算步骤是基于接收定单的通道以及该病人的身份执行的，和用户从所述多个队列中访问任何一个队列是由用户的简要描述决定的。
权利要求
1.一种用于为至少一个医疗处方自动处理定单的方法，该方法包括下列步骤a.接收所述定单，其中所述定单是通过一个预定的通信通道接收的；b.分配所述定单到至少一个队列，其中所述队列是从多个队列中选择的；和c.处理所述定单，其中处理所述定单的所述步骤包括，执行必要的动作，从至少一个初始队列通过至少一个中间队列前进到一个最终队列，其中所述最终队列导致所述定单发货给病人。
2.如权利要求1所述的方法，其中每个步骤或其组合是在地理上分开的地点分布和执行的。
3.如权利要求1所述的方法，其中所述预定的通信通道是从至少下面的一个中选择的传真、电话、万维网、邮件或其组合。
4.如权利要求3所述的方法，其中所述预定的通信通道包括邮件，所述方法进一步包括在接收所述定单后预处理所述定单的步骤，其中预处理所述定单的步骤包括下列步骤a.打开邮件；b.准备扫描打开的邮件；c.扫描打开的邮件；d.复核打开邮件的扫描图像；e.存储打开邮件的扫描图像；和f.对打开邮件的扫描图像排队，以进行处理。
5.如权利要求4所述的方法，其中扫描打开邮件的所述步骤是利用高分辨率彩色扫描仪来完成的，其中所述扫描图像是彩色的。
6.如权利要求4所述的方法，其中准备扫描打开的邮件的所述步骤包括下列步骤a.给打开的信封盖上打开邮件的日期戳；b.集中打开的邮件成为纸张捆；和c.对所述纸张捆排序。
7.如权利要求6所述的方法，其中对所述纸张捆排序的所述步骤包括a.把条形码放到所述打开邮件的内容上；b.移走异常物品，其中异常物品是来自所述打开邮件的达不到预定标准的内容；c.插入定单隔离物；和d.插入捆首。
8.如权利要求7所述的方法，其中所述异常物品包括虚假的处方、用现金付款的定单和三维物体。
9.如权利要求7所述的方法，其中所述异常物品或所述异常物品的代表是利用一个平板扫描仪扫描的。
10.如权利要求6所述的方法，其中扫描打开邮件的所述步骤包括，分配一个标识号码给每个纸张捆，以及分配一个标识号码给作为纸张捆的一部分的每个文件。
11.如权利要求4所述的方法，其中复核打开邮件的扫描图像的所述步骤包括，选择接受或拒绝打开邮件的扫描图像的步骤，其中拒绝打开邮件的扫描图像导致重复步骤(c)和(d)直到接受了另外的扫描图像。
12.如权利要求4所述的方法，其中存储扫描图像的所述步骤包括把扫描的图像存储到计算机可读的介质中。
13.如权利要求12所述的方法，进一步包括以预定的方式存储所述打开邮件的步骤，以使所述打开的邮件被编索引为存储在所述计算机可读介质中的其对应的扫描图像。
14.如权利要求4所述的方法，其中扫描打开邮件的所述步骤包括从定单文件中分离出付款文件。
15.如权利要求1所述的方法，其中处理所述定单的所述步骤包括下列步骤a.接收和复核与所述定单相关的图像；b.分类与所述定单相关的每个图像；c.核实所述定单的详细内容；d.输入所述定单到一个处理设备中；e.验证所述定单；f.对所述定单应用至少一个协议，以使所述定单向前进行到所述最终队列；和g.在应用至少一个协议后，复核所述定单。
16.如权利要求15所述的方法，其中对所述定单应用至少一个协议的所述步骤包括下列步骤a.复核所述定单以确定是否要应用至少一个协议；b.当根据至少一个数据库应用协议时，分解至少一个协议；和c.重复复核所述定单以确定是否应用至少一个协议和根据至少一个数据库分解至少一个协议的所述步骤，直到协议被分解。
17.如权利要求16所述的方法，其中所述至少一个数据库选自于以下中的至少一个临床数据库、计划数据库、规则数据库、联系数据库、应收帐款数据库、处方集数据库、定价数据库、客户简要描述数据库、病人历史数据库和其组合。
18.如权利要求16所述的方法，其中复核所述定单以确定是否应用至少一个协议的所述步骤包括下列步骤a.决定联系人对分解所述定单是否是必要的；b.当联系人是必需时选择联系模式；和c.启动所述联系模式。
19.如权利要求18所述的方法，其中所述联系模式是从以下至少一种中选择传真、电话、电子邮件、万维网、邮件及其组合。
20.如权利要求18所述的方法，其中所述联系人是从至少下列之一中选择开药者、病人、计划管理人员及其组合。
21.如权利要求18所述的方法，其中当联系模式是至少一个传真时，启动所述联系模式的所述步骤包括下列步骤a.产生所述传真；和b.把所述传真发送给联系人。
22.如权利要求21所述的方法，其中产生传真的所述步骤包括下列步骤a.选择传真模式；b.选择至少一个协议；c.填充可用的传真域；d.选择联系人；e.选择从所述联系人接收响应的等候时间；
23.如权利要求22所述的方法，其中来自所述联系人的所述响应是传真或电话呼叫中的至少一个。
24.如权利要求23所述的方法，其中当来自所述联系人的所述响应是电话呼叫时，该方法进一步包括下列步骤a.发送所述电话呼叫到用于呼叫回复的一个指定的搜索群；b.从队列中检索所述定单；c.从联系人得到信息；和d.更新所述定单。
25.如权利要求23所述的方法，其中当来自所述联系人的所述响应是传真时，该方法进一步包括下列步骤a.通过自动匹配过程把所述传真匹配到所述定单；b.用所述传真上的信息更新所述定单；和c.把所述传真附到所述定单上。
26.如权利要求22所述的方法，其中当所述等候时间超过一个预定值时，所述方法进一步包括下列步骤a.发送所述定单到一个发出呼叫队列；b.安排一个呼叫；c.呼叫联系人；d.从发出呼叫队列中检索所述定单；e.与联系人复核所述定单；f.分解所述定单；和g.更新响应所述分解的定单。
27.如权利要求26所述的方法，其中当呼叫联系人的所述步骤不能联络上联系人时，呼叫联系人的所述步骤进一步包括下列步骤a.填写一个呼叫回复表；b.更新发出呼叫队列；和c.重复安排呼叫和呼叫联系人的步骤直到联络上联系人。
28.如权利要求18所述的方法，其中当联系模式是电话呼叫时，所述方法进一步包括下列步骤a.发送所述定单到一个发出呼叫队列；b.安排一个呼叫；c.呼叫联系人；d.从发出呼叫队列中检索所述定单；e.与联系人复核所述定单；f.分解所述定单；和g.更新所述定单。
29.如权利要求28所述的方法，其中呼叫联系人的所述步骤包括下列步骤a.引入非药剂师能够解决的问题；b.转移呼叫到一位药剂师；和c.发送所述定单到药剂师可访问的位置。
30.如权利要求28所述的方法，其中当呼叫联系人的所述步骤不能联络联系人时，呼叫联系人的所述步骤进一步包括下列步骤a.完成一个呼叫回复表；b.更新发出呼叫队列；和c.重复安排呼叫和呼叫所述联系人的步骤直到联络上所述联系人。
31.如权利要求1所述的方法，其中处理所述定单的所述步骤包括下列步骤a.把所述定单中的每个文件分类；b.核实所述定单中的每个文件；c.核实所述定单中的处方总数；d.为所述定单核实和输入处方分类中的至少一个步骤；e.核实和输入至少会员号码、组号码和子组号码之一中的至少一个步骤；f.核实和输入付款额和类型中的至少一个步骤；g.核实和输入病人提供的信件中的至少一个步骤；h.核实和输入更新和重新填入的号码中的至少一个步骤，如果这些号码出现的话；i.核实和输入开药者姓名中的至少一个步骤；j.核实和输入病人姓名中的至少一个步骤；k.核实和输入处方发出日期中的至少一个步骤；l.核实和更新病人信息中的至少一个步骤；m.核实和更新药物信息中的至少一个步骤；n.核实和更新药物浓度中的至少一个步骤；o.核实和更新药物说明书中的至少一个步骤；和p.核实所述定单的每个元素是正确的。
32.如权利要求31所述的方法，其中核实所述定单的每个元素是正确的所述步骤中，如果所述定单的一个元素不正确时，进一步包括重复步骤(l)到(o)。
33.如权利要求31所述的方法，如果所述定单是一个多处方定单，则进一步包括重复(l)到(o)的步骤。
34.如权利要求33所述的方法，进一步包括在完成所述多处方定单中的所有处方之前，给所述定单的一部分配药的步骤。
35.如权利要求31所述的方法，其中(m)至(o)的步骤包括一个定单注释创建程序，其中对所述定单的注释可从至少一个下拉菜单创建，其中所述至少一个下拉菜单包括注释选项。
36.如权利要求31所述的方法，其中用户能执行一个步骤或其组合的能力是由用户的简要描述决定的。
37.如权利要求1所述的方法，其中所述多个队列彼此通过正向控制机制来通信，其中所述正向控制机制允许所述定单通过所述自动处理而被跟踪。
38.如权利要求37所述的方法，其中所述正向控制机制在收到所述定单后发送一个确认到接收所述定单的一个先前队列。
39.如权利要求37所述的方法，其中所述正向控制机制跟踪所述定单花费在任何一个队列的时间长度。
40.如权利要求39所述的方法，其中当所述定单花费在任何一个队列中的时间长度超过一个预定值时，给用户发出一个警告。
41.如权利要求1所述的方法，其中用户对所述多个队列的任何一个队列的访问是由用户的简要描述决定的。
42.如权利要求1所述的方法，进一步包括一种计算定单什么时候需要被配药的算法，其中该计算包括加权接收定单的通道和病人的身份，以确定定单什么时候需要被配药。
43.一种为至少一个医疗处方处理定单的系统，包括一个计算机网络；连接到该网络的一个计算机处理器；连接到该计算机处理器的储存器和内存，以存储定单、定单图像和软件模块；连接到该计算机处理器的至少一个扫描仪，用于扫描文件；连接到该计算机处理器的通信链接，用于与用户通信；连接到该计算机处理器的至少一个显示器，用于显示定单图像；连接到该计算机网络的至少一个协议分解数据库；与该网络进行通信的至少一台传真机；一个图像质量控制处理模块，存储在计算机可读的存储介质中，所述图像质量控制处理模块在所述计算机处理器中是可执行的，配置所述质量控制处理模块以复核、接受和/或拒绝由所述至少一个扫描仪所捕获的图像；一个定单标题处理模块，存储在计算机可读的存储介质中，所述定单标题处理模块在所述计算机处理器中是可执行的，配置所述定单标题处理模块以复核和接收与所述定单关联的非临床数据；一个定单完成处理模块，存储在计算机可读的存储介质中，所述定单完成处理模块在所述计算机处理器中是可执行的，配置所述定单完成处理模块以复核和接收与所述定单关联的临床数据；一个协议分解处理模块，存储在计算机可读的存储介质中，所述协议分解处理模块在所述计算机处理器中是可执行的，配置所述协议分解处理模块以分解与所述定单关联的适用的协议；一个医生呼叫处理模块，存储在计算机可读的存储介质中，所述医生呼叫处理模块在所述计算机处理器中是可执行的，配置所述医生呼叫处理模块以接收有关所述定单的信息；一个命令和控制处理模块，存储在计算机可读的存储介质中，所述命令和控制处理模块在所述计算机处理器中是可执行的，配置所述命令和控制处理模块以监测和接收到所述系统的输入。
44.如权利要求43所述的系统，进一步包括一个定单配药模块，存储在计算机可读的存储介质中，所述定单配药模块在所述计算机处理器中是可执行的，配置所述定单配药模块以给所述定单配药。
45.如权利要求43所述的系统，进一步包括一个发货处理模块，存储在计算机可读的存储介质中，所述发货处理模块在所述计算机处理器中是可执行的，配置所述发货处理模块以处理所述定单的发货清单。
46.如权利要求43所述的系统，进一步包括一个输入的无纸定单处理模块，存储在计算机可读的存储介质中，所述输入的无纸定单处理模块在所述计算机处理器中是可执行的，配置所述输入的无纸定单处理模块以电子表格接收所述定单。
47.一种图形用户界面，用于输入、显示和实时管理一个存储在数据库中的处方定单实现系统，该处方定单实现系统包括用于分解至少一个定单元素的至少一个队列，该图形用户界面包括至少一个处理控制屏幕，其中至少一个处理控制屏幕各自包括至少一个可选择图标或域或其组合，图示描述至少一个定单元素中的一个；至少一个队列屏幕，其中至少一个队列屏幕各自包括至少一个可选择图标或域或其组合，图示描述集合中的至少一个定单元素；至少一个生产屏幕，其中至少一个生产屏幕各自包括至少一个可选择图标或域或其组合，图示描述至少一个定单元素中的至少一个生产元素；和至少一个系统资源屏幕，其中至少一个资源屏幕各自包括至少一个可选择图标或域或其组合，图示描述与至少一个定单元素有关的至少一个系统资源元素。
48.如权利要求47所述的图形用户界面，其中每个处理控制屏幕是具有多个域的一个搜索模板。
49.如权利要求47所述的图形用户界面，其中每个处理控制屏幕包括用于产生处理控制报告屏幕的一个图标。
50.如权利要求47所述的图形用户界面，其中每个队列屏幕是一个仪表板的图形表示，其中所述仪表板包括量规，其中所述量规指示多个系统队列的状态。
51.如权利要求50所述的图形用户界面，其中每个量规是可选择的，且选择的所述可选的量规从系统队列级的细节屏幕深入到单个定单级的细节屏幕。
52.如权利要求50所述的图形用户界面，其中每个量规是从多个队列中选择的，队列包括存档代理、向导、配药、文件室、管理协议、专业协议、标题输入、定单完成、通道服务、联系服务、客户服务、持有的定单、研究、发出呼叫应用程序、净化代理和队列再提交。
53.如权利要求47所述的图形用户界面，其中队列屏幕是一个条形图，其中所述条形图描述每个系统队列中的定单数量。
54.如权利要求53所述的图形用户界面，其中所述条形图中的每个条是可选择的，且选择的所述可选条从系统队列级的细节屏幕深入到单个定单级的细节屏幕。
55.如权利要求47所述的图形用户界面，其中每个队列屏幕是具有行和列的表格图形，其中所述表格包括包含有关系统队列的信息的项。
56.如权利要求55所述的图形用户界面，其中所述表格包括可选择的项，其中选择的所述可选项从系统队列级的细节屏幕深入到单个定单级的细节屏幕。
57.如权利要求55所述的图形用户界面，其中所述表格的所述行和列是用户可配置的。
58.如权利要求57所述的图形用户界面，其中所述可配置的列是配置显示定单在一个队列中的时间长度。
59.如权利要求47所述的图形用户界面，其中从所述表格选择一项连接到一个屏幕，其中所述屏幕包括与定单有关的信息，信息表示在所选择的表格项中。
60.如权利要求47所述的图形用户界面，进一步包括至少一个过滤器图标，其中选择的所述至少一个过滤器图标过滤出选择信息，选择信息表示在至少一个处理控制屏幕、至少一个队列屏幕、至少一个生产屏幕、至少一个系统资源屏幕或其组合中的任何一个。
61.如权利要求60所述的图形用户界面，其中所述过滤器是可配置的，并允许用户查看系统的另一个用户完成的所有定单。
62.一种处理医疗处方定单的系统，包括一个定单接收模块；一个定单成像模块；一个特殊处理模块；一个定单存档模块；一个定单输入模块；一个传真接收模块；一个定单分配模块；一个协议分解模块；和一个数据核实模块。
63.如权利要求62所述的系统，进一步包括一个打印处方定单标签组模块；一个产品分配模块；一个产品核实模块；一个产品包装模块；一个自动显示模块；和一个发货模块。
64.一种处理医疗处方定单的系统，包括一个计算机网络；连接到所述计算机网络的一个主机；连接到所述计算机网络的至少一个集线器，所述集线器包括一个定单接收模块；一个定单成像模块；一个特殊处理模块；一个定单存档模块；一个传真接收模块；一个工作流程模块；一个协议分解模块；和一个数据核实模块。
65.如权利要求64所述的系统，其中所述集线器进一步包括一个生物测定读取模块。
66.一种具有计算机可执行的组件的计算机可读介质，用于至少一个医疗处方的定单的自动处理，其中所述计算机可执行的组件为至少一个医疗处方处理定单，包括如下步骤a.接收所述定单，其中所述定单是通过一个预定的通信通道接收的；b.分配所述定单到至少一个队列，其中所述队列是从多个队列中选择的；和c.处理所述定单，其中处理所述定单的所述步骤包括执行必要的动作，通过至少一个中间队列从至少一个最初队列前进到一个最后队列，其中所述最后队列导致所述定单发货给病人。
67.如权利要求66所述的计算机可读介质，其中每个步骤或其组合在地理上分开的位置上分布和执行。
68.如权利要求66所述的计算机可读介质，其中所述预定通信通道是从至少下面之一中选择的传真、电话、万维网、邮件或其组合。
69.如权利要求66所述的计算机可读介质，其中处理所述定单的所述步骤包括a.接收和复核与所述定单关联的图像；b.把与所述定单关联的每个图像分类；c.核实所述定单细节；d.向处理设备输入所述定单；e.验证所述定单；f.对所述定单应用至少一个协议，以向前传送所述定单到所述最后的队列；和g.在应用至少一个协议之后，复核所述定单。
70.如权利要求69所述的计算机可读介质，其中对所述定单应用至少一个协议的所述步骤包括下列步骤a.复核所述定单，以确定是否要应用至少一个协议；b.分解至少一个协议，当该协议参照至少一个数据库被应用时；c.重复复核所述定单以确定是否应用至少一个协议和参照至少一个数据库分解至少一个协议的步骤直到协议被分解为止。
71.如权利要求70所述的计算机可读介质，其中所述至少一个数据库从以下至少一个中选择临床数据库、计划数据库、规则数据库、联系数据库、应收帐款数据库、处方集数据库、定价数据库、客户简要描述数据库、病人历史数据库和它们的组合。
72.如权利要求70所述的计算机可读介质，其中复核所述定单以确定是否应用至少一个协议的所述步骤包括下列步骤a.确定联系人对分解所述定单是否是必要的；b.当联系人必需时，选择联系模式；c.启动所述联系模式。
73.如权利要求72所述的计算机可读介质，其中所述联系模式从传真、电话、电子邮件、万维网、邮件和它们的组合中的至少一种选择。
74.如权利要求72所述的计算机可读介质，其中所述联系人从下列至少一种中选择开药者、病人、计划管理人和它们的组合。
75.如权利要求72所述的计算机可读介质，其中当联系模式是至少一个传真时，启动所述联系模式的所述步骤包括以下步骤a.生成所述传真；b.把所述传真传送给联系人。
76.如权利要求75所述的计算机可读介质，其中生成所述传真的所述步骤包括以下步骤a.选择传真模式；b.选择至少一个协议；c.填充可用的传真域；d.选择联系人；和e.选择等待时间，在等待时间内接收来自所述联系人的响应。
77.如权利要求76所述的计算机可读介质，其中来自所述联系人的所述响应以传真或电话呼叫的至少一种形式被接收。
78.如权利要求77所述的计算机可读介质，其中当来自所述联系人的所述接收的响应是一个电话呼叫时，所述计算机可执行组件进一步包括执行以下步骤a.把所述电话呼叫发送给指定的搜索群用于呼叫回复；b.从队列检索所述定单；c.从联系人获得信息；d.更新所述定单。
79.如权利要求77所述的计算机可读介质，其中当来自所述联系人的所述接收的响应是至少一个传真时，所述计算机可执行组件进一步包括处理所述响应的步骤，其中处理所述响应的步骤包括以下步骤a.通过自动匹配过程匹配所述传真与所述定单；b.利用所述传真上的信息更新所述定单；c.将所述传真附在所述定单中。
80.如权利要求76所述的计算机可读介质，其中当所述等待时间超过一个预定值时，所述计算机可执行组件进一步包括执行以下步骤a.把定单发送给发出呼叫队列；b.安排一个呼叫；c.呼叫联系人；d.从发出呼叫队列检索定单；e.与联系人复核定单；f.分解定单；g.更新定单，以响应所述分解。
81.如权利要求80所述的计算机可读介质，其中当所述呼叫联系人的步骤未能联络上联系人时，所述计算机可执行组件进一步包括执行以下步骤a.填写一个呼叫回复表格；b.更新发出呼叫队列；和c.重复安排一个呼叫和呼叫联系人的步骤直到联络上所述联系人。
82.如权利要求72所述的计算机可读介质，其中当联系模式是电话呼叫时，所述计算机可执行组件进一步包括处理所述响应的步骤，其中处理所述响应的步骤包括以下步骤a.把所述定单发送给发出呼叫队列；b.安排一个呼叫；c.呼叫联系人；d.从发出呼叫队列检索所述定单；e.与联系人复核所述定单；f.分解所述定单；和g.更新所述定单。
83.如权利要求82所述的计算机可读介质，其中呼叫联系人的所述步骤包括以下步骤a.引入由非药剂师能够解决的问题；b.把呼叫传送给一个药剂师；和c.把所述定单发送到药剂师可访问的位置。
84.如权利要求82所述的计算机可读介质，其中当呼叫联系人的步骤未能联络上联系人时，所述计算机可执行组件进一步包括执行以下步骤a.填写一个呼叫回复表格；b.更新发出呼叫队列；和c.重复安排一个呼叫和呼叫所述联系人的步骤。
85.如权利要求66所述的计算机可读介质，其中处理所述定单的所述步骤包括以下步骤a.把所述定单中的每个文件分类；b.核实所述定单中的每个文件；c.核实所述定单中的处方总数；d.为所述定单核实和输入处方分类中的至少一个步骤；e.核实和输入至少会员号码、组号码和子组号码之一中的至少一个步骤；f.核实和输入付款额和类型中的至少一个步骤；g.核实和输入病人提供的信件中的至少一个步骤。h.核实和输入更新和重新填入的号码中的至少一个步骤，如果这些号码出现的话；i.核实和输入开药者姓名中的至少一个步骤；j.核实和输入病人姓名中的至少一个步骤；k.核实和输入处方发出日期中的至少一个步骤；l.核实和更新病人信息中的至少一个步骤；m.核实和更新药物信息中的至少一个步骤；n.核实和更新药物浓度中的至少一个步骤；o.核实和更新药物说明书中的至少一个步骤；和p.核实所述定单的每个元素是正确的。
86.如权利要求85所述的计算机可读介质，其中当核实所述定单的每个元素是正确的步骤时，进一步包括当所述定单的一个元素不正确时重复(l)至(o)的步骤。
87.如权利要求85所述的计算机可读介质，进一步包括以下步骤重复步骤(l)至(o)，如果所述定单是一个多处方定单。
88.如权利要求87所述的计算机可读介质，进一步包括在所述多处方定单中的所有处方完成之前给所述定单的一部分配药的步骤。
89.如权利要求85所述的计算机可读介质，其中(m)至(o)的步骤包括一个定单注释创建程序，其中注释可从至少一个下拉菜单中获得，其中所述至少一个下拉菜单包括注释选项。
90.如权利要求85所述的计算机可读介质，其中用户执行一个步骤或其组合的能力由用户的简要描述来确定。
91.如权利要求66所述的计算机可读介质，其中所述多个队列包括一个正向控制机制，和其中所述正向控制机制允许通过所述定单的整个自动处理来跟踪所述定单。
92.如权利要求91所述的计算机可读介质，其中所述正向控制机制在收到所述定单之后向接收所述定单的前一队列发送一个确认。
93.如权利要求91所述的计算机可读介质，其中所述正向控制机制跟踪所述定单在任一队列中所花费的时间长度。
94.如权利要求93所述的计算机可读介质，其中当所述定单在任一队列中所花费的时间长度超过一个预定值时，给用户发送一个警报。
95.如权利要求66所述的计算机可读介质，其中用户对来自所述多个队列的任一队列的访问由用户的简要描述来确定。
96.如权利要求66所述的计算机可读介质，进一步包括一种计算定单什么时候需要被配药的算法，其中该计算包括加权接收定单的通道和病人的身份，以确定定单什么时候需要被配药。
97.一种为至少一个医学处方自动处理定单的方法，该方法包括接收所述定单的方法，其中所述定单通过一个预定通信通道来接收；将所述定单分配到至少一个队列的方法，其中所述队列从多个队列中进行选择；和处理所述定单的方法，其中处理所述定单的所述方法包括执行必要的动作以将所述定单从至少一个初始队列通过至少一个中间队列前进到最后的队列，其中所述最后队列导致所述定单发货给病人。
98.如权利要求97所述的方法，其中所述预定通信通道包括邮件，该方法进一步包括打开邮件的方法；准备打开邮件用于扫描的方法；扫描打开邮件的方法；复核打开邮件的扫描图像的方法；存储打开邮件的扫描图像的方法；和排队打开邮件的扫描图像用于处理的方法。
99.如权利要求98所述的方法，其中准备打开邮件用于扫描的方法包括给打开的信封盖上打开邮件的日期戳的方法；把打开邮件聚集成纸张捆的方法；对纸张捆排序的方法。
100.如权利要求99所述的方法，其中对纸张捆排序的方法包括在所述打开邮件的内容上放置条形码的方法；移除异常物品的方法，其中异常物品是来自所述打开邮件的不满足预定标准的内容；插入定单隔离物的方法；和插入捆首的方法。
101.如权利要求100所述的方法，其中所述异常物品包括虚假处方、用现金付款的定单和三维物体。
102.如权利要求99所述的方法，其中扫描打开邮件的方法包括给每个纸张捆分配标识号和给属于纸张捆的一部分的每个文件分配标识号的方法。
103.如权利要求98所述的方法，进一步包括以预定方式存储所述打开邮件的方法，以使所述打开邮件被编索引到其对应的扫描图像。
104.如权利要求98所述的方法，其中扫描所述打开邮件的方法包括把付款文件与定单文件分隔开。
105.如权利要求97所述的方法，其中处理所述定单的方法包括接收和复核与所述定单关联的图像的方法；把与所述定单关联的每个图像进行分类的方法；核实所述定单细节的方法；将所述定单输入到处理设备中的方法；验证所述定单的方法；将至少一个协议应用于所述定单以使所述定单向所述最后队列前进的方法；和在至少一个协议被应用以后复核所述定单的方法。
106.如权利要求105所述的方法，其中将至少一个协议应用于所述定单的方法包括复核所述定单以确定是否要应用至少一个协议的方法；当参照至少一个数据库应用协议时，分解至少一个协议的方法；和重复复核所述定单以确定是否应用至少一个协议，和参照至少一个数据库分解至少一个协议的所述步骤直到协议被分解的方法。
107.如权利要求106所述的方法，其中所述至少一个数据库选自于以下中的至少一个临床数据库、计划数据库、规则数据库、联系数据库、应收帐款数据库、处方集数据库、定价数据库、客户简要描述数据库、病人历史数据库和它们的组合。
108.如权利要求97所述的方法，其中处理所述定单的方法包括把所述定单中的每个文件分类的方法；核实所述定单中的每个文件的方法；核实所述定单中的处方总数的方法；为所述定单核实和输入处方分类中的至少一个方法；核实和输入至少会员号码、组号码和子组号码之一的至少一个方法；核实和输入付款额和类型中的至少一个方法；核实和输入病人提供的信件中的至少一个方法；核实和输入更新或重新填入的号码中的至少一个方法，如果这些号码出现的话；核实和输入开药者姓名中的至少一个方法；核实和输入病人姓名中的至少一个方法；核实和输入处方发出日期中的至少一个方法；核实和更新病人信息中的至少一个方法；核实和更新药物信息中的至少一个方法；核实和更新药物浓度中的至少一个方法；核实和更新药物说明书中的至少一个方法；和核实所述定单的每个元素是正确的方法。
109.如权利要求108所述的方法，进一步包括处理多处方定单的方法。
110.如权利要求109所述的方法，进一步包括在完成所述多处方定单中的所有处方之前给所述定单的一部分配药的方法。
111.如权利要求108所述的方法，进一步包括利用定单注释创建程序来注释定单的方法，其中所述定单注释创建程序从至少一个下拉菜单创建注释。
112.如权利要求108所述的方法，进一步包括限制用户访问可用队列的方法。
113.如权利要求97所述的方法，进一步包括，在自动处理过程中通过队列跟踪所述定单的方法。
114.如权利要求97所述的方法，进一步包括计算所述定单什么时候被配药的方法。
115.一种计算机可读存储设备，包含一个定单处理数据结构，用于为被用户界面切割程序访问的至少一个医学处方自动处理定单，该用户界面切割程序在计算机可读存储设备中被编码，并由数据处理系统中的处理器来运行，该数据结构包括多个条目，包括一个病人标识符；一个开药者标识符；至少一个药物标识符；一个会员标识符；一个定单标识符；其中用户界面切割程序访问该数据结构，以通过使用病人标识符、开药者标识符、至少一个药物标识符、会员标识符和定单标识符来处理所述定单。
116.如权利要求115所述的计算机可读存储设备，进一步包括一个支付标识符；其中所述用户界面切割程序访问所述数据结构，以通过使用病人标识符、开药者标识符、至少一个药物标识符、会员标识符、定单标识符和支付标识符来处理所述定单。
全文摘要
一个成像和工作流程方法、系统、计算机可读介质(10)和用户界面，用于有效地处理信息，以处理医疗处方定单(15、20、25)。该系统包括对文件扫描(40)、基于规则的自动定单处理、统计报告、文件产生、文件存储和检索的支持。本发明利用成像技术帮助用户把信息扫描到系统和软件模块中，以改进定单的处理。
文档编号G06F19/00GK1628308SQ02829054
公开日2005年6月15日 申请日期2002年4月30日 优先权日2002年4月30日
发明者S·M·赫尔姆斯, D·L·柔森, L·H·布瑞斯曼 申请人:麦迪柯健康方案公司