CN117083603A - 用于跨不同系统、平台和/或业务的过程协调和互操作的系统 - Google Patents

用于跨不同系统、平台和/或业务的过程协调和互操作的系统 Download PDF

Info

Publication number
CN117083603A
CN117083603A CN202080103315.2A CN202080103315A CN117083603A CN 117083603 A CN117083603 A CN 117083603A CN 202080103315 A CN202080103315 A CN 202080103315A CN 117083603 A CN117083603 A CN 117083603A
Authority
CN
China
Prior art keywords
pipco
resource
agent
participant
participants
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202080103315.2A
Other languages
English (en)
Inventor
K·那拉亚南
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
K Nalayanan
Original Assignee
K Nalayanan
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by K Nalayanan filed Critical K Nalayanan
Publication of CN117083603A publication Critical patent/CN117083603A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/258Data format conversion from or to a database
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02ATECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE
    • Y02A90/00Technologies having an indirect contribution to adaptation to climate change
    • Y02A90/10Information and communication technologies [ICT] supporting adaptation to climate change, e.g. for weather forecasting or climate simulation

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • General Health & Medical Sciences (AREA)
  • General Business, Economics & Management (AREA)
  • Medical Informatics (AREA)
  • Epidemiology (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Biomedical Technology (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Detergent Compositions (AREA)
  • Train Traffic Observation, Control, And Security (AREA)

Abstract

一种用于跨不同系统、平台和/或业务的过程协调的系统,其捕获并允许分析并最终重构过程特定交互,以在特定行业领域内的各种业务过程中的所有参与者之间提高效率。该系统包括:(1)过程规范语言,其识别领域的参与者、资源、代理和过程步骤的术语;(2)规范存储库,其存储参与者、资源、代理和过程步骤的信息;(3)过程知识引擎,其识别和跟踪相关过程步骤;以及(4)执行引擎,其执行过程步骤,管理代理的证书,并且更新规范存储库。

Description

用于跨不同系统、平台和/或业务的过程协调和互操作的系统
技术领域
本发明涉及一种提供通用过程互操作平台的系统,其被设计为协调、捕获、允许分析并最终重构过程特定交互,以在特定行业领域内的各种业务过程中的所有参与者之间提高效率。本发明将用参与者对平台交互代替点对点参与者交互,以允许更大的过程透明度并允许分析和重构。尽管该系统具有广泛的适用性,但其对于涉及以不同的技术平台操作的多个参与机构并且过程本身具有与标准生产线不同的复杂流程的过程特别相关。
背景技术
业务过程和互联网
过去二十年来全球通信技术的进步和互联网的兴起已使得企业运营的方式发生了许多改变。具体地:
·通信成本的降低和数字信息存储库的越来越多的使用已使得可快速地提供信息而不依赖于物理方法。这使得许多企业的产品和营销材料的交付急剧地改变。
·许多现有服务的提供已被简化并且变得更可靠。因此,例如,以前通过邮件或电话进行的账单支付现在在线进行。需要物理签名和邮件的文档验证现在可通过数字签名进行。
·用户友好的图形接口可用于大量在线信息已导致虚拟业务的兴起。Amazon之所以存在是因为互联网已使得虚拟商店成为可能。
·由于互联网而成为可能的新型交互方式已使得许多新的业务出现。因此,Google作为一种允许用户在互联网上搜索信息,同时向其销售定向广告的方式而出现。Ebay和Facebook则作为使用互联网的工具进行协调的合理方式出现。现有企业必须调整其过程以利用这些新的场所。因此,Google和Facebook如今是巨大的广告门户。许多企业直接通过Ebay来销售。
毫无疑问,互联网代表了一场颠覆性技术变革,其正在缓慢但稳步地重塑众多关键行业和社会。尽管大多数企业认识到了这些变化的本质,但很少有企业有强有力的战略来应对它们。因此,跨行业的众多公司一直在为“数字战略”而挣扎,没有完全认识到这种战略将牵涉什么。鉴于通信技术的进步速度以及新的、颠覆性的技术新创企业有充足的资金,老牌公司在数字战略上举步维艰并不奇怪,能预料到技术的变化以及可能随之而来的业务结构的相关变化确实有难度。更糟糕的是,新通信技术的激增意味着诸如区块链的全新概念的引入,这些概念的意义甚至没有被技术本身所很好理解,更不用说企业、社会了。通常,老牌企业已逐渐采用互联网技术,但其方式没有使其充分利用这些发展的力量。因此:
·已改变现有业务过程步骤以包含一些新技术。因此,通过实体邮件发送的账单现在被电子邮件通知所取代,以前通过电话进行的信用卡支付现在通过在线门户网站进行,等等。然而,很少有企业尝试以可用的新技术工具箱重新思考其整个过程框架。
·已创建新的过程来应对最新技术所导致的问题。因此,在线记录访问意味着需要更好的备份技术以及应对诸如黑客和病毒的新威胁的措施。这需要所需技术专长的显著改变,从公司内使用的更陈旧系统转向更先进的框架。
尽管互联网技术的传播速度很快,企业内的技术变革的步伐相对缓慢。这是完全可以理解的,因为很少有公司愿意为了业务过程的往往边际的改进而承担新技术的可能无法量化的风险。一些行业内的真正破坏通常来自于新的竞争对手,他们在尝试激进的新方法时没有现有商业特权可失去。
因此,尽管Amazon不断取得成功,大多数零售商在在线呈现方面仍迟缓,难与Amazon匹敌。现有零售商十年前缺少稳健互联网呈现所需的技术基础设施,这使得Amazon得以快速增长。如今,他们很可能能够在零售方面复制Amazon的在线呈现,但是缺少Amazon为其在线活动所开发的库存管理、仓储和交付的相关业务过程。如今令人惊讶的是,Amazon的市值大于零售业中的所有商店(包括Wal-Mart)的总和。
零售业中发生的颠覆性变革很可能也在其它行业中发生,如果不是已经发生的话。持续的技术变革是不可避免的,随着时间推移,接受新方法和过程来改进效率的公司很可能主导其相应行业。变革的速度越快,公司就越需要适应。
技术影响领域
我们可区分技术影响公司的两个广泛领域。首先,有些过程是公司内部固有的,公司对其有完全控制。这些任务通常由公司自己的员工或代理执行。其次,我们有外部程序,因为它们涉及代理,包括以既定方式与公司交互的顾问、供应商、服务提供商和客户,而不受公司完全控制。
公司牢牢掌握其内部过程,并且通常大量投资以改进其效率。事实上,即使在互联网兴起之前,最好的公司也在改进这些内部方法,并且随着技术进步一直在继续这样做。
然而,典型的公司几乎没有能力影响它与之交互的外部代理。首先,这些代理(包括公司的客户、供应商等)不受公司的直接控制。其次,公司在其自身业务的相对有限的背景下与这些代理交互。因此,它无法全面了解其总体业务和客户,更不用说其技术需求。这种情况的罕见例外出现在例如大批量制造的情况下,其中外部供应商被迫参与供应链门户网站,以便能够应对单个大客户。
然而,公司的外部过程决定其收入和最终盈利能力。没有客户,公司将没有销售。没有供应商,它可能没有产品可制造或销售。互联网给公司带来的许多颠覆性变革来自于外部渠道。因此,Amazon开始是虚拟书店,其网络门户网站优于Barnes&Noble和Wal-Mart。最初,它缺少Wal-Mart的库存技能、购买力和内部技术。然而,凭借其网络呈现和过程的优势,它已摧毁了Barnes&Noble,并成为Wal-Mart自身的可信威胁。随着时间推移,Amazon允许其内部业务以支持其关于仓库选址、交付时间表等的外部过程的方式演进。即,其外部过程交互已向内渗透到公司中,使其成为零售业中一股不可忽视的力量。
许多企业已有效地使用了技术优化其内部过程,但对其与外部代理(例如其客户、供应商和服务提供商)的交互几乎没有控制。此外,几乎所有外部交互均是点对点的。因此,任何一个代理或团体均不可能在不付出相当大努力的情况下全面了解交互的结构。随着业务过程中代理数量的增加,交互的数量呈多项式增长,以使得这些交互中的每一个的优化并不会降低过程本身的复杂度。
颠覆性过程重整
互联网和相关技术的发展使得可按照在没有互联网的情况下将不可能的方式来重新思考和重整代理的外部交互。众多新创公司恰好已实现了这种目标,即使其实际并非为此目的而创建:
·Ebay允许个人和公司拍卖原本可能卖给特定转售商的商品。在互联网之前这可能也是可能的(例如通过在线公告板),但Ebay让大众更容易做到这一点。
·Facebook允许个人群体简单地通过创建兴趣小组和允许成员共享信息来交互。在其创建之前,这种交互必须通过点对点通信或群电子邮件来实现。
·Dropbox和类似的替代物允许跨用户共享文件,在一些情况下带有版本控制和共享编辑。
·Salesforce允许公司以标准方式与其自己的在途销售人员交互,这在没有互联网的情况下是不容易实现的。
上述所有公司有一个共同特性。它们各自是为大量提供特定功能而设计的。
为了充分利用当前技术,企业将不得不将一系列技术产品(例如上述产品)集成到其自己的独特数字平台中。上述构建块的存在使得开发某些业务功能更容易,但其造成了集成麻烦。企业将不得不投资于使产品(例如上述产品)在其环境中无缝工作的技术,更糟糕的是,随着技术及其软件提供商改变,将不得不继续投资。如今不存在用于简单地跨相关业务的各种不同操作平台的数字集成平台。
总之,我们可关于技术和业务过程得出以下结论:
·技术变革正在发生,并且不可逆转且不可避免。
·很少有企业有强有力的战略来管理技术变革。接受错误的技术在商业特权和成本方面均存在相当大的风险。然而,不改变可能意味着更灵活的竞争对手可能威胁到你的存在。
·互联网允许(如果不是强制的话)业务过程从外到内的改变。适应不断变化的外部技术环境的需求迫使重新思考内部过程。
·新技术和软件包激增。然而,可根据需要并入新技术以服务业务需求的技术不可知、灵活的框架并不存在。
发明内容
本发明应被称为过程互操作平台(“PIPCO”),是提供通用过程互操作平台的系统,其被设计为协调、捕获、允许分析并最终重构过程特定交互,以在特定行业领域内的各种业务过程中的所有参与者之间提高效率。
PIPCO是独特的系统,其充当过程枢纽,以通过用点对枢纽交互取代代理之间的点对点交互来解决业务过程的复杂度。然而,该系统与传统交易所或其它平台的不同之处在于,其对于其参与者而言本质是增量过程集成系统。因此,其通过首先为其参与者提供最基本集成服务来操作,但随着时间推移,允许它们将越来越多的功能迁移到该系统中。PIPCO系统的设计允许关键业务过程的增量标准化,同时也允许其参与者继续使用其大部分(如果不是全部的话)已有技术。
PIPCO系统提供了显著的理论和实践效益。在涉及n个代理的传统(点对点)过程中,在最坏情况下,代理交互的通道数量将以n2的速率增长。另外,修订m次的单个文档可生成最坏情况存储要求,其是初始文档大小的m*n倍。PIPCO系统通过代理对平台通信取代过程中的代理对代理交互。PIPCO系统还可从单个位置存储和/或引用文档,并且维持原始文档的更改历史,而非每一次都重新存储。PIPCO系统可减少过程交互通道的数量,以使得它们仅按因子n增长,或者在最坏情况下线性增长。PIPCO系统还可将文档存储要求降低至作为初始文档的大小(加上修订历史)的恒定因子,而非传统过程流程中生成的最坏情况mn个副本。
PIPCO系统广泛适用于诸如医疗保健、保险和全球贸易的各种行业。PIPCO系统服务于其它系统无法提供的关键功能。PIPCO系统是强大的“水平”集成枢纽,其允许参与者将行业范围的系统和技术组合以满足其一些核心的跨技术和跨代理协调需求。PIPCO系统还允许他们以在功能和时间方面均适合其需求的方式增量地这样做。然而,随着时间推移,PIPCO系统将允许参与的企业将其许多过程迁移到该系统,并且最终以其自己独特的方式转变其过程流程,以允许最高的效率和有效性。
PIPCO系统允许将不同的技术集成到可适应各个企业的特定需求的内聚框架中。PIPCO系统具有以下特性:
灵活。该系统的设计允许(如果不是鼓励的话)将新技术和方法容易地并入其框架中。该系统的焦点是使得业务过程步骤易于集成,使用最优的技术来进行。
增量。其提供了以有限的功能开始,然后根据需求添加特征的能力。因此,该系统不是外部交互的完整解决方案,它是用于以适合于所讨论的代理的速度映射外部过程的框架。
可定制。各个参与者(及其相关代理)将具有其自己独特的需求。该系统被设计为易于定制并适应各个参与者类型,并且根据需求与其常驻系统一起工作。这不是一刀切的解决方案。
成本高效。参与者的主要成本将在于挂钩到PIPCO系统上所需的初始集成和努力。预期一旦运营,参与者的成本节约将是切实且明显的。
智能。该系统收集过程流程数据。因此,其提供了研究领域内的过程流程所需的原始信息。这继而可用于达到可能使参与者受益的过程改进和修改。
PIPCO系统中的各种参与者可有两大类:
·完全属于公司内部的实体,例如业务单位和部门。当在这种背景下使用时,PIPCO系统可用于在企业内传递增量过程变更,从而增强或替代现有技术和过程。
·完全在公司外部的实体,例如供应商、客户、服务提供商等。与这些参与者,PIPCO系统可协调公司的外部事务,这些事务通常在其现有内部系统内未捕获。这些事务将包括电子邮件、估价、消息、文档、批准、修订等。
尽管PIPCO系统可在单个大型公司/企业的有限环境中有效地使用,但是当其用作给定行业/领域内的一些、许多或所有公司/企业的外部事务的主要集成平台时,才展现其真正的力量。在这种情况下,PIPCO系统可用于构造、标准化并最终流线化公司/企业与其外部对应方之间的整个交互过程。
当用于集成行业/领域中的外部事务时,PIPCO系统表现出显著增加的规模利益。登录该系统的参与者越多,可集成到框架中的方法和事务的数量就越大,并且可部署的新技术也越多。因此,规模越大,所有参与者的效率增益和成本节约将越大。
PIPCO系统的设计是技术不可知的。PIPCO系统没有推送“正确”的技术。相反,该系统使用对于给定行业/领域最有意义的最优技术,目的是随着更好的替代方案可用而更换技术。为了允许各种新技术的这种集成,该系统的设计在许多方面是真正前沿的。
最后,PIPCO系统的设计既是自上而下的也是自下而上的。建立该系统需要大量自上而下的行业过程知识以及基于技术变革来规划理想化的过程的意愿。然而,PIPCO系统的实现本质是自下而上的。该平台开始于跨领域内的行业参与者提供简单的协调功能,但是可快速地演进以得到显著增加的规模利益,从而接管整个行业/领域。这将在下面变得越来越清楚。
示出PIPCO系统的一般概念的示例
查看一个简单的非技术示例,可更好地理解PIPCO系统的业务过程重构方法。
考虑工业区内的多个小型制造企业,其通常有原材料运给它们,反过来将其成品邮寄给其客户。为了简单,假设这些公司全部通过能够处理其体量的其本地邮局来接收和发送其产品。来自企业的货物必须被打包,运输到本地邮局,并与适当的保险和交付确认请求一起邮寄出去。为此,各个企业委派一名或多名员工。
假设货运承揽商进入该区域以帮助这些企业处理其包裹。一开始,承揽商签订合同以从每家企业收取包裹,确保相关文书工作正确地完成,并且将包裹连同正确的付款一起及时交付到邮局。作为奖励,承揽商在月末提供企业记录的所有装运、支付价格和交付日期的日志。
为了提供这些服务,承揽商雇佣一小群专门且有学识的货运员工,购买能够处理所有货运和交付的卡车车队,并且构建必要的计算机系统,以记录和跟踪各个企业的包裹。如果所有企业均与承揽商签约,则最有可能以远低于企业自己做时的价格提供服务,因为其拥有其客户所缺少的专业知识和规模。承揽商最初进军此业务过程的重点在于提供服务,这种服务具有明显(虽然较小)的切实利益,但范围有限,因此出错的可能性很小。重要的是,各个企业与我们的承揽商签约几乎没有成本,并且将很快认识到这种新服务是否奏效,如果与承揽商其净成本(针对效益调整)实际上更高,则它将简单地拒绝使用后者的服务。
在与其客户签约之后,我们的智能承揽商可趋向于为其基本包裹业务增加更多价值。具体地,它可能很快就了解,许多企业会向另一工业区货运,并且可与邮局或另一独立货运商协商大宗折扣以统一发送这些包裹。这是各个公司永远不可能知道的,但积累了过程知识的承揽商可了解并利用这一点。重要的是,如果承揽商适当地协商,则其非常有可能赚取可观的利润,同时甚至允许其客户得益于略低的价格。
但是承揽商不必止步于仅仅降低其客户的货运成本。基于打包,可能认识到其一些用户有复杂的打包要求,需要昂贵的包装材料。因此,其可通过两种方式之一来帮助这些企业:其可批量采购包装材料并以较低的成本将它们交付给客户;另选地,其可完全接管公司的打包过程,而且考虑到其自己执行此操作时的较大规模,很可能以远低的成本完成它。
再进一步,随着时间推移,承揽商可能会为其客户公司处理所有国际海关文书工作、原材料和产品的仓储,并且可能担任外包采购和交付经理,甚至处理付款。事实上,随着新特征和交付可能性可用,承揽商将尝试将它们并入其平台中,以为其客户提供最大效益。
我们的示例带来的重要特征如下:
·承揽商起初以低成本和切实效益提供基本服务,并且不会给其客户带来中断。
·所提供的任何新服务由企业自行决定,因为相对于成本,效益显而易见。承揽商通常可按照远低于企业自己做时的成本提供这些所需服务。
·企业从承揽商获得的服务针对其需求有效地定制,企业无需承担其不需要的服务。
·可合理地向各个企业保证,承揽商将是充分利用当前最佳实践的货运和物流专家。因此,它可依靠承揽商来使用可能最佳和成本最低的方法来处理企业物流。
·随着时间推移,大量使用承揽商服务的企业最终显著但增量地转变其内部过程。因此,增量内部变革以低成本进行,每一步均有明显的效益,并且内部反对或下行风险很小。
将承揽商称为PIPCO货运将使说明更切实。从PIPCO货运的角度,提供其客户企业当前和未来可能需要的所有服务将需要大量规划和技术。需要了解业务领域以及当前和未来要提供的服务的性质。更重要的是,需要以业务和技术平台来操作,其将允许逐步集成其客户的业务服务。客户也将使用同一平台来获取与其业务过程有关的信息,因此承揽商必须将其客户也并入该平台中。另外,PIPCO货运必须不断地从其自己的过程数据学习需要集成哪些新技术和过程以向其客户提供更好的服务。
显而易见,PIPCO系统是PIPCO货运用来执行上述战略的核心集成平台。通过该平台,PIPCO货运可增量地重整其客户的过程,以实现其集聚效益。此外,这种重整在每一步以低增量成本和最小的业务中断进行。更重要的是,有效地使用该平台来设计自己的定制集成解决方案,各个企业仅采用它从PIPCO货运实际所需的服务。简单地通过将我们的工业区中的企业一起整合到该高级技术平台中,PIPCO货运能够协调其活动并为每个人节约成本。
本发明的PIPCO系统包括以下四个主要组件:
·过程规范语言,可用于指定特定领域的过程步骤、代理等。
·规范存储库,其定义原子过程元素、各种代理及其特定能力、权限以及理解过程所需的其它设置信息。因此,规范存储库将具有各种代理身份和证书的映射、关于各种资源的位置的数据等。
·过程知识引擎,其定义过程步骤的实际排序,并且维持PIPCO系统所跟踪的各个过程的当前状态。过程知识引擎的排序利用以过程规范语言编写的规范来布置。
·执行引擎,其执行为每一个参与者指定的实际过程步骤,使用系统中为此维持的各种映射来管理访问和安全,并且更新过程知识引擎中的过程状态。
附图说明
本发明的优选实施方式是为了例示和描述而选择的,并且示出于形成说明书的一部分的附图中,其中:
图1提供了本发明的PIPCO系统的一般概述。
图2示出本发明的PIPCO系统的四个主要组件。
图3示出PIPCO系统的规范存储库的各种功能。
图4提供了PIPCO系统的一些功能的示例的概述。
图5示出医疗保健领域中的一些原子资源定义。
图6A示出图5的医疗保健领域中的各种原子资源的资源层次结构。
图6B示出医疗保健领域中分解为较低层次的原子资源的原子资源。
图7示出医疗保健领域中的一些基本/原子代理定义和代理/角色层次结构。
图8示出由PIPCO系统跨不同参与者的身份映射。
图9示出过程知识引擎,特别是用于创建PIPCO系统的过程映射的各种层。
图10以抽象术语示出用于过程知识引擎的过程(事务)映射的过程定义层。
图11示出医疗保健领域中的过程定义层的示例。
图12从一个角度示出医疗保健领域中的关系和对象层的示例。
图13示出区分医疗保健领域中的不同对象层的示例。
图14示出本发明的分散式PIPCO系统,其具有PIPCO中央系统和多个PIPCO本地系统。
图15示出一起工作以应对医疗保健领域中的事务的PIPCO中央和本地系统的示例。
图16是医疗保健领域中的各种原子代理之间的现有技术过程流程的示意图。
图17是图16的PIPCO系统重整的就医的示意图。
图18是一个银行事务的现有技术过程流程的示意图。
图19是图18的PIPCO系统重整的贸易融资的示意图。
图20是PIPCO系统重整的贸易过程的示意图。
图21是保险索赔结算的现有技术过程流程的示意图,示出仅针对索赔的一方发生的交互。
图22是PIPCO系统重整的保险索赔过程的示意图。
具体实施方式
以下描述中使用了以下术语,下面提供了其一般含义:
·实体是个人、公司、组织、单独可识别存在的企业或者较大实体内的组织单位或部门
·参与者是使用PIPCO系统或与之交互的实体。有时,当我们提到参与者时,我们意指代表参与者的一组代理。这应该从上下文清楚。
·代理是PIPCO系统内的特定角色。代理的概念对应于PIPCO系统的具有某些明确定义的能力的用户的概念。代理在PIPCO系统中以其定义的角色代表参与者行动。
·行业(或领域)由在特定区域中一起工作/彼此交互的一组实体形成。例如,医疗保健、保险、全球贸易等。
·资源是指可由PIPCO平台中的参与者(或其代理)或平台本身执行或提供的功能、数据元素或操作。因此,资源的概念对应于动作及其所有相关数据。
提供了标号的索引和对应元件:
标号 元素
100 PIPCO系统
101 PIPCO中央系统
102 PIPCO本地系统
105 参与者
200 过程规范语言
300 规范存储库
305 原子资源
306 资源
307 资源映射
309 代理角色映射
310 资源层次结构
311 身份映射
313 证书映射
315 原子代理
316 代理
317 代理/角色层次结构
319 过程步骤/事务
321 过程步骤/事务层次结构
323 知识数据库
400 过程知识引擎
404 过程定义层
405 过程映射
407 关系层
409 对象层次结构层
411 代理类
413 事务类
500 执行引擎
如图1所示,PIPCO系统100是智能过程助手,其通过协调各种代理316之间为了执行这些功能所需的所有过程交互来在给定行业领域所特定的一组业务过程中帮助所有参与者105。PIPCO系统100是基于网络的过程枢纽,其必要时和根据需要将所有参与者105(以及代表其行动的代理316)高效地且有效地彼此连接。PIPCO系统100不具有确切地决定需要进行哪些改变以改进过程所需的高级智能,而是允许收集信息以允许执行这种功能。一旦决定了任何改变,PIPCO系统100就可被指示实现它们,就像生产线中的低级工作人员(或智能机器人)一样。因此,PIPCO系统100是原始智能,其可应对它必须应对的众多代理所生成的大量过程流程信息,同时可编程以在数据复杂度和过程步骤方面均实现更大的功能。设计PIPCO系统100相当于设计简单的大脑,其需要具有处理信息、存储状态和随时间推移积累知识的能力。
如图2所示,PIPCO系统100可被视为由四个主要组件组成:
·过程规范(或领域编程)语言200。这是设计用于允许PIPCO系统100的所有组件(代理、过程步骤、访问规则等)的识别/规范,并且布置实际过程步骤的排序和逻辑的语言。这种语言高度特定于PIPCO系统100提供过程协调的领域。
·规范存储库300。为了使PIPCO系统100提供过程协调,需要知道过程的原子细节。需要了解过程步骤319是什么、它们如何执行、参与者是谁、他们的角色、权限以及其它设置信息。这些细节由规范存储库300维持。没有该信息,PIPCO系统100甚至无法开始执行其功能。
·过程知识引擎400。PIPCO系统100必须了解过程步骤319的总体排序,以及维持当前过程状态的概念以提供协调。需要跟踪在其系统上从启动到完成的任何事务。从监测该过程流程获得的信息允许PIPCO系统100确定每一个参与者在给定过程中做了什么,并且随后分析整个过程的效率。因此,PIPCO系统100的过程排序和状态引擎实际上是系统的意识大脑,其为系统提供了智能以用于实现过程协调。
·执行引擎500。这是PIPCO系统100的一部分,其实际实现各种过程协调步骤,在规范存储库300中布置规则和映射以驱动其行为。换言之,执行引擎500是执行由作为大脑的过程知识引擎400指示的功能的主体。执行引擎500的活动由过程知识引擎400记录并最终研究。执行引擎500的行为由以过程规范(或领域编程)语言200编写的代码驱动
过程规范语言200
过程规范语言200是设计用于允许整个PIPCO系统100的规范和编程的领域特定编程语言。至少,该语言将允许定义以下所有内容的高级过程映射的规范:
·PIPCO系统100试图建模的过程的各种步骤是什么以及如何为这些步骤中的每一个执行各种系统功能。
·代理在过程中是谁以及其在各个过程步骤中的角色。
·在将其指定的过程步骤并入平台框架中以及创建、访问和改变驻留在PIPCO系统100中的信息的能力方面,代理如何与PIPCO系统100一起工作。
过程规范语言200必须是PIPCO系统100为了过程协调操作的领域/行业所非常特定的。它必须足够灵活,以支持各种代理316和过程流程规范。还需要支持高级过程步骤319,以允许容易地检查规范。因此,例如,在医疗保健领域中,语言需要能够指定高级操作,例如从医院访问特定格式的病历、转换放射图像以便以特定格式查看、等。
将调用PIPCO系统100的规则语言以定义大量潜在代理316和过程步骤319。另外,单个代理或过程步骤必须可变为多个子单元。例如,在医疗保健领域,随着时间推移,单一医院代理可拆分为众多代理,这些代理是单个医院的分部或下级工作人员。同样,内部运作最初不为PIPCO系统100所知的单个过程步骤随着时间推移可拆分为一组子步骤。考虑到这一设计要求,PIPCO系统的语言必须支持代理和过程步骤的分层定义,随着时间推移,其可轻松重新定义为更小的实体组。
规范存储库300
规范存储库300提供基本知识(构建块)以便于PIPCO系统100提供过程协调。
规范存储库300提供以下问题的答案:
·PIPCO系统100在其所选领域中将为参与者做什么(在特定过程步骤或事务319方面)?PIPCO系统100框架中的每一个过程步骤319被当作资源的访问。因此,规范存储库必须确切地定义可通过PIPCO系统100访问哪些资源,这相当于布置可提供哪些功能。
·PIPCO系统100应该如何提供特定请求的资源或服务?为此,PIPCO系统100需要了解所请求的资源或服务在哪里以及如何通过PIPCO系统100来交付它们。
·PIPCO系统100中的参与者105及其授权代理316是谁?PIPCO系统100需要了解各种参与者105、其在系统中的代理/角色以及其访问所定义的各种资源的权利。此外,这些代理316需要具有适当证书以指示PIPCO系统100执行其选择的功能。
如图3所示,规范存储库300执行以下功能:(1)通过(a)标准化资源定义并(b)构建资源位置映射307来识别对于特定领域资源在哪里以及是什么;(2)优化如何向参与者105提供资源(包括识别过程步骤319并将过程步骤319分配到事务/过程步骤层次结构321中);以及(3)通过(a)基于参与者组织内存在的角色为各个参与者内的代理创建层次结构和角色映射309,(b)利用身份映射311调和参与者的代理在PIPCO系统100中的其它参与者105处可能具有的多个身份,并且(c)创建用于资源访问的证书映射313来确定哪些参与者105/代理316可访问哪些资源。
资源(什么和哪里)
PIPCO系统100是虚拟云平台,其向所有参与者105提供过程资源的公共接口,不管它们来自哪里以及它们使用了什么内部系统。PIPCO系统100是对各个参与者105可用的所有资源提供无缝操作访问的中间件层,其中术语资源涵盖功能以及数据。通过创建用于资源操作访问的公共框架,无论它们位于哪里或者它们由什么第三方子系统提供(在我们的讨论中,等同于用于执行过程步骤的公共框架),PIPCO系统100可跟踪整个过程流程,从而可改进总体效率。
如图4所示,代理X 316在4-01请求的资源R 306可能在4-02驻留在另一参与者A105内部的系统上。然而,当X在4-03被认证到PIPCO系统100中时,他需要能够访问A的系统中他有权的资源R 306,就像它们实际上由PIPCO系统100维持一样,针对参与者A处的资源R认证X的过程及其向X的交付必须对X透明,并且将在下面进一步描述。
为了提供对资源的访问,PIPCO系统100必须:(a)跨参与者标准化资源定义;以及(b)构建资源位置映射307。
跨参与者标准化资源定义
在跨许多参与者的大多数自组织过程中,定义资源(无论是过程步骤还是数据单元)的内容本身跨参与者105也不一致,并且可变化很大。资源可以是文本文件、视频、约定、语音呼叫等,或者更复杂的概念,例如程序、检验摘要或索赔备份。不同的参与者105对于各种资源通常具有不同的访问协议和证书。然而,当资源定义在过程中未跨参与者105标准化时,因为没有过程步骤是什么的概念,所以无法提供任何过程协调。
PIPCO系统100解决这一问题的方法是开发资源306的公共层次结构310,其统一了跨所有参与者105使用的资源模型。为此,PIPCO系统100的规范存储库300执行以下功能:
1.在领域的框架中使用参与者105宇宙所使用的最细粒度资源元素来定义PIPCO系统100的原子资源305是什么。这里重要的是要注意,并非所有参与者105均将在其内部资源中实际以这种粒度级别工作,这意味着PIPCO系统100可能必须将其内部聚合资源概念拆分为更原子的框架。
2.出于访问、安全和功能目的,将这些原子资源305组织成逻辑层次结构310。设计这种层次结构的预期是PIPCO系统100中的大多数参与者105将发现其资源概念对应于层次结构310中的某一或某些级别。我们在此层次结构中越高,资源概念就越复杂。
3.将跨所有参与者105使用的资源定义映射到领域的该框架中,以使得当引用PIPCO系统100的上下文中的特定资源时,尽管其可具有任何内部定义,其跨任何参与者105指同一项。
随着PIPCO随时间推移扩展其过程知识,上述资源框架在需要时可向上(创建更复杂的资源分组和访问层次结构)和向下(创建更原子的资源定义)扩展。
图5示出医疗保健领域中的一些原子资源定义,其中有三个参与者105:医院A、成像设施B和实验室C。各个参与者105对其认为的原子资源305有不同的概念。医院A具有医案的总体概念,其被拆分为图像、检验和就诊,没有超出该框架的附加粒度。与医院A相比,成像设施B和实验室C对图像和检验二者具有更细粒的概念,将这些拆分为CAT扫描、X射线、血液检验和尿液检验的类别。PIPCO系统100从各种参与者105处使用的资源创建原子资源定义。PIPCO系统100的定义步骤涉及首先将框架的(初始)原子资源305识别为CAT扫描、X射线、血液检验、尿液检验和就诊。PIPCO系统100然后以这些原子资源305开始将各个参与者105的资源组织成资源层次结构310,认识到并非所有参与者105均可内部具有或需要所有这些原子资源305。PIPCO系统100还可能必须为具有这些资源但在内部以更高聚合级别以其操作的参与者105创建这些原子资源305。例如,医院A以图像类别进行操作,但在概念和实现二者中,PIPCO系统100将其拆分为子类别。即使医院A内部不以这些类别进行工作也是这样,以确保医院A可正确地与PIPCO系统100的框架中的其他参与者105一起工作。
图6A示出图5所示的各种原子资源305的资源层次结构310。PIPCO系统100为来自各种参与者105的原子资源305构造层次结构310。医院A、成像设施B和实验室C对其各自的资源和访问/使用层次结构全部有不同的定义和术语。在如图5所示的先前步骤中建立了原子资源集合305之后,PIPCO系统100然后按特异性增加的顺序为原子资源305(例如医案、医学研究和医疗元素)建立层次结构310。参与者105之间使用的原子资源定义305和层次结构310可在一些情况下略微改变术语,而在其它情况下(类似医院A)需要大量努力才能映射到PIPCO系统100框架中。例如,对于没有识别出适合资源层次结构310中的某些级别(类似医案)的对应资源306的某些参与者105(类似成像设施B),PIPCO系统100以适当的访问逻辑来为参与者105创建这些资源306。
随着时间推移,还应该注意到,PIPCO系统100的资源定义可能随着资源306被拆分为原子性增加的级别而改变。图6B示出一个原子资源305(即,病历)可如何随时间推移被拆分为较低层次的原子资源305(例如,医案、处方记录等)。
预计各个参与者105将仅支持PIPCO系统100的原子资源305的子集,并且可将其资源仅映射到PIPCO系统100的广泛原子资源305的一部分和资源层次结构310。然而,PIPCO系统100的框架为跨所有参与者105的资源提供的逻辑组织是过程协调的基本前提条件。由于存在其资源映射307(将在下面进一步讨论),PIPCO系统100可参与从各个参与者105处使用的各个资源概念抽离的许可和访问的全过程设置。在下面的讨论中,原子资源使用标号305,一般的资源(无论是原子的还是我们的资源层次结构310中更高的)使用标号306。
由于PIPCO系统100将所有数据元素和功能视为资源,并且过程步骤319被定义为对这些资源的访问(我们也可以认为是对这些资源执行的操作),所以创建资源层次结构310相当于定义通过PIPCO系统100平台可用的每一个最后功能和数据元素。资源层次结构310中的资源306(原子的和其它)仅是PIPCO系统100知道并且可通过其框架处理的资源。重要的是,该资源层次结构310足够全面,以支持PIPCO系统100中的所有参与者105的需求。
构建资源位置映射
一旦参与者105在特定过程实例的上下文中对彼此可用的各种资源被识别并归类为原子资源305(更一般地,使用资源层次结构310的资源306),就需要定位它们,以使得它们可被PIPCO系统100中的其他参与者105访问。PIPCO系统100在其规范存储库300中构建可识别参与者105内和跨参与者105的特定系统的资源位置映射307,其存储相关元素并布置访问方法以及证书系统,代替认证这种访问。
构建资源映射307是PIPCO系统100中的重要步骤。PIPCO系统100所做的分析是研究给定参与者105的设置内内部使用的协议,如何最好地定位和访问这些参与者105的资源306。该资源映射307的初始建立主要是手动过程,但是可通过当前广泛使用的文档版本控制和规范技术来方便其维护。应该注意,由于并非所有参与者105均将必然支持PIPCO系统100所使用的所有原子资源305概念,所以资源映射307将必然支持原子资源305以及资源层次结构310中更高的资源306。
标准关系数据库、对象数据库或其它数据库可提供表结构,并且还可支持快速访问这些原子资源305所需的层次结构310。对于给定领域,可识别/定义数千原子资源305。然而,这些数字对于任何现代数据库引擎而言都是微不足道的负载。
如何向参与者提供资源
利用资源映射307知道资源是什么和在哪里并没有使PIPCO系统100解决如何访问资源并将其交付给PIPCO系统100上请求它们的参与者105的问题,以及为实现这一点过程步骤319是什么。资源映射307中标识的各种资源306可通过使用不同证书的各种协议来访问。为了允许PIPCO系统100访问资源306,为资源306(根据需要原子的和高级的)提供访问器/操作器,其取得适当的参与者105证书,根据需要将其应用于各种参与者105所维持的资源存储库,然后将资源306交付的格式解析为PIPCO系统100可从其提取更新其过程状态以及管理向请求参与者105交付资源306所需的信息的结构。
例如,过程步骤319为了从医院以健康级别7临床文档架构标准(HL7-CDA)交付的医疗事务中获得事务标签,PIPCO系统100必须进行以下所有操作:
·连接。PIPCO系统100提供到交付该HL7-CDA记录的医院系统的连接器,其中它可自动发送请求参与者105的证书以用于认证以访问该资源。例如,用于此的协议可能涉及复杂的多级认证。
·请求。PIPCO系统100在使用用于识别该资源306的正确医院定位符认证之后请求适当的资源,这意味着它需要将其资源位置映射307转换为对执行引擎500的精确指令。
·解析。PIPCO系统100解析返回的资源306以提取信息,在这种情况下意味着解析HL7-CDA文档以提取适当的事务日期、标签以及与PIPCO系统100相关的其它细节,以便于正确地记录事务。这需要提供相对复杂的解析器,其不仅理解HL7-CDA格式,而且可应对交付报告的特定医院以此格式引入的站点特定代码。在所交付的资源306对于访问代理316不够“原子”的情况下,PIPCO系统100必须对其进行处理以将其拆分为期望的形式,以使得仅交付资源305的适当原子部分。
各种资源访问器是专门设计的,可能有第三方组件,以便于经由PIPCO系统100在各种操作平台之间无缝集成和交换信息。访问器必须依靠PIPCO系统自己的身份定义和映射来适当工作。
向谁提供资源
PIPCO系统100定义了被允许使用它的所有参与者105的代理316,并且确切地指定了各个代理在PIPCO系统100上可以做什么。PIPCO系统100还具有适当认证/证书机制以允许各个代理316执行他/她被许可的功能,考虑到其将涉及可能具有自己的代理、角色和安全概念的多个参与者子系统。因此,即使PIPCO系统100了解在技术方面如何提供访问,它也需要能够管理谁或哪个代理316可获得这种访问的机制。PIPCO系统100通过提供层次结构和角色映射309、身份映射311和证书映射313来实现这一点。
代理层次结构和角色映射309
PIPCO系统100为其平台中的各个代理316定义角色。这些角色基于PIPCO系统100正在协调的过程来定义,并且必须足够细粒以允许过程所需的各种级别的访问和协调,但足够简单以允许总体过程理解和分析。最细粒角色将是PIPCO系统100中的基本/原子代理315的角色。在PIPCO系统100中建立基本/原子代理315定义的过程与上面讨论并示出于图5的原子资源305定义的过程非常相似。用于建立基本/原子代理315定义的过程比用于原子资源305定义的过程更简单,因为在操作领域中的给定过程中涉及明显的逻辑参与者。
PIPCO系统100将原子代理定义315并入更复杂的代理316定义的层次结构中。层次结构中更高的代理316具有层次结构(其分支)中在其之下的代理316的所有能力以及较低代理316所缺少的一些附加能力。原子代理定义315确保了存在足够细粒的(原子)角色集合,其将允许通过将它们插入到代理/角色层次结构317中的适当位置来对将使用PIPCO系统100的各种实际代理316的能力和权限进行适当建模。因此,PIPCO系统100通过基于给定代理316在代理/角色层次结构317内的位置而建立的简单规则来控制许可和访问。用于创建代理/角色层次结构317的过程与图6A和图6B所示的建立资源层次结构310之后的过程相似。代理/角色层次结构317根据其位于层次结构中的何处来定义PIPCO系统100中的所有代理316的访问级别,并且其适当定义对于PIPCO系统100的正确起作用至关重要。在我们随后的讨论中,原子代理的概念使用标号315,一般代理(原子的或层次结构中更高的)的概念使用标号316。
图7示出医疗保健领域中的一些基本/原子代理315定义和代理/角色层次结构317,其中有两个参与者105:医院A和诊所A。与原子资源305类似,各个参与者105具有不同的代理316,其将是PIPCO系统100的原子代理315。PIPCO系统100基于领域中的参与者105内的各种代理316(在此示例中,只是护士和医生的两个基本代理315)来创建基本/原子代理315定义。在此示例中,各个代理316在各个参与者105处以不同名称的角色(从PIPCO系统100的角度)进行操作。例如,医院A处的医疗提供方是医生,但在诊所A处是护士。同样,诊所A甚至没有医生角色/代理,医院A没有定义护士角色/代理。PIPCO系统100建立诸如组织、高级提供商和提供商的代理/角色层次结构317,并且将参与者105处的各个角色重新映射到代理/角色层次结构317中以进行过程协调。为了简单,图7示出PIPCO系统100内映射有这些内部参与者105角色的单个代理/角色层次结构317。在完全实现中,代理/角色层次结构317可具有多个分支以应对各个参与者105内的多个功能和角色。
不容易与这种分层视图相吻合的安全框架根本无法适应PIPCO系统100,对于平台而言将导致过于复杂。
在PIPCO系统100中指定角色和许可代理是可在任何计算机系统中容易地实现的简单过程。然而,PIPCO系统100面临的问题在于,其过程角色可能不容易或根本无法映射到参与平台的各个参与者105内的特定内部角色。为了跨其平台的一致性,PIPCO系统100根据其自己的代理角色定义来定义其安全框架。然而,PIPCO系统100的各个参与者105将有可能基于其访问方的标识而具有其自己的内部安全框架。由于角色和身份必然不同,所以清楚的是,PIPCO系统100必须通过创建身份映射311和证书映射313来将其自己的身份和角色映射到等同角色/身份,以访问其各个代理316的各种资源306以及用于访问的适当证书。
调和多个身份的身份映射311
协调外部过程时的最大问题之一在于,当涉及到用户或者更一般地诸如文档的资源的标识符时参与者105通常不会同意。尽管多个文档身份可能造成文档冗余的困扰,但是关于用户身份的分歧将意味着任何过程协调均将不可能,我们无法在对行动者是谁存在分歧的情况下协调过程。因此,创建过程交互的中央枢纽需要我们跨参与者105统一各种参与者105以及可能时甚至各种资源306的身份,只要这些资源是诸如文档的物理资源306。在每个人都需要实现的系统中(比如政府强制),这种身份统一相对简单,尽管向其的过渡会较棘手。在这种情况下,每一个参与者都必须采用中央系统所强制的资源和参与者标识符,中央系统成为通用身份提供方。
考虑到不是强制系统,PIPCO系统100统一身份的方法完全不同。按照设计,PIPCO系统100用作跨所有参与者105将各个代理316和资源(无论是否是原子的)306的中央PIPCO身份映射到其关联身份的目录的中央编目系统。因此,当从给定参与者105访问与给定资源306/代理316有关的数据时,PIPCO系统100将该资源306/代理316的中央过程身份转换为参与者105的内部框架中的适当身份。因此,PIPCO系统100维持通用身份转换器,其可将跨参与者105的代理316或资源306的多个身份映射到单个身份,这保证过程流程中的所有参与者105全部指相同的资源306或代理316。这是PIPCO系统100设计的关键元素,没有这种身份统一,将不可能在给定过程步骤319中得到所有参与者105的活动的一致视图。还重要的是需要注意,这种身份统一必须在参与者105维持这些身份的级别,而非在PIPCO系统100访问它们的原子级别进行。因此,例如,参与者105内的医案资源306可能被PIPCO系统100拆分为更原子的资源305,例如CAT扫描、X射线、血液检验、尿液检验等。然而,参与者105的医案标识符链接到该资源306,而非参与者不知道的PIPCO系统100的原子资源305定义。因此,甚至对于原子资源305的PIPCO系统100身份统一也必须在参与者105内的资源层次结构310中实际可进行资源识别的适当级别进行。因此,在此示例中,这种识别和统一必须在医案级别进行。
图8示出医疗保健领域的示例,可有助于使这一点更清楚。如今存在各种电子健康记录系统,就像众多保险和计费系统一样。名为John Smith Junior的患者可能以不同方式进入各种提供方系统。例如,参与者105医院A可能称他为J.Smith,II。参与者105医院B可能称他为John Smith,II,而为他投保的参与者105保险公司C可能称他为J.Smith Jr。这些变体并不罕见,特别是当我们的患者的父亲John Smith Senior也可能是所有这些参与者105的患者时。在这种情况下跨所有参与者105将共同身份强制为John Smith Junior是困难的过程,每一个人都必须更新他/她的内部身份映射,而在全球范围,该过程甚至变得更复杂,其中例如Junior可能被替换为诸如Filo的另一词语,如类似巴西的葡萄牙语国家中可能会发生的。
PIPCO系统解决了身份问题,而无需参与者105改变其内部数据。毕竟,如果医院(比如医院A)要将患者识别为J.Smith II,则其在与他相关的所有内部事务中均将以相同方式称呼他。PIPCO系统100可在其身份映射311中将该同一患者识别为John Smith Junior并将他对于参与者105医院A的身份映射为J.Smith,II(医院使用的身份),并且在需要时跨参与者105适当地转换对他的所有引用。这里的想法是,通过这样做,PIPCO系统100在平台一次解决身份问题(对于从每一个参与者105获得的资源306),并且无论哪个参与者105提供他的记录,保证使用PIPCO系统100的John Smith Junior标识符访问该患者的任何其他参与者105是正确的John Smith。
尽管图8示出在患者识别的上下文中的身份映射311,但是当需要时,这同样适用于其相应层次结构309和310内的其它代理316或资源306(例如在组织/参与者105内具有唯一标识符的文档)。这是PIPCO系统100的总体设计中较关键的方面之一。
用于资源306访问的证书映射313
身份映射311本身无法用于从各种参与者105的各种位置获得所需资源306。对于PIPCO系统100的各个代理316,PIPCO系统100必须从他将从其访问这些资源306的各个参与者105建立用于资源306访问的证书313的映射。这些证书被绑定到参与者105为身份映射311中定义的特定代理316定义的身份。这样,对PIPCO系统100的请求是来自给定代理316的认证的资源请求,其使用其正确的身份以及正确的证书被转换为对实际存储所需资源306的参与者105的等同请求。一旦资源提供参与者105认证了该请求(给予这种参与者105提供给代理316的证书),就可访问适当资源306并交付给请求代理316。通过提供这种功能,PIPCO系统100有效成为所有参与者105的虚拟资源存储库。PIPCO系统100使过程中参与者105所需的任何资源无缝可用,即使其可能与另一参与者105驻留在远程位置。
应该注意,由于PIPCO系统100的资源映射和层次结构307和310创建,给定代理316可能请求比参与者105中实际存在的资源更原子的资源306(如图6A所示的新资源点中)。对于这些情况,PIPCO系统100将使用比代理316可用更高级别的证书来获得更广泛的资源306,但是然后仅根据PIPCO系统100的规则向他交付该更高级别的资源306中他有权访问的部分(将是资源层次结构310中比PIPCO系统100所获得的更广泛资源306更低的一些资源306)。即,医院中的成像技师可能仅能访问图像,但是PIPCO系统100中的给定参与者105可能仅维持医案,这些医案也包含图像,但我们的技师无权看到全部。在这些情况下,PIPCO系统100将使用比成像技师可用更高级别的证书来从参与者105获得医案,但是然后仅向后者提供来自该记录的图像。出于这些目的,PIPCO系统100将具有指定的证书,其允许正确的访问级别以获得更高级别的资源306,以用于其创建资源层次结构310中较低的资源306的目的。
PIPCO系统100提供的身份映射311和证书映射313相对容易实现。身份映射311通过设计链接用于资源306访问的所有证书信息。这些映射固有是关系型的,可在经典关系数据库中容易地实现。然而,它们会变得非常大,并且考虑到所存储的证书信息的敏感性质,需要非常安全,同时提供良好的性能。实现这些映射的真正挑战不在于抽象设计,而在于实现良好的性能。
身份映射311和证书映射313允许PIPCO系统100提供对跨参与者105分散的资源306的无缝访问。这是PIPCO系统100平台的关键设计要求。事实上,通过所存储的证书以及到各个参与者105的高速通信链路,PIPCO系统100提供比PIPCO系统100外部访问相同资源306的各个参与者105可能得到的性能水平高得多的性能。
规范存储库300的各种信息、数据、映射、规范等被存储在一个或更多个知识/过程状态数据库323中。
过程知识引擎400
PIPCO系统100将每一个过程视为资源306访问(或者使用更熟悉的术语,事务)序列。高级过程可能由具有明确定义的开始和结束步骤的事务序列组成,然而也有许多事务预期有多个并行活动线程,其中这种清晰的界定是不可能的。为了过程监测和协调,PIPCO系统100必须知道过程319中涉及的步骤序列。知识引擎400是PIPCO系统100的组件,其定义并维持过程排序逻辑,它是PIPCO系统100的意识大脑,其了解过程并存储已经完成的过程步骤319的序列。PIPCO系统100跨所有参与者105存储总体过程状态的能力使其能够使过程流程透明并评估在哪里过程效率可改进(如果发生的话)。
规范存储库300定义了原子过程步骤319以及执行各个步骤所需的各种访问和资源映射307、309、311、313。知识引擎400将这些规范构建块一起拉到过程结构中,该过程结构根据其要求适用于各个参与者105。规范存储库300中的定义的一致性允许具有复杂过程步骤序列的过程逻辑编码(以及过程状态的维持),并且保证该代码跨PIPCO系统100的所有参与者105无缝地工作。
在为PIPCO系统100的过程知识引擎400创建过程映射405时出现了一些重要的设计考虑。具体地:
·大量抽象数据。PIPCO系统100记录的被视为原子事务的过程步骤319需要连同关于谁参与了过程319、他们的访问许可等的信息一起存储。这些数据需要以允许我们在所讨论的事务涉及正被访问的数据元素时根据需要链接回各种参与者105的数据存储库的方式存储,考虑到PIPCO系统100为其参与者105执行的每一个功能(包括访问记录、上传、图像转换等)是过程步骤319,系统100将记录数百万且最终数十亿的事务步骤。存储这些事务及其丰富的链接集合并高效地检索它们是关键设计目标。
·改变原子资源305、代理316和关系的性质。PIPCO平台100的代理316及其事务的概念可能随着时间推移变得更丰富和更复杂。例如,给予PIPCO系统100对作为单个资源的整条病历的访问的医院参与者105可能决定,该原子资源305需要被PIPCO系统100解析为其各种组件,例如检验结果、医生就诊、过敏等。当发生这种情况时,PIPCO系统100的平台需要扩展其层次结构和角色映射317和309、证书映射313和资源映射307,以支持这些现在分解的资源306。同样,对于PIPCO系统100中的整个原子代理315也可能发生同样的情况。例如,医院参与者105可能想要PIPCO系统100允许在总体过程流程的上下文中跨其员工(例如,医生、护士等)中的特定成员进行更细粒的过程协调(即,更细粒的代理/角色层次结构317)。将单个原子代理315或原子资源305变形为多个新的子类型不仅增加了原子代理315和原子资源类型的数量(同时使许多先前的原子类型不再是原子的!),而且还需要创建许多新的原子资源305/代理过程链接。PIPCO系统100的平台支持这种变形作为其设计的核心元素。
·复杂且灵活的关系。过程步骤319可能必须以在PIPCO系统100首次建立时可能没有预料到的复杂方式相关。例如,与前来手术的医疗患者有关的过程步骤319可能需要与他的交通请求和住宿安排相关,这些事物严格意义上不具有医疗/医疗保健性质,但是在需要特殊转运和住宿的病患的情况下实际上是过程319的一部分。PIPCO系统100将建模的关系并非全部在初始设计阶段期间设定,并且PIPCO系统100需要足够灵活以支持可能没有预料到的任何类型的未来关系。
为了满足上述目标,PIPCO系统100的过程知识引擎400是总体设计中最复杂的组件。过程知识引擎400必须应对数量不断增长的参与者105、原子资源305的增加的层次结构310和数量不断增长的代理316。它还必须应对不断增长的过程步骤/事务319的集合。此外,知识引擎400必须引用和跟踪各种层次结构中任何级别的所有这些过程元素(代理、资源、步骤等),并且它必须在提供合理性能的同时完成所有这些。PIPCO系统100在一系列层中解决这些要求:过程定义层404、关系层407和对象层次结构层409。图9中示出这些层的示意图。
过程定义层404
如图10所示,过程定义层404允许众多事务排序为明确定义的过程布局。“T”表示特定事务/过程步骤319。过程步骤319的特定序列可涉及从T0开始,到T1,到T4,然后在Tn结束。在图11所示的医疗保健领域的更具体示例中,上述过程步骤319将涉及从“患者就医”开始,到“血液检验”,到“高级医生就诊”,到“患者事务结束”。
过程布局404的实际规范并不像如图10所示仅布置静态图那样简单。这是因为PIPCO系统100将应对的实际过程流动得多并且常常基于从先前步骤319获得的结果将涉及多个分支。过程定义404必须以过程规范语言200编写,并且将布置总体过程逻辑,包括在每一个步骤需要获得的结果(如果有的话)以及下一可能步骤可能是什么。换句话说,过程规范非常像语言语法。语法规则限制了过程步骤319的可能顺序(或多或少取决于所讨论的过程),但实际过程流程可能以与我们的语法一致的任何方式演进。此外,在定义过程步骤319排序时过程规范语言200的重要性变得显而易见。当定义过程319的排序规则时,我们必须有足够丰富以捕获该领域的高级过程原语的语言。因此,在医学领域中,我们的过程规范语言200将必须支持诸如“从医院得到医案”或“与医生建立电话会议”的高级原语,这将允许在我们的过程定义层404内容易的过程排序。当然,这些高级概念将由PIPCO系统100的执行引擎500(在下面的部分中提出)解释,以执行期望的功能。
尽管过程定义层404涉及规范的复杂性,但它可能是规范存储库300的最简单部分。PIPCO系统100使用过程规范语言200来对布置动态过程排序步骤319的规则进行编程。甚至用于复杂过程的这种规范相对小,并且使用任何可用的数据库或甚至简单的文件存储技术来容易地维持在PIPCO系统100的规范存储库300中。
关系层407
知识引擎400的关系层407允许代理层次结构317中的任何代理316与过程步骤/事务层次结构321中的任何过程步骤319(再次重申,在PIPCO系统100中被视为访问资源306)之间的关系(例如,参与者、委托人、付款人、担保人、接收者等,取决于领域)映射。例如,发生的电话/电话会议(在PIPCO系统100中是涉及两个或更多个代理316的资源306请求)是需要链接到所有参与代理316的资源306使用,可能实际录音的呼叫和/或其记录对其中的所有代理316均可用。呼叫的发起者可能以关系“发起者”与该事务相关并且以关系“参与者”与参与者相关。这种关系设置将允许我们稍后返回到所讨论的事务以确切地确定谁在其中做了什么,并且可能稍后在呼叫的记录或录音可用时根据建立的规则适当地通知他们。事后正是代理316和事务319的这种链接允许每个人全面了解过程中发生了什么。
问题是PIPCO系统100具有丰富的代理和过程层次结构,例如317和321。如果系统具有中等复杂度,则将这些变化的层次结构与甚至更丰富的关系层407融合将根本变得不可能,更不用说PIPCO系统100的复杂度。为了允许这种建模,PIPCO系统100采用严格的规则:
·PIPCO系统100中的每一个代理316(无论他位于代理/角色层次结构317中的何处)均都属于代理类411。
·执行的每一个动作或事务319(无论它在PIPCO系统100中的事务/过程步骤层次结构321中的何处)均属于事务类413。
在关系层407的上下文中,仅代理类411和事务类413可彼此相关。代理类411和事务类413之间的关系是多模态的,这意味着它们可按任意方式相关,无论它们具有SQL样式关系模式,还是非SQL方法(例如图、密钥或其它任意连接)。PIPCO系统100的多模态性质意味着所有这些类型的关系将被同时允许。
关系层407中的多模态要求可利用以下简单的过程示例容易地理解。具有四个代理316A、B、C和D的过程可能由A发起,其需要执行特定动作并告知B和C。响应A的请求,B和C可能必须同时执行特定功能。假设B和C二者必须将所需文件上传到D。D继而随着他处理上传的文件与文件提供方B和C中的每一个多次交互。这些交互可能包括在验证文件的正确性、对其内容解码以及对其中的数据分析之后向这些代理316通知。一旦这些过程步骤完成,B和C就将来自D的结果响应给A,然后A认为过程完成。在这种情况下,显而易见的是,A分别与代理B和C之间的过程步骤在逻辑上不同。同样,B与D和C与D之间的交互在逻辑上也不同,因为这些是有效地单独交互组,其知道另一方正与D交互,既不会与B也不会与C并行发生。对这些交互进行建模通常涉及构造过程步骤319的复杂图。然而,当涉及到代理316A、B、C和D之间的实际关系时,它们可为分层的。然而,给定过程步骤319中涉及哪些代理316的问题(这也是PIPCO系统100的执行引擎500所跟踪的)是简单的一对多关系。由于即使在这个微不足道的示例中,PIPCO系统100也必须同时支持所有这些类型的关系(图、层次结构、关系),所以其关系核心在概念上是多模态的并且必须如此实现。
多模态关系核心利用许多当前可用的面向特定类型的关系的技术(例如,可用关系或图形数据库)的组合来实现,其中跨技术的链接由PIPCO系统100利用定制的跨数据库工具来实现。
对象层次结构层409
PIPCO系统100中的代理和事务的丰富且可能不断增长的层次结构根本不在关系层407中直接捕获。然而,它们被间接捕获,因为PIPCO系统100中的每一个代理316属于代理基本类411,并且每一个过程步骤319属于事务基本类413。因此,各个代理316和过程步骤319无论多么复杂,均在这些基本类级别管理其关系,而这些连接不会污染代理和事务层次结构(分别为317和321)。因此,代理和事务对象层次结构409可以任意复杂,分别具有众多不同的代理316类型和角色以及众多不同的过程步骤319。然而,尽管层次结构复杂,考虑到所有事物均在基本类411和413的级别定义,核心关系、身份映射311等将全部正确地工作。
代理和事务基本类411和413中隐含的对象层次结构409意味着核心知识引擎400必然是复杂的。特别是:
·在关系级别,它必须是关系型的。毕竟,它将代理类411和事务类413相关,这是纯关系功能。
·在代理316和事务319级别,它必须是面向对象的。它在需要表示的这些维度具体实现明确定义的对象层次结构409。
·在事务/过程步骤319被组织到过程中的过程定义层404,它需要是面向图形的,具有多个路径和节点排序。
重要的是,知识引擎400必须同时提供所有上述不同的关系模式,同时沿着所有这些维度完全可扩展。
图12和图13从医疗保健领域中的过程映射405内的关系层407和对象层409的两个不同角度示出示例。对于图12中的第一角度,各个事务319被组织在事务层次结构321中。例如,事务1用于图像,特别是CAT扫描图像。类似地,各个代理316被组织在代理/角色层次结构317中。例如,代理1是医生,特别是高级医生。关系层407识别代理316与事务/过程步骤319之间的关系。对象层409将事务413或代理411类与更复杂的事务319和代理316概念无缝地相关。使用对象层409允许从代理316和事务319层次结构(分别为317和321)的复杂度及其随时间推移的可能突变抽离,无论这些代理316和事务319概念如何演进,关系层407处定义的关系将保持不变。
对于图13中的第二角度,关系层407涉及多个代理316与事务319。例如,该事务可能涉及医生和护士二者,例如获得CAT扫描或X射线对比,两个群体均可能参与其并且事后均需要获得相关信息。
PIPCO系统100中的关系层407需要维持的数量非常大的事务和关系使得性能设计成为重要问题。关系层407与过程状态/知识数据库323协同工作,以存储通过PIPCO系统100处理的每一个事务319及其所有关联的关系(与其它事务319或代理316,如适当的事务411或代理413类所指示)。这将允许过一段时间返回以从任何相关代理316或事务319的角度研究该事务319及其关系,并且通过将其与PIPCO系统100可能已完成的其它类似事务319进行比较来分析。因此,将一起工作的关系层407和过程状态/知识数据库323的数据库均需要是分布式的、多模态的和虚拟的,因为通过其框架访问的大多数数据将经由到其它源的链接。甚至,单个代理316在任何时间点所使用的实际数据集很可能非常小,这意味着数据存储必须通过为每一个代理316创建其自身数据的高速视图来操作,以获得合理的性能。
执行引擎500
利用通过规范存储库300并入PIPCO系统100框架中的资源定义306、位置(具有资源映射307)和参与者身份311,并且利用过程知识引擎400所提供的过程映射405,执行引擎500进行过程实现的实际工作。
可由执行引擎500提供的过程特征的非穷尽列表包括:
·基于其适当权限,所有代理316的相关过程资源306(无论是文本文件、视频、音频、图像等)的访问。
·通过PIPCO系统100直接向PIPCO系统100中的代理316进行语音和视频呼叫或发送文本的能力,其中全程录音以及如果需要记录。
·根据某些指定的规则上传数据并使其在许可时自动对其他代理316可用的能力。
·PIPCO系统100上的所有事务319的记录,具有完整访问日志和变更审核跟踪。
·所有文档的完整版本控制,能够轻松恢复任何年份的文档。
·自动文档格式转换,需要时可选的光学字符识别,需要时语言翻译、备份和压缩。
为了理解执行引擎500如何工作,看一些示例是有启发性的。图4示出代理316的典型资源306访问的示例,其涉及PIPCO系统100的执行引擎500如下:
1.PIPCO授权。在框4-03,代理X 316首先必须使用PIPCO系统100提供的证书向PIPCO系统100本身认证。这种认证可能由PIPCO系统100自己的身份管理子系统完成,或者另选地由提供身份管理的第三方认证器(例如Google或Facebook)完成。实际认证过程无论如何实现必须由执行引擎500管理,如实际访问的记录一样。
2.资源请求。代理X 316在认证之后请求(在框4-01)他有权访问的资源R 306。资源的位置被提供给执行引擎500,如来自为此目的维持的各种映射(例如资源映射307和证书映射313)的资源的代理位置一样。执行引擎500必须快速获得正确的映射并确保提供所讨论的资源306的相关服务器是可操作的。
3.资源访问和交付。资源映射307示出相关资源306位于何处。然而,PIPCO系统100本身需要提供用于访问资源306的机制。具体地,在框4-06,执行引擎500必须使用代理316的证书来处理对资源306的认证,使用所需协议和标识符来访问资源306,并且一旦获得,就必须将资源306以适当的格式交付给请求代理316。这些任务可证明高度复杂。因此,如果例如在专用图像服务器上存在诸如患者图像的资源306,则执行引擎500必须基于参与者105的协议为资源306提供正确的标识符,使用适当的系统调用获得资源306,然后对其进行后处理(如下所述),以便显示在比如平板、电话或其它此类设备上。
4.资源处理。这是执行引擎500的真正灵活性发挥作用的地方。在框4-08,资源306一旦被访问就必须在交付给请求代理316之前以某种复杂的方式处理。这种处理将包括执行引擎500对资源306进行后处理以确定其性质并最低限度地更新规范存储库300中的过程状态/知识数据库323。执行引擎500还可能具有诸如文档格式转换、光学字符识别、语言翻译等的活动。当资源306是类似电话会议或日历安排请求的项目时,后处理必须在可进行交付或请求完成之前将其他代理316并入处理循环中。PIPCO系统100所完成的大部分资源处理可由为此明确目的而集成到PIPCO系统100平台中的第三方子系统完成。但是执行引擎500提供这些子系统的总体管理。
要注意的是,图4是简化示例,没有示出实际过程映射405,也没有示出执行引擎500对过程状态/知识数据库323的更新。过程步骤/事务319全部在知识数据库323中(连同由已经执行的所有过程步骤319定义的当前状态)指定。执行引擎500简单地引用这些项目以执行其各种功能,并且当原子过程步骤319已完成时更新知识数据库323。
换句话说,知识数据库323包括用于规范存储库300内的过程319的规则集合,并且执行引擎500是执行这些过程319规则并在完成各个步骤319时更新知识数据库323的实际机器。因此,PIPCO系统100积累的知识可用于使用过程规范语言200(在此上下文中是规则编程语言)通过对一个或更多个参与者105及其关联代理316的给定过程319规则的变更来引起过程变化。执行引擎500实际实现过程步骤319的该新序列。从用户的角度,PIPCO系统100的感知智能来自协同工作的知识数据库323和执行引擎500。因此,诸如由代理316上传特定类型的文件的过程步骤319可能在知识数据库323中(利用过程规范语言200)被指定为触发一系列附加操作的过程步骤,例如向代表特定参与者105的各种定义的代理316发送消息,并将其响应列表发送回上传代理316。文件上传之后的附加步骤319表示PIPCO系统100的智能,毕竟,没有PIPCO系统100,上传代理316将不得不执行过程319本身所需的所有消息功能。PIPCO系统100可准确地、一致地执行这些功能并且对于所有参与者105和代理316而言谁做了什么(包括执行引擎500本身做了什么)是完全透明的,这一事实使其对于所有其参与者105及其代理316用作越来越智能的准人类助手。
开发执行引擎500是持续的努力,因为规则语言必须是可扩展的,以支持新的代理316、过程步骤319和资源(305、306)处理方法。这又意味着引擎500本身不断地扩展以支持更多功能。
执行引擎500的设计很可能复杂得多并且与已经开发的其它类似引擎根本上不同。这是因为PIPCO系统从一开始就旨在成为虚拟过程协调器,其参与者105可地理上广泛分散,具有不同且可能高度复杂的内部系统。同样,PIPCO系统100甚至从开始就旨在将第三方服务提供商无缝地并入其框架中,用于诸如提供电话呼叫、日历、翻译、格式转换等的活动,甚至可能用于诸如身份管理的更基本要求。最后,执行引擎500必须以适合于容易分析的格式记录来自各种代理316的过程信息,如下面所讨论的。
因此,PIPCO系统100的平台必须交付从不同位置的各种复杂系统获得的资源306(全部接近实时),这甚至对于数据全部本地驻留在单个服务器上的系统也是苛刻的要求。然而,PIPCO系统100通过复制将实际过程资源越集中到自己的存储框架中,冗余、过期数据等的可能性就越大。
为了应对这些实现问题,执行引擎500从一开始就被设计为以中央大脑以及理想地位于各个参与者105位置中的远程大脑二者来操作。换句话说,执行引擎500具有中央大脑和本地大脑协同工作的分布式智能。图14示出图1的PIPCO系统100的分散式设置,其包括PIPCO中央系统101和多个PIPCO本地系统102。各个PIPCO本地系统102可物理地驻留在参与者105的内部技术框架内其自己的防火墙和安全屏障(无论在现场还是在互联网上)之后,或者虚拟地驻留在PIPCO系统100内该参与者105的安全分配中。
图15示出扩展形式的PIPCO本地系统102之一以及医疗保健领域中的PIPCO中央系统101以及PIPCO系统100处理来自代理X 316的代理请求的全部工作。各个过程步骤319中的数字显示过程排序,从代理X请求资源Rx1到最终交付给他,总共有9个步骤。步骤1至5由PIPCO中央系统101处理,其涉及处理请求代理X 316、他的认证、资源307和证书313映射的搜索以及对我们的医院A的本地PIPCO系统102的实际资源306请求。PIPCO中央系统101维持完整的过程映射405和身份映射311(图中未示出过程映射405)以及用于执行引擎500的访问的逻辑。在参与者105站点中操作的本地系统102维持在要交付给PIPCO系统100的数据方面仅对该参与者105站点相关的这些映射405和311的副本。步骤6、7和8由本地PIPCO系统102处理。本地系统102的主要角色是管理代理认证,预格式化数据和标签信息,以使得对来自中央系统101的资源306请求的响应是相对即时的过程并将最终结果实际交付给PIPCO中央系统101。此过程将如下进行:
1.PIPCO中央系统101的执行引擎500向参与者105站点处的PIPCO本地系统102请求资源306(步骤5)。在我们的示例中,此请求利用代理X 316的正确身份向医院A105(在那里他被称为X-ABC而非X)进行,并且利用医院A用于X-ABC的正确登录证书。
2.PIPCO本地系统102的执行引擎500根据需要提供必要的认证转换,然后轮询参与者105所维持的内部认证系统,以确保交付所请求的资源306(步骤6)。
3.如果参与者105的本地认证服务器对访问请求作出肯定响应,则本地系统102的执行引擎500将通过对资源306(其很可能已预格式化)编组并将其高速传送到中央系统101的执行引擎300来响应中央系统101请求的执行引擎200(步骤7和8)。
4.如果需要,向参与者105站点针对特定资源306的重复请求可能由本地系统102的执行引擎500高速缓存,以提升性能。如果参与者105站点在需求高峰期无法支持高速通信,则高速缓存到云可能是必不可少的。当然,在步骤9中,PIPCO中央系统101将资源306交付给请求代理X 316。
这里要注意的重要问题是,中央系统101的执行引擎500在高流量参与者105站点的各种本地系统102处具有很多卫星执行引擎500,以从中央系统101的执行引擎500卸载大部分参与者105特定逻辑。然而,由于本地系统102的这些执行引擎500将以与中央系统101的执行引擎500相同的规则和映射来操作,所以存在其开始起作用的内置冗余,以及通过以合适的高速缓存或其它策略适当地优化本地系统102的执行引擎500来生成非常高的速度的可能性。
对于本发明的PIPCO系统100,最大瓶颈最终很可能是从PIPCO系统100到其参与者105和提供商的链路中的通信速度。PIPCO系统100设计有允许各种中间高速缓存步骤和众多不同的传输协议的能力,以降低通信速度所带来的惩罚。
PIPCO系统100的执行引擎500的主要挑战不是速度,而是灵活性。PIPCO系统100的大部分是以灵活的解释语言(例如Python)编写的,其中许多第三方模块被集成到框架中以提供关键优化。如果需要,选择PIPCO系统100中作为瓶颈的模块将以低级语言(例如C++)重写,以改进速度。
理论效率
传统过程流程,特别是当其涉及外部代理时,通常围绕参与代理之间的点对点交互来建立。此外,这些交换涉及诸如文档、图像等数据的传输,各个代理存储其自己的私有副本。通常,当特定文档被更改时,仅整体发送修订文档,因为过程中的各种代理很少使用允许增量记录和向初始文档中并入更改的通用工具。
通过一些简单的数学,我们可计算传统过程流程中需要维持的最坏情况代理链路数量,以及跨代理的最坏情况数据存储要求。
假设我们的过程中有基于点对点交互的n个代理。在最坏情况下,在过程中每单个代理可能不得不应对每一个其他代理。因此,在这种情况下代理1将与代理2、3...n交互,代理2将除了代理1之外与代理3、4....n交互,等等。如果这种最坏情况过程情况下需要维持的通信链路的总数为N,则我们可很容易证明:
在计算机科学方面,在最坏情况下n个代理之间的链路或交互通道的数量以代理数量的平方或O(n2)的速度增长。
在存储方面,假设代理1生成初始文档,对其更新总共m次,每个更新的文档整体存储,然后将各个版本发送给过程中的其他代理。即,代理1初始创建大小为的文档。他的第一次微小更新(或修订1)使其大小相对于先前版本改变了量/>以使得新文档的大小为然后在第k次修订,文档的大小将为:
假设更改相对于/>较小,则他的m次更改的总存储需求S1将由下式给出:
在最坏情况下,各个代理存储代理1所发送的这一个文档的每一个修订版本的完整副本。因此,仅仅对于代理1通过m次修订所生成的这单个文档,跨所有n个代理的存储需求将近似为:
即,由于有效地存储初始文档的mn个副本,所以传统过程的存储需求随更改次数m和代理数量n或以O(mn)的速率成倍增长。
PIPCO系统100的设计旨在用点对平台交互代替过程中的代理316之间的点对点交互。在需要跨所有代理316的交互的过程的最坏情况场景中,这些交互仍然将由每一个代理316通过PIPCO系统100进行。因此,通信链路的数量将仅以与代理316的数量成比例的速率或线性地增长。在计算机复杂性方面,链路的数量以O(n)速率而非传统过程流程中的O(n2)速率增长。
在存储方面,PIPCO系统100将数据从位于PIPCO系统100本身或生成代理316处的单个存储输送到所有参与者105。此外,如果PIPCO系统100是用于访问的专用通道,则它可通过存储初始大文档,然后简单地存储所做的小更改来优化文档的存储。当任何代理316查看数据时,他将得到当前版本,因为PIPCO系统100可执行适当调节以确保看到正确的文档。此外,它可跨文档的历史维持更改的审核记录,以使得更容易理解更改。如果PIPCO系统要这样做,假设更改较小,则上面生成的文件的存储要求将为:
清楚的是,在最坏情况下对于每一个事务319,PIPCO系统100可将存储成本降低m*n倍,因此每事务的存储几乎恒定。即,PIPCO系统100将存储复杂度从O(mn)降低至O(1)的恒定水平。
因此,PIPCO系统100具有一些显而易见的效益。在n代理316过程中,其将所需的最坏情况代理通信链路从复杂度O(n2)降低至O(n)。其将来自单个代理m次修订的单个文档事务的最坏情况存储要求从因子O(mn)降低至恒定量O(1)。当代理316的数量n与文档修订次数m一样大时,PIPCO系统100所提供的切实效益可证明巨大。
下面针对三个不同的领域提供三个示例:医疗保健、全球贸易以及财产和意外伤害保险。这些领域例示并非旨在为穷尽的。相反,它们旨在展示PIPCO系统在允许这些领域中的业务过程的重整和重新映射方面的能力。因此,这些示例旨在加强这种自上而下的集成平台的非凡力量。
用于医疗保健行业的PIPCO系统的示例
美国医疗保健行业是私营部门以及政府二者的单一最大支出领域。医疗保健是大多数美国公司为其员工提供的最大福利之一。医疗保险和医疗补助是巨大的政府项目,随着美国人口日益老龄化,其成本只会持续增长。
医疗保健成本的急剧上升不能低估。在20世纪80年代初,美国在医疗保健费用上花费了大约6%的GDP。如今,近17%的GDP用于医疗保健,并且在接下来的几年这一数字甚至将随人口结构而上升。行业中涉及的几乎每一个人都会同意,医疗保健成本已急剧增加。事实上,即使重大技术进步降低了诊断和治疗的成本,总体成本仍持续飙升。尽管对究竟是什么促成了这种成本爆炸存在实质性争论,但我们仍然可识别一些广泛的驱动因素:
·医生越来越被迫去看更多的患者,使得他们无法花费准确诊断真正必要的时间。因此,众多常常不必要的检验替代了受过训练的患者评估和护理。
·缺少用于病历保存的中央系统意味着许多检验常常简单地重复,因为可能不同提供方所拥有的先验数据不易获得。
·健康保险的存在意味着患者通常不关注其护理成本,这是保险公司的责任。因此,健康支付系统常常成为患者、保险公司专家和提供方就究竟可做什么和支付什么进行争论的对抗设置,而非为患者生成最佳结果的合作过程。
·医疗保健定价是出了名的不透明。很少有提供方制定可用的标准价格表,尽管他们常常被要求这样做。考虑到价格细节的复杂度,消费者无法容易地基于成本或结果进行比较。
·欺诈在行业中猖獗,各种提供方和消费者利用该系统来牟利或绕开晦涩的支付规则。
·管理成本高并且只增不减。限制欺诈和成本超支的需求意味着在交付过程的每一步均存在永久的成本监控组。这反过来又给患者和提供方二者强加了更多成本,因为他们必须对抗更多的记录保存和审批过程。
对医疗保健过程的重大反思远超出PIPCO系统100的范围。然而,PIPCO系统100可智能地用在众多医疗保健领域中,其中可获得显著的效率增益,甚至同时保持系统的核心结构基本完好。事实上,在医疗保健行业中战略性地使用PIPCO系统100将使医疗保健过程的部分更加及时和透明。通过PIPCO系统100将提供的细察,可应用各种强大的技术工具以流线化过程的某些元素并降低成本。
PIPCO系统100的方法将填补美国医疗过程领域的重要空白。就其本质而言,它是当今医疗空间中根本不存在的横向集成平台。PIPCO系统100的平台将被设计为协调医疗空间中的所有参与者和代理(例如提供方),根据需要针对特定要求采用和集成其优选的垂直解决方案。因此,PIPCO系统100的平台从一开始就将被设计为根据需要以一系列高质量医疗计费解决方案、诊断软件辅助和记录保存数据库来操作。因此,其将所有部分解决方案集成到统一系统中,该系统可满足各个参与者105/代理316的至少一些基本集成需求。
下面的示例示出PIPCO系统100可如何变革涉及相对简单的医患就诊的美国医疗过程。首先说明如今这种就诊的过程流程,然后说明在PIPCO系统驱动的医疗世界事物如何变化。
如今的就医和随访
考虑一个患者,他因并非完全微不足道的事情而去看医生。如图16所示,在这样的就诊中,将涉及以下代理316中的许多(如果不是全部的话)代理:
·患者,其自己决定发起此过程以就诊。
·初诊医生(PD),首次约诊的人。此医生将检查患者,并且可能需要进一步咨询专家以做出诊断。
·专家,初诊医生将患者转诊给其以进一步评估。
·实验室,其执行检验并将结果交付给医生和/或患者。
·成像设施,其取得患者的扫描或其它图像。
·保险公司,其为患者提供医疗保险。
·药房,其接收医生处方并向患者提供药物。
·医院或诊所,其可能提供诸如手术室、注射药物等服务。
·政府,取决于服务类型和患者所具有的保险类型。
图16示出代理316之间的过程流程和交互,对于相对正常的就医,即使代理316的数量相对少,这也变得异常复杂。具体而言,患者在医生见他之前填写一些表格,列出他的过敏、症状等。这些表格将由医生保留,有时可能被提供给专家。医生可能安排检验,通常处方开给患者或内部实验室。医生写下可能提供给患者的诊断,以及给药店的处方或在医院进一步治疗的医嘱。当然,该诊断和所有相关的检验单将由保险公司以及可能由政府审查。实验室、成像设施和医院继而将对患者执行所需手术并向患者提供总结报告,这些报告常常被发送给安排检验的医生,但未必发送给患者护理矩阵中的其他医生。不管好坏,患者可能不得不最终成为过程协调员,特别是在初始治疗完成并且需要进行支付时。
甚至图16在许多方面比实际情况简单得多。由于病历的保密性,各个代理316(提供方)将坚持一堆表格和书面工作以便于数据发布给另一代理316。此外,各个代理316将保留他自己的与其交互有关的所有病历的私人副本。当提供医疗服务的代理316彼此独立时,他们常常根本没有用于数据传送的格式,并且通常将采取其打印报告或扫描电子邮件。患者本身常常充当信使。通常,考虑到医疗中的隐私问题严重,没有病历的中央存储库。这也意味着在检验记录分析或结果比较方面没有简单的自动化方法,我们在很大程度上依靠从业者的技能和经验。
试图用独立的监督方来改进上述过程的效率很可能在后者开始之前就注定要失败:新的代理316很可能在已经过载的系统中创建如此多的新通信要求,以至于仅仅这些新链路的成本就会使他可能产生的任何效率增益相形见绌。尽管如此,值得注意的是,现有过程甚至致力于交付良好的结果!
PIPCO系统100重整的就医
已有众多尝试来解决由上述就医创建的行政噩梦。这些措施可分为三大组:
·封闭式综合解决方案,其涉及采用给上述混乱强加其自己的秩序的定制系统。许多这样的系统已进行了尝试或至少构想过,但过程的巨大复杂性使得普遍采用几乎不可能。该综合系统旨在取代所有现有系统,因此必须在快速变化的技术环境中以高可靠性执行,这对于任何技术都是苛刻(如果不是不可能的话)的要求。
·有限受众系统。这些系统越来越多地用在某些医院或医疗集团的范围内,其中提供方在单一保护机构下操作。在这样的情况下,所有医疗记录可像计费和保险索赔处理一样被集中。不幸的是,当患者走出医院系统的范围时,他又回到早前描述的混乱环境。
·有限功能系统。许多系统通过仅聚焦于诸如计费的一个问题领域来应对医疗挑战。因此,可处理保险公司、医疗保障和患者的账单的医疗计费系统广泛可用。提供医案保存和安全备份的其它系统也无处不在。尽管这些系统中的许多系统在其宣称的功能方面做得很好,但它们根本无法提供可重做上述总体混乱过程的基础。
PIPCO系统100重整上述医疗过程的方法是创建可承担过程协调任务的综合平台。该平台将强加用于跨参与者105及其相关的代理316共享数据和过程知识的框架,以限制冗余并允许过程随时间变化。PIPCO系统100旨在利用这样的事实:与共享/纠正信息有关的许多信息和过程步骤本质是浪费的,一旦与患者有关的数据被此过程中的特定代理正确地收集,就必须无缝且正确地使相同的数据对被允许查看任何或所有该数据的所有其他代理可用。对核心数据的任何更改同样应该在没有人工干预的情况下尽可能快地发送给相关参与者105/代理316。各个参与者105/代理316应该被允许在他的首选计算机系统中随意存储和查看他被许可的数据,根据需要对其进行备份,并且考虑到实际数据收集过程的限制,被保证其始终准确。
更具体地,对于初诊医生,他通常维持与患者有关的多个信息块。这些信息块是:
A识别信息以及计费和保险细节。
B详述说明过敏、手术等的患者病史。
C当前症状以及与症状发作有关的细节。
D安排/完成的检验。
E 实验室结果。
F 最终诊断和治疗建议。
G治疗、随访护理、检验等的患者说明。
H带药物剂量的处方。
在医生收集该信息的同时,并非过程中的每一个代理316均对其全部知情。因此,医生可能将患者转诊至的专家可能需要查看所有上述信息。药房仅需要查看H块。患者需要查看G区,可能查看F,但也有权查看其它所有信息。如果患者已授权,则保险公司将需要查看所有信息。实验室将需要查看A和D,但没有其它。这里需要注意的重点是,医生被迫管理此过程中的各个代理316可查看什么,并且必须确保适当的保护措施到位,以防止未授权信息发布或信息盗取。显而易见,过程中的各个代理316收集关于患者的信息。许多这种信息是跨参与者105共同的,尽管他们不可避免地多次收集。
大体上,医疗过程涉及各个代理316收集关于患者及其问题的一些基本信息,执行他在这个问题中的角色所特定的一些功能,然后一旦执行了指派的任务,就通知其他适当的代理。PIPCO系统100流线化此医疗过程的方法将通过限制信息冗余并允许更容易的协调来工作。因此,PIPCO系统100将创建用于应对上述信息块A-H的框架,以及用于共享相同信息的必要安全和过程规则。在这个世界上:
·初诊医生将仅仅以他通常的方式收集信息,但系统将被设计为沿着上述块结构组织该信息。
·信息块将与过程中的其他代理316(药房、医院等)自动共享,而无需医生干预。即,一旦医生断言信息是准确的,它就将被自动发布给该过程中涉及的所有相关代理316。各个代理316将仅查看他有权的块。
·信息发布将有时间戳,并且向其他受影响的代理316发送关于新信息的可用性的适当提示。
·对信息的任何更新将被突显,并且根据修改的块,将通知所有受影响的代理316。不需要查看修改的块的代理316将不被通知。
当然,相同的方法不仅适用于医生,而且适用于过程中的所有其他代理316。
PIPCO系统100可能没有存储它散播的任何实际信息,它唯一必须存储的是过程交互框架和适用的规则。因此,医生的信息很有可能保留在他自己的定制内部系统上,PIPCO系统100仅仅与他的技术挂钩,以使其按照有利于他们使用的格式对其他代理316可用。
从解决医疗处理问题的其它方法的上下文来看,PIPCO系统100的方法是创建综合平台,该平台被设计为插入医疗领域所特定的各种参与者105。该平台用作过程协调器、发送器、翻译器和事务记录保存器。它也可以是数据存储库,因为其参与者105为了速度和/或方便也需要数据存储库,但它不需要。图17是PIPCO系统100重整的就医的示意图。即使PIPCO系统100功能以可变的成本加上公司的合益利润被提供给过程中的各种代理316,通过以PIPCO系统100操作而获得的效率也不能低估。PIPCO系统100将进行以下所有操作:
·限制跨代理的数据冗余。由过程中的任一个代理316获得的单个识别记录可跨所有代理316共享。
·消除点对点通信,将其替换为代理316对PIPCO系统100交互。所有数据将由相关的代理316验证一次,并且PIPCO系统100将保证正确的数据将以高确定性发送。
·提供中央框架以研究过程动态并评估瓶颈,并且根据需要提供协调帮助。因此,例如未及时提供的药物批准可由患者提供方快速升级并解决,而病患甚至不知道发生了什么。
·允许随时间完全灵活地进行过程迁移。医生可能决定PIPCO系统100的平台可代表他存储发送的数据,并最终使其成为他的备份解决方案。有趣的是,这种备份可能被存储在医生自己的场所和系统中,但以更高效和可用的PIPCO系统100格式。
·随时间推移允许重大过程重整。如果专家想要让内科医生作为他的首次约诊医生,则他可能能够纯粹基于从患者初次就诊获得并通过PIPCO系统100的平台与他实时分享的画面和视频进行他的诊断。这将在下面更详细地讨论。但是需要注意的点是,PIPCO系统100不是这样做的正确方式或唯一方式,而是它是如果需要将无缝地允许这种迁移的框架。
具有PIPCO系统的激进的新医疗保健模型
PIPCO系统100的平台将允许医疗过程的元素如上所述增量地重整,但它也可支持急剧变化,特别是当一个或更多个参与者105寻求这种变化时。
在如今实践的医学中,医生类似于优秀的工匠。他的临床态度、他给患者带来的信心以及他的声誉全部是在收费价格高方面展示的奥秘元素。美国大部分地区已出现的辅助医疗设施都是为了支持这种技艺高超的医生队伍。大多数情况下,保险公司基于对患者执行的程序而非产生的结果来进行支付。这方面的少数例外是诸如Mayo Clinic的设施,其尝试基于整体护理而非特定程序来计费。
不幸的是,工匠式医学方法本质就昂贵。诸如汽车、家具、服装和电子等众多制造业已成功转向生产线方法。这在很大程度上既降低了成本,也改进了质量。几十年来,分配医疗护理的生产线方法的前景一直备受赞赏。事实上,纽约斯隆-凯特林癌症研究所是在阿尔弗雷德·斯隆基金会的资助下于1945年创建的。同名的查尔斯·凯特林是通用汽车公司副总裁兼研究主管,他在组织中的角色是利用其前雇主所使用的生产线技术来组织癌症研究和治疗。此后的众多研究表明,医学中的生产线技术确实能生成更好的健康结果。有影响力的医学书Checklist Manifesto(Atul Gawande,2011年,出版商:Picador)证明,即使是在手术前采用检查清单这一简单行为如何避免不必要的错误并改进结果。
我们相信,从工匠转到生产线模型最终将成为医学上的必然。利用在生产线设置中收集的数据,用于诊断的智能计算机辅助人工智能助手很可能变得更易适用。当与既往病例和结果的详细病史相结合时,这些AI助手将变得更强大,从而允许医生将精力集中在实际需要他们关注的真正复杂病例上。事实上,可容易地想到这样的情况:甚至在医生参与进行其最终诊断之前,检验结果、实验室报告等由计算机系统独立地分析。
PIPCO系统100不试图确切地确定未来的医疗保健模型将如何工作。但是考虑到其分散性质及其从参与者105构建知识库的能力,无论其如何演进,它将为未来做好准备。
例如,考虑医学的生产线方法,特别是对于专家很少的偏远地区的患者。可容易地想到一种框架,其中:
·护士或初级内科医生查看患者并拍摄适合于其症状的一系列照片和/或视频。
·很可能在不同地点、具有一些计算机辅助诊断工具的高级医生团队要求某些检验或更多视频。
·由地理上分散的高级团队在共同研究检验和图像之后进行诊断。
·在护士/内科医生实际提供指令之后,规定适当的治疗。
PIPCO系统100可无缝地支持这种新医学模型。随访护士/住院医师将向PIPCO系统100发布最新的患者识别和保险数据以及所有诊断信息和图像。该信息将立即对专家和其他须知的代理316可用。归功于PIPCO系统100的集成,最适当的诊断、人工智能工具将对该数据进行操作。部分地基于计算机助手,将在正确地向过程中的所有方发送指令的情况下捕获高级团队的建议。一切将被充分记录,以使得没有任何歧义。如果患者在初始诊断后有问题呼入,则他将呼叫PIPCO系统100,并且将同时告知适当的各方/代理316。重要的是,这一结果可被事后研究。可容易地采用许多计算机工具以研究患者随时间的进展并且检查任何提供方在提供其护理时是否出错。换句话说,利用PIPCO系统100收集的数据,可准确地确定在医学实践中产生的过程错误,并且采取适当的保护措施来限制它们。
当医疗过程中的各个代理316完成其指派的任务时,PIPCO系统100可记录这种完成,使所提供的服务与患者的保险赔偿金匹配,并且允许保险公司进行支付。为了容易且安全地允许所有这些,PIPCO系统100可根据需要将区块链或同等支付技术并入其平台中。
更好的是,PIPCO系统100还将通过其应用编程接口(API)使其平台对外部服务提供商可用。利用这些,我们可能具有可行的外部提供方生态系统,其允许更大的护理交付效率。因此,允许患者在其电话上检查和记录其血压的血压监测装置的制造商可使用PIPCO系统100的API来将其持续发布到平台中的患者护理记录。然后,装置制造商必须做的就是集成到平台,曾经在PIPCO系统100中的数据将根据需要立即对所有护理提供方可用。继而,使用参与者105API的PIPCO系统100可根据需要无缝地为提供方/代理316更新适当的病历,以及基于这些结果是从患者所操作的不太准确的家庭装置获得的事实,关于这些结果的准确性的警告。更好的是,PIPCO系统100可运行其自己的人工智能(AI)工具以确定患者发布的数据是否足够严重(当针对标准测量误差进行了调节时),以保证提供方代理316立即关注。
如今的医疗保健公司部署了技术、系统、应用和过程的复杂混合,以为患者和医师服务并应对组织特质。这种混合涉及最先进的技术以及老旧的遗留系统二者。作为集成平台,PIPCO系统100必须自行设置为仅以给定参与者105工作一次。当PIPCO系统100完成其集成时,其益处将对PIPCO系统100的网络上的所有代理316均可用。因此,PIPCO系统100消除了各方集合之间的多个集成步骤,从而大大降低每个人的成本。因此,PIPCO系统100可带走提供方/参与者105的许多集成难题和成本,并且允许他们将精力集中在所交付的医疗保健质量上。
基于上文,清楚的是,PIPCO系统有可能激进地变革医疗保健过程,并且在仍不知未来会带来什么的同时这样做。新的过程技术(无论它们可能是什么)可容易地映射到PIPCO系统100的平台中。新技术,无论是区块链、人工智能还是别的东西,完全可无缝地集成到PIPCO系统100中。PIPCO系统100确实是用于未来的平台。
用于全球贸易的PIPCO系统的示例
过去几十年来,全球贸易急剧增长,许多发展中国家成为货物和服务外包的优选目的地。因此,自20世纪90年代初以来,中国已成为世界制造业强国,而印度已成为重要的业务过程外包枢纽。尽管生产和服务的这种全球分散化在过去几年才获得势头,但事实仍然是,这是极其复杂的过程,需要大量中介机构来提供便利。
国际采购中的挑战
涉及国内实体从海外生产商持续购买标准产品的简单对外事务涉及以下协助方中的一些或全部:
·全球运输公司,其将跨国运输生产的货物。
·全球保险公司和再保险公司,其为货物投保损失险,但通常不针对错过交付时间表。
·报关行,其应付繁琐难懂的进出口法规和关税,管理事务。
·银行或其它金融公司,其将处理跨境支付和任何流动资金、金融和汇率事务。
·律师,其商定合同条款,特别是解决争端的机制和场所。
·会计师,其跟踪所有事务和相关支付,并且确定适当的跨境及其它税。
当所讨论的事务变大时,中介机构的数量及其任务的复杂度增加。因此,从外国生产商持续购买大订单可能需要采购商监测实际生产并证实其质量,以及生产商满足各种不断变化的国际法规。对于全球分散式供应链,采购商可能还必须采取措施以确保其订单被及时交付,并且在必要时干预以帮助生产商。应对当地问题(例如恶劣天气、工厂罢工等)可能需要从不同地点一起采购。
当前技术应用于贸易
众多技术已尝试解决全球贸易所带来的许多问题。在一个极端,各种全球供应链软件技术允许将庞大的全球供应链集成到单个平台中,每个人都可登录该平台以管理他们的大部分持续事务需求。然而,其它平台已演变为支持交易过程的特定部分。因此,有些系统将纯粹处理海关处理,其它系统将只处理全球支付和相关货币交易,还有系统处理运输、保险等。尽管给定公司很有可能找到可能服务于其全球贸易需求的最佳技术组合,但是在不进行重大软件集成努力的情况下,无法使它们无缝地工作。
因此,对于全球贸易,技术现状是最大的公司已转向大体量、无所不包的供应链平台。这些昂贵的技术需要不仅在企业层面,而且其所有主要供应商的巨大集成努力。应对各种差异化产品的中型到大型公司常常不得不面对不断变化的系统和过程的复杂大杂烩。而较小的公司,甚至常常最大的公司,不得不求助于中介机构为他们提供所需服务。所有这一切表明,从新的外国供应商的海外采购对于大多数公司都是艰巨的,特别是开始时。即使以最好的技术运营和/或有中介机构进行贸易管理的公司也不得不转向新的提供方或一次性方法来应对特定问题。对标准过程的这些专门调整所需的知识属于公司中有能力的个人,很少被制度化。因此,关键人员的调离或终止常常会导致关键过程信息的丢失,特别是在应对技术无法预料到的独特瓶颈时。
PIPCO系统100可如何发挥作用
当PIPCO系统100应用于全球贸易中涉及的过程时可提供三个重要功能:
·便利化。PIPCO系统可用于以透明且灵活的方式实现全球贸易处理中涉及的某些必要步骤,从而允许显著的效率增益。
·制度化。通过强制以一致的方式看待贸易事务,PIPCO系统可允许关键过程步骤的制度化,以使得代理公司内的人员变动将不需要重新学习。
·变革。随着时间推移,PIPCO系统可潜在地改变贸易过程,在一些情况下急剧地改变。对PIPCO系统简单地通过强制完全透明带来的效率存在内在偏见。
换句话说,PIPCO系统100极其适合全球贸易。
传统方式的贸易融资
简单的示例将示出PIPCO系统为交易过程带来的益处。图18是一个银行事务中的现有技术过程流程的示意图。
考虑类似塔吉特(Target)的大型美国零售商,其想要订购小型高质量生产商(我们应称为VietPro)在越南制造的服装。当VietPro一次不经常地去美国时,因对VietPro的管理和产品留下深刻印象,Target可能被说服下了一个比如10000件的初始小订单。Target发现,其初始的一批VietPro服装已让其客户吵着要更多,并且愿意给予VietPro一个为下一销售季生产250000件的订单。
现在小制造商VietPro必须为其更大的订单采购原材料和劳动力,并且可能需要银行贷款来满足增加的流动资金要求。Target的采购订单应该使其当地银行愿意以有吸引力的费率快速推进这种贷款。然而,由于以下原因,通常将不会出现这种情况:
·当地越南银行不知道Target是谁或什么。即使能够查明,也无法验证订单的合法性。它必须联系美国的往来银行来为这一切充当其代理。
·Target出于竞争和隐私原因会不愿意公开其采购订单的所有细节。代表越南银行的往来银行将不得不应付Target的官僚主义并获得关于采购订单的合法性的声明。它还很可能不得不使用类似Dun&Bradstreet的商业信用公司来评估Target的信誉。
·当贷款最终被推进时,银行可能会对这笔贷款收取高得多的越南利率,即使这笔贷款以美元可以低得多的利率获得。另外,VietPro现在有美元的采购订单,贷款以美元计价的风险可能会小很多。VietPro根本没有专业知识来尝试用越南盾贷款对冲其美元敞口。
·没有美国银行参与这笔贷款,尽管它们都知道Target,因为他们不知道VietPro将表现如何。
利用PIPCO系统100的贸易融资
PIPCO系统100可方便上述过程,以及对其进行变革以使其更简单,如图19所示。具体地:
·Target将在PIPCO系统上发布其采购订单。由于PIPCO系统了解这是采购订单(基于过程知识数据库中的信息),所以它已经知道只有Target的授权人员才能发布这种订单。因此,如果这种订单在PIPCO系统上,则它必须是真实的。
·类似Dun&Bradstreet的信用机构可自动链接到PIPCO系统的平台中。因此,甚至在越南银行请求之前,关于Target的诚信的所有信息就将对银行可用。
·VietPro只需针对该事务将其当前银行指给PIPCO系统,贷款批准所需的所有数据就将立即可用。
显然,在上述情况下PIPCO系统确实提供了一些显著的益处。事实上,如果对于跨不同国家的文档和图像,需要翻译文档或需要更改格式,则考虑到其领域知识,PIPCO系统可无缝地处理所有这些。原始过程中的参与者(类似上述往来银行)也会变得多余。
利用PIPCO系统100的其它贸易过程
PIPCO系统100可随时间推移完全变革贸易过程。Target与VietPro的最初几笔订单都很成功,该公司决定使后者成为重要供应商,并且接下来想要下一笔2000000(200万)件服装的订单。现在,鉴于VietPro的重要性,Target必须对其进行更严密的审查。它需要确保VietPro可扩大其业务规模,满足其交付期限,并且对于大额初始付款和进度付款其管理可信赖。Target可能必须向VietPro的工厂派遣检查员以监测其状况,确保满足安全和其它童工标准等。如果VietPro没有公布财务报表,则它可能还必须对VietPro进行定期财务审计。
因此,Target在使VietPro成为主要供应商的道路上面临重重障碍。有着不同的经营习惯和语言的遥远领域中相对未知的供应商意味着Target必须以更显著的方式真正承诺从越南采购。它必须派遣能够定期前往越南的人员,支付其员工或第三方监督员以对VietPro进行尽职调查,并且需要随时间推移持续这样做。这种监测可由专门的Target团队或由重点监管Target人员设置或知晓的外部中介机构完成。这里的监测过程即使对于最大的公司也仅是部分结构化的。关键Target人员的离职并不意味着来自先前监测活动的数据丢失。相反,这将意味着Target的知识损失,因为在监测中做出的许多临时决策根本没有充分记录或排序,因此几乎不可能全面了解过程。毫无疑问,Target增加其对越南的敞口的成本相当大。不幸的是,VietPro最终将支付大部分费用,因为Target只会要求更低的价格。
PIPCO系统100可急剧改变执行这些事务的方式。重要的是这里需要注意,Target在越南的供应商可能很少,因此可能几乎不需要开发用于在该国交易的泛化过程。另一方面,PIPCO系统预期将在全世界与众多越南供应商和Target等同物签约,并且在使过程动态更容易且更便宜方面有既得利益。具体地,如图20所示,PIPCO系统可执行以下所有功能:
·对Target可能与VietPro进行的所有事务进行排序,包括记录所有聘请的审计员/监督员,以及提供所有其报告的翻译和验证副本。这将提供以前不可用的过程的全貌。
·向职责是监测类似VietPro的公司的外部公司开放过程。Target可简单地从这组监督公司中选择以为VietPro寻找可取的审计师,而非重塑此轮。
·一旦工作完成,就从Target及其他获得关于监测公司的成功及其定价的反馈。这些评述将形成从实际验证的用户对服务提供商进行客观评级的基础。
·引入可信担保人,该担保人将实际保证VietPro及时履行并遵守工作标准,根据需要承担监测责任。这种担保将使Target完全无需进行任何监测。如果这由政府间机构完成,则可能有助于使越南成为更容易的采购地点并且可致力于促进该国的贸易。
·与越南中央银行合作来跨货币汇总越南公司的采购订单并以采购订单计价的货币向这些公司提供资产支持贷款。这对于想要针对低风险事务以发达国家可用的低利率借贷的高利率国家将特别有益。
用于保险理赔的PIPCO系统100的示例
财产和意外伤害(P&C)保险业特别适合于PIPCO系统的应用。全球理赔过程是保险业中最复杂且成本最高的过程之一。除了它们实际对相关损失进行的支出之外,全球保险公司每年仅在P&C索赔的管理方面就花费超过200亿美元。尽管事实上,行业中的大多数公司实际已开始削减成本并且在其索赔处理过程内大量使用技术。
大部分P&C索赔处理过程涉及保险公司与外部代理(例如其它保险公司、再保险公司、索赔理算师、代理和律师)之间的交互。尽管公司可能改进了其内部过程,但它们对与这些外部代理的交互几乎没有控制权,其中许多外部代理可能在完全不同的户籍或司法管辖区。另外,索赔过程和遗留系统因公司和国家而显著变化,没有单一论坛或系统可在过程中涉及的各种群体之间快速提交和交换索赔信息的所有元素。
PIPCO系统特别适合应用于全球财产和意外伤害保险业。该平台可极大地简化理赔中涉及的外部交互,带来显著的成本降低。
保险索赔中的参与者105
保险索赔涉及两个或更多个公司;它可能本质是对抗性的;它可能跨地理边界;它可能需要专门的工程和会计工具和过程;一方或更多方可能对索赔提起诉讼;并且,可能需要几个月或几年才能解决。必须收集和编制大量信息。没有中央、可访问的办公室来充当所有(或就此而言,过程中涉及的任一方)的焦点。信息共享和通信经由传真、电子邮件、快递、标准邮件、电话和面对面会议来进行。下面列出可能的参与者:
·公司保单持有人通常发起索赔过程,确定其保险需求和水平,在限额内自我保险,并且管理其内部索赔过程。
·经纪人常常代表客户处理索赔过程,与个人和公司就保险需求进行咨询,确保保险范围。
·承保人利用索赔经验来承保和定价产品。
·再保险人基于情况或承运人经由再保险提供增加的金融保护。
·理算师收集索赔信息,安排测试,研究索赔。
·会计师确定与损失相关的成本。
·工程师确定损失的情况和细节。
·索赔经理协调索赔过程,收集和编制信息,指导内部和外部律师,批准专家和顾问,制定协议和程序。
·律师根据需要参与。
当前索赔过程
考虑如图21所示的典型全球货运保险索赔将示出过程的复杂性。该示例实际上在海事索赔领域相当简单,但快速示出了解决此类索赔所面临的复杂性。
总部在伦敦的海上保险公司接到电话,告知其一艘其投保的船舶在马尼拉与码头发生碰撞。该保险公司聘请当地独立索赔理算师进行初步评估,并且建议其中国香港办事处监督诉讼程序。码头所有人向其保险公司通报了损坏情况,并声称船长有过错。其保险公司是在美国注册的公司,它聘请自己的当地独立理算师进行评估。各个保险公司提醒各自的律师事务所可能的行动,然后各个律师事务所聘请马尼拉的对应律师事务所。损坏是大规模的,导致各个保险公司聘请当地工程公司来研究损坏。各个被保险人还向其保险公司寻求业务中断成本,促使会计师需要设定初始损失准备金。损坏使得它们不仅进入伦敦保险公司的自留水平,而且进入更高水平的再保险,促使需要告知其再保险经纪人,并且通过他们告知其再保险承运人。
上述情况中的所有信息经由电话、传真、电报、电子邮件、标准邮件、国际快递和面对面会议来交换。很快就有许多个人参与其中,各个保险公司的理赔经理试图组织和跟踪其团队的信息流。访问实时数据或与索赔有关的全面、最新的信息几乎是不可能的。
现有全球索赔系统没有任何机制来协调参与其中的所有代理。尽管交互本身可能经由电子邮件或其它标准化电子方法已流线化,但是过程本身涉及跨代理的多个交互,而没有任何关于索赔进度的集中信息或控制。因此,参与者之间的交互的总成本相当大,即使当前各个交互的成本很低。并且成本远大于仅通信成本。各个保险公司内的内部过程必须朝着支持需要被告知索赔状态的各种代理进行调整,由于造成众多冗余,这导致效率极其低下。
毫不奇怪,在本示例中,整个索赔将花费数月来解决。事实上,即使是简单的数据交换也可能花费数周甚至数月。
具有PIPCO系统100的索赔系统
PIPCO系统100特别适合于全球保险索赔的管理。PIPCO系统100可提供简单框架,所有索赔参与者均可在该框架内工作,以使得它们可有效地协调其活动。该系统的设计将消除过程和数据冗余二者并极大地加快整个理赔过程,同时降低成本。
PIPCO系统的方法是建立基于web的全球互联网服务局,其将专门负责保险索赔信息、处理和管理。在服务器设施内,虚拟索赔办公室(VCO)将专门负责各个个体保险索赔。VCO将在索赔有效期内有效,可使用基于互联网的浏览器技术从全球任何位置轻松访问。虚拟索赔办公室(VCO)将由以下组成:
·虚拟索赔代表(VCR),其与索赔中的各个参与者105对应,其行为将完全由真实参与者指定。VCR将确定如何处理到达VCO的信息。
·虚拟文件柜(VFC),其将允许索赔中的各个参与者105将与该索赔相关的信息发布到集中位置。其他代理316对参与者105的代理316发布到VFC的信息的访问将由他所建立的VCR控制。
尽管VFC和VCR是使保险过程更容易理解的术语,但这些概念很容易映射到PIPCO系统100的功能。VFC是PIPCO规范存储库300的一部分,VCR是规范存储库300、过程知识引擎400和执行引擎500的组合。
基于web的VCO将类似于真实的索赔办公室,每天24小时由来自索赔中的各个参与者105的代表值守。各个代表(PIPCO系统100中的代理316)可充分访问其对应雇主/参与者105可用的所有信息,其被放置在他有钥匙的安全文件柜中。基于其雇主(PIPCO参与者105)所制定的规则,他将与索赔办公室中的其他人(代理316)共享其文件中的适当信息子集。当代表从办公室中的另一位接收信息时,他可被指示立即联系其雇主,或者另选地可被授权代表其雇主以有限的方式行事,也许通过联系办公室中的又一代表来发起其它事务。
根据其基本设计,全球保险虚拟索赔办公室将在索赔经理(将是PIPCO系统100中指定的代理316)的控制下提供最新的、集中的、交互的信息存储库,并且可由所有授权方/代理316根据需求立即访问。在上述示例中,各个代理316每天直接向驻留在服务器上的索赔节点提交报告、数据或其它信息。每次提交具有用于PIPCO在VCO建立时为特定保险公司参与者105设计的管理和访问的嵌入式协议。因此,索赔经理和其他授权代理316对他们被允许使用的所有信息具有即时24×7访问。并且,这些信息已在需要时被翻译,因此可在用户的系统上查看,而无需购买昂贵的软件或增强功能。
虚拟索赔办公室不仅仅是交换或在线文档共享系统。它实际上是虚拟办公室,因为参与者105的VCR可完全实现参与者的索赔管理规则。因此,该VCO不尝试篡夺遗留系统的角色或尝试更改任何特定参与者(105)领域内的索赔过程的结构。即,任何参与方均可将其外部交互过程映射到VCO中,而不必更改其内部过程。
对于索赔中的给定参与者105,PIPCO系统100将与多个其他代理316的众多、昂贵的交互替换为与PIPCO系统本身的单个事务集合。事实上,使用web,即使该单一事务也有可能具有低于如今常常文档驱动的物理交互的成本。图22示出PIPCO重整的索赔过程如何工作。
PIPCO系统100将多个代理316事务替换为各自的单个VCO事务。它消除了冗余。并且它向所有参与者105和代理316提供集中过程协调和反馈,这如今根本不存在。毫不奇怪,PIPCO系统100代表了理赔的真正成本和时间节约方法。它有可能将理赔时间框从数月缩短到数周或数天。
PIPCO系统100作为其它技术的基础的示例
过去几年来,有众多技术概念受到了显著关注。这些技术的非穷尽列表将包括:
·区块链,一种分布式账本概念,因加密货币比特币的增殖而流行。
·人工智能,其涉及将计算机变成智能机器人助手,用于各种活动,包括接听电话、付款、传递简单信息等。
·大数据分析,其是指在如今的数字世界中针对特定模式存储和挖掘大量数据以预测行为、销售等的许多方法。
·应用编程接口(API),用于向外部应用和开发人员开放技术。
下面讨论PIPCO系统100与这些概念的关系,要注意在上述情况中,仅区块链可能是真正新的和不同的。在下面的讨论中,为了方便,将省略PIPCO系统的标号100。
PIPCO系统下的区块链
区块链是分布式数据账本,其中众多代理持有账本副本,以使得不存在单点故障。参与者可基于定义事务的严格规则将事务添加到该账本。在特定数量的潜在事务累积成所谓区块之后,它们被提交给集合代理网络以便于批准。在其他参与者根据其账本副本验证事务之后同意鉴于网络规则,这些事实上合法且允许之前,该区块(以及其内的事务)无法完成。一旦达成这种约定,网络中的各个代理就更新其账本副本,使得几乎不可能更改约定的条目。在任何给定时间点,各个代理持有系统中发生的约定事务的完整历史。因此,我们最终拥有稳健的分布式事务历史,其在没有整个网络的合作的情况下无法被改变,并且任何参与者可从这确定当前或过去任何时候的账本状态。区块链中用于就事务约定并确保约定的区块变得不可变的方法是新颖的,尽管它们很复杂。首先,区块链必须许可可在网络中进行事务的参与者以及他们可执行的事务。其次,当区块需要验证时,必须有足够大的代理组来执行验证过程。该过程极其复杂,需要检查所讨论的事务的需求以及以不断变化的输入求解非常困难的预定数学谜题,这甚至会占用强大的计算机几天时间。当区块链网络中的任一个参与者求解谜题并验证其正在操作的区块时,它会向网络宣告此事实。此时,其结果的正确性由网络中的其他人检查,之后区块可被接受。多个代理可能同时验证两组不同的事务,然后复杂的规则决定要拒绝哪组事务以及应该如何使链稳定以防止分叉。
数学谜题的美妙之处在于,即使单个计算机需要很长时间来求解,但是当提出给足够大的计算机网络时,其中一个计算机会仅仅在几分钟内就偶然找到正确的答案。因此,同一计算机极不可能针对需要验证的若干连续区块正确地求解该谜题,要做到这一点,该计算机必须自己与整个代理计算机网络的力量较量。
一旦数学谜题被求解,其它计算机就全部验证结果,一旦完成,区块就被提交到账本。重要的是,新区块接收一些识别信息,这些信息将其链接到最后接受的区块的标识符以及区块本身内的数据。为了验证区块没有因此改变,参与者需要应用数学计算,输入是前一区块的标识符和当前区块的内容。如果这些结果与区块上的识别信息匹配,则其必须合法。即使新区块中的单个元素改变,计算结果也将发生巨大变化。
区块链中的编码过程的性质和数据的分布式性质意味着链中的事务无法撤销。撤销事务的唯一方式是网络中的大多数节点在过程中勾结,这通常是不可能的。同样,如果单个腐败的代理试图发布一个区块的有效事务,然后是假设第一组被接受则将被无效的一个区块仍然正确的事务(类似加倍支付而账户资金不足),则理论上可能有人会试图在网络规则上作弊。然而,代理自己使这两个事务有效的唯一方式是让自己的计算机在这两个连续事务集上破解相关数学谜题。然而,由于需要求解以进行验证的数学谜题的复杂性,这在统计上很难实现。
另外,区块链网络不会受到中央数据库可能遭受的标准黑客攻击,因为不存在单点故障。真正危及区块链网络的唯一方式是某一或某些代理控制网络中50%以上的计算节点。因此,由于需要共识和验证所需的数学技术,区块链网络通过设计正确地工作。个体参与者可能不可信,但是网络规则仍然允许我们信任区块链中的数据。
为了接受区块而执行复杂验证计算需要整个网络中相当大的计算能力,没有单个计算机或组比组合的其余网络能力更强大。因此,必须激励众多计算机成为区块链计算“节点”以执行这些计算。支付给这些节点的服务报酬实际上是使用区块链网络的服务费。比特币加密货币网络是运转的区块链的第一个示例。根据其规则,任何参与者可安全且匿名地向任何其他参与者转让比特币。使用复杂的加密方法来安全地识别发送方和接收方二者。通过支付少量比特币来给予验证计算的比特币节点(所谓“矿工”)其服务报酬。
区块链作为技术带来一些显著优势,其中尤其是如果需要可完全匿名并且事务完全安全。尽管如此,区块链还使得不可能返回以及逆转过去的错误,至少假设即使允许,在没有巨大的复杂程度的情况下也不可能。同样,区块链缺少用于维持账本的中央机构。可为此成立行业小组,但这种小组的目的必须是应对与网络本身的规则有关的问题,而非处理具体的争议或事务。因此,并非所有过程均适合于区块链技术,即使它们从表面上看起来可能如此。即使在某些元素适合的情况下,在较大过程的上下文中将它们迁移为使用该技术也绝非易事。根据设计,PIPCO系统是涉及数据、知识和执行规则的分布式过程枢纽。它是允许集成众多不同的技术以用于解决特定业务领域内的特定协调问题的使能系统。因此,PIPCO系统可根据需要容易地将区块链技术并入其结构中。事实上,随着时间推移,PIPCO系统及其积累的过程智能将能够评估其过程流程的哪些部分最适合于类似区块链的技术,哪些可能由更传统的方法更好地服务。因此,PIPCO系统可根据代理的类型存储其事务数据中的一些或全部,其中跨整个参与者网络或其子集进行区块链式加密。根据过程的各个步骤需要什么,它可将分布式账本以及集中式数据库二者无缝地并入其框架中。更简单地说,PIPCO系统的平台是区块链的巨大超集。
从类似区块链的新技术可如何通过PIPCO系统并入业务过程中的角度来看,应该清楚的是,PIPCO系统远不止是一种特定技术,它是尝试使用最佳特定技术来求解特定领域问题的技术框架。
具有PIPCO系统的人工智能
作为概念,人工智能(AI)并不新鲜。计算机科学研究人员最早的目标之一是构建可模仿人类行为的一些元素的计算机系统,达到至少可像原始动物的程度。然而,最近,归功于语音激活电话助手(例如苹果的Siri或谷歌的OK Google)、自驾驶AI辅助汽车的前景以及家庭助手(例如Amazon Echo),AI吸引了公众的注意。
大多数计算机科学家都同意,当关注领域有限时,AI技术效果最好。我们可能永远不会达到这样的情况:我们有类似星际迷航的计算机,它理解口语的所有细微差别。然而,我们已经有可辅助类似进行电话支付、提供信息等的特定任务的计算机。领域越有限并且信息质量越好,AI的前景越好。
PIPCO系统的职责是收集过程数据,特别是根本没有以任何形式组织的数据。利用该数据,PIPCO系统旨在辅助其平台中的代理重新思考并以允许最大效率的方式重整其过程活动。因此根据其设计,PIPCO系统是智能平台,它从自己的参与者学习并使平台上的所有其他人均可借鉴以使他们受益。
PIPCO系统收集并分析过程数据,从这一点来讲它已经是运转的AI的示例。同样,通过使用其数据并首先关注业务过程中最昂贵的部分,PIPCO系统将允许使用简单成本效益计算来增量应用AI。最后,PIPCO系统可通过简单地将来自多个代理的信息捆绑在一起并且在绝对没有可用帮助、集中式或其它的场所中辅助,来将全新的AI元素并入其平台中。出于所有这些原因,我们相信PIPCO系统将很可能是在业务过程的上下文中正确完成的人工智能的最终示例。
利用PIPCO系统的大数据分析
作为过程结构存储库,PIPCO系统存储过程知识,并且存储数据本身或具有访问数据的规则。当然,根据领域,所讨论的许多数据可被加密,因此即使PIPCO系统可访问也无法理解。然而,PIPCO系统是数据传输通道的事实意味着它可容易地使数据分析工具可用,同时提供其所需的数据库结构。
以其最偏执的形式,PIPCO系统可简单地用于将来自参与代理的加密数据输送给数据分析包或服务,因此将这些各方聚集在平台上。更典型地,如果PIPCO能够访问数据元素,则它可能能够使用一系列工具来实际分析数据本身,同时仍遵守其所所需的隐私和其它规则。换言之,由于PIPCO系统知道它能够访问数据的规则并实现这些规则,所以它可在相同的约束下工作以提供适合于代理的最佳分析工具。因此,PIPCO系统将通过允许代理仅根据需要将分析所需的内容迁移到平台来使数据挖掘的整个概念更简单。
利用PIPCO系统的应用编程接口(API)标准化
API的概念并不新鲜。事实上,大多数软件系统均提供某种API以用于定制。然而,过去几年中,众多公司一直在努力建立有用的网络呈现。大多数都有网站,但在在线提供实质性功能的意义上并非每一个都是支持web的。一些公司经由API向外部开发人员开放其内部系统,从而完全接受了新技术。许多实际本身是技术公司,其对提供API的兴趣是围绕其产品和服务与外部开发人员构建大型生态系统。
围绕API成功构建的生态系统有很多示例。Salesforce.com从其发布第一天就创建了API,以支持以新颖的方式使用其平台。Ebay于2000年推出其API,以允许其网络中的参与者将其拍卖平台更完整地集成到其业务过程中。谷歌地图具有允许外部网站将地图功能无缝地集成到其设置中的API。其它示例包括Twitter、Facebook、Instagram等,其全部提供了API,这些API导致了繁荣的外部用户社区,其以新颖的方式将这些公司所提供的功能调整为自己使用。
作为集成平台,PIPCO系统以两个方式受益于API。首先,当参与者已为其提供API时,PIPCO系统可更容易地将参与者集成到其平台中。事实上,没有这些API,PIPCO系统将不得不为大型系统/参与者开发API以实际允许其集成。其次,PIPCO系统提供自己的API以允许新参与者集成到平台中。即,以前可能必须学习多个公司的API以提供其服务的外部开发人员可依靠PIPCO提供单个API来与给定领域中的众多代理接口。
在这种情况下需要注意的重要一点是,PIPCO系统被设计为尊重参与者(105)的安全要求,因为它的核心旨在允许外部集成。因此,通过向外部服务提供商/参与者提供自己的API,同时使用参与者的API连接到参与者侧技术,PIPCO系统可缓解来源于大量外部开发人员/参与者访问内部系统的所有参与者的众多难题。PIPCO系统可容易地用作参与者与外部开发人员/参与者之间的单一通道,并且仅仅通过控制公开的功能就可做到这一点。
实现PIPCO系统100
在行业/领域中实现PIPCO系统100需要开发技术,签约参与者,并且细化和定制系统以适合参与者。
将PIPCO系统100从概念变为现实将涉及以下步骤:
·构建用于平台的核心技术基础设施,基本集的基元功能(primitive function)跨大多数领域都会有价值。这种结构将具有用于存储和检索过程知识(包括数据和设置)的机制。
·以适当的定制向特定领域营销PIPCO系统100。这涉及市场研究、销售、过程咨询和系统集成努力。目标是将关键量的初始参与者签约到仍基本但高度可定制的PIPCO系统100。
·针对现有参与者105以更多的功能细化和扩建PIPCO系统100,同时签约新的参与者105。
重要的是需要注意,PIPCO系统100在设计上是低成本和增量推出的。它不是短期解决方案,而是长期的过程基础设施投资。下面进一步描述上述各个步骤。
构建核心基础设施
如前所述,用于领域的PIPCO系统涉及规范存储库300、过程知识引擎400、领域编程/过程规范语言200和执行引擎500。这些核心基础设施允许给定领域的快速实例化。具体地,核心技术涉及:
·规范存储库300的数据存储设计。需要指定可能被存储或远程访问的每一种类型的数据,无论是文本数据、图像数据、照片、音频/视频文件等。接下来,需要建立用于数据的存储和快速访问的机制,无论是关系型、面向对象的、noSQL(图形或分布式列表)等等。需要无缝地映射到过程知识引擎400中的数据安全模型。重要的是还需要注意,数据只是PIPCO系统100认为是资源306的一部分内容。从PIPCO系统100的角度,资源306包括数据以及可由系统100或其参与者105和代理316执行的原子功能、动作等。
·过程知识引擎400设计。需要为各个代理316的过程规范设计模型,包括其查看/编辑数据、查看其他代理316的过程步骤和数据的权限以及总体过程历史。还需要设计用于对各种过程步骤319以及可能若干独立但合作的线程可视化以及如果需要排序的框架。
·在数据设计的上下文中实现核心过程319规则的执行引擎500。
需要注意的重要一点是,PIPCO系统100的力量很大程度上来自于其从当前过程方法抽离,反而聚焦于给定领域中的所有参与者105可最终移向的构思的能力。因此,PIPCO系统100的核心技术必须相当通用,甚至可在没有决定初始目标领域的情况下开发。
向领域定制和营销
为了使PIPCO系统100理想地工作,给定领域中关键量的代理316将参与该平台。代理316也必须具有不同的类型,以使得平台的能力可被充分利用。此外,为了签约这些代理316,需要以高度可靠性提供一些合理功能的工作系统。
可为定制领域解决方案构建PIPCO系统100,其具有三个组:
·因其在领域过程和系统技术方面的专业知识而被聘用的PIPCO系统100员工。该领域团队将领导PIPCO系统100的初始过程平台需求和领域定制。
·来自潜在客户参与者105的高级管理成员,其愿意提供关于其过程和技术基础设施的信息,以使得PIPCO系统100可开发将满足其一些需求的定制解决方案。
·行业专家和咨询公司,其在PIPCO系统100中看到显著未来集成业务的前景。
实现很可能是多月项目,特别是对于大型公司参与者105。
与PIPCO系统100合作的初始参与者105对其成功至关重要。如果它们在领域中足够大,则仅其影响就可能允许PIPCO系统100将其提供方作为代理316签约到平台中。因此,我们预期第一批大型参与者105将成为战略合作伙伴,其将被集成到PIPCO系统100中,除了继续合作之外几乎不收取费用。
PIPCO系统100的初始推出是相对原始的。因此,它可能仅涉及文档查看以及确定哪些参与者105和代理316可看什么信息和什么格式的访问规则,以及简单的过程排序。然而,平台的后续迭代将越来越强大并且扩展这些基本功能。
细化和扩建
一旦平台上线并以关键量的参与者105运行,PIPCO系统100就不会很难签约参与者105。PIPCO系统100所带来的先进技术将允许与PIPCO系统100签约的各个参与者105提出自己的定制“数字战略”,这将使他当下(如果不是未来)突飞猛进。
另外,一旦参与者105被集成到PIPCO系统100的平台中,就不必担心新技术的集成,因为这可由PIPCO系统100有效地处理。参与者105的主要焦点将在他自己的内部过程上,以及如何最好地改变这些过程以是最高效的。最终,随着参与者组织105开始意识到PIPCO系统100所提供的灵活技术构建块,PIPCO系统100很可能更加渗透到参与者组织105中。
随着PIPCO系统100开始了解参与者105的过程流程,它能够提供更多定制。这些增强可能采取过程的更多元素可被移到PIPCO系统100的形式,或者另选地,使用PIPCO系统100上可用的工具和服务来重整各种参与者过程319。如反复指出的,PIPCO系统100的吸引力在于,将不必进行这些改变中的任何改变,除非参与者105期望效益,只有当他觉得这样做的成本远低于他可能实现的效益时,他才会采用这些改变。
用于给定行业的PIPCO系统100可由以共同愿景一起工作的三个不同小组组成:
·技术开发小组,其负责核心技术平台的实际设计和增强。该小组将配备有经验丰富的软件开发人员,其了解最新技术和发展,而不是行业专家。该小组的初始焦点将是开发可为各种潜在参与者105快速定制的PIPCO系统100的工作实现。
·销售和营销小组,其至少最初配备有来自PIPCO系统100所针对的特定行业的专家,他们可向所涉及的各种参与者105的高层管理说明PIPCO系统100和技术。团队的第一要务将是通过向平台签约足够的领域参与者105来达到关键量。
·实现和运营咨询小组,其与已签约的行业参与者105共事以规划其内部过程和遗留系统,以确定如何最好地将其与PIPCO系统100接口。该小组实际上等同于具有目标行业专业人员、过程工程师和技术专家的组合的系统咨询小组。
为了成功地为给定行业开发PIPCO系统100,最大的挑战是从高级行业管理获得一定程度的初始支持。参与者105的承诺将是让PIPCO系统100开发从参与者105的现有过程和数据存储到平台的适当挂钩。通过初始承诺,预期PIPCO系统100的推出将相对无痛(但愿如此),因为至少在一开始,它承诺对现有参与者105过程的中断如此少甚至没有。
PIPCO系统100需要对目标行业的过程流程有深刻了解。了解越好,编程语言200以及过程知识引擎400和执行引擎500就越灵活。规范存储库300由给定行业的PIPCO系统100中的参与者105驱动,而所讨论的语言将是属于PIPCO系统100的受版权保护的知识产权。因此,给定行业的PIPCO规范语言200的功能不易被竞争对手复制,除非所讨论的竞争对手在与PIPCO系统100相同的参与者105上签约。
最后,尽管互联网在许多方面已成熟,但涉及到业务过程时其使用仍相对原始。尽管web大致稳定并且核心技术相当稳健,但仍有众多小问题困扰着所有基于web的系统。实时、关键任务的基于web的事务系统仍很难可靠地设计。对于时间要求不特别严格的领域,PIPCO系统100是理想的。参与者105的几分钟中断然后很可能导致最小程度的中断。
PIPCO系统100的益处
PIPCO系统100提供了独特且强大的新协调架构,以允许领域中的企业更好地与它们与之交互的外部代理共事。其设计既有自上而下的构思,也有自下而上的构思。PIPCO系统利用对行业的过程流程及其在未来可能如何演进的大量自上而下的知识来设计。然而,其核心实现完全是自下而上的,因为该平台最初被设计用于跨代理提供最基本协调。
PIPCO系统100生成显著的切实效益。从理论角度,它大大减少了跨领域中的代理所需的通信链路的数量以及存储要求。实际上,它允许各种参与者组织基于相对于他们将更多功能迁移到该结构需要花费什么,他们期望节省什么,来增量地采用该平台。随着时间推移,PIPCO系统100将激进地变革它所掌握的每一个行业。PIPCO系统提供了未来的过程框架,幸运的是,其可利用如今的计算机技术来实现。
本文所示出和描述的本发明的特征是优选实施方式。因此,将理解的是,所附权利要求旨在涵盖所公开的变型以及具有非实质性差异的不可预见的实施方式,其在权利要求的精神内。

Claims (24)

1.一种用于跨领域中的至少两个参与者协调过程以允许在不同平台上操作的所述参与者的互操作的系统,各个参与者具有至少一个资源和一个代理,其中,来自参与者的代理向另一参与者请求资源,并且所述另一参与者根据请求提供所述资源,其中,从一个参与者到另一参与者的所述过程包括至少一个过程步骤,所述系统包括:
a.过程规范语言,所述过程规范语言识别所述领域的各个参与者、资源、代理和过程步骤的至少一个相关术语;
b.规范存储库,所述规范存储库使用以所述过程规范语言识别的术语来存储至少一个参与者、资源、代理和过程步骤的信息,其中,各个过程步骤由至少一个参与者、资源和/或代理定义,并且按事务层次结构组织;
c.过程知识引擎,所述过程知识引擎针对从一个参与者的所述代理对来自另一参与者的所述资源的请求在所述规范存储库中识别和跟踪相关过程步骤,根据请求提供所述资源;以及
d.执行引擎,所述执行引擎执行由所述过程知识引擎识别的所述相关过程步骤,基于存储在所述规范存储库中的用于所述代理和所述资源的信息针对所述资源管理请求所述资源的所述代理,并且利用所述过程知识引擎所跟踪的所述过程步骤来更新所述规范存储库。
2.根据权利要求1所述的系统,其中,存储在所述规范存储库中的所述资源的信息包括所述资源的身份和/或位置。
3.根据权利要求1所述的系统,其中,存储在所述规范存储库中的所述代理的信息包括所述代理访问至少一个资源的证书、权限和/或许可。
4.根据权利要求1所述的系统,其中,所述规范存储库包括按原子资源和/或资源层次结构组织的所述参与者的所述资源的至少一个映射。
5.根据权利要求1所述的系统,其中,所述规范存储库包括按身份、角色、证书和/或代理层次结构组织的一个或更多个参与者的所述代理的至少一个映射。
6.根据权利要求5所述的系统,其中,所述过程知识引擎包括按过程定义层、关系层和对象层次结构层组织的参与者之间的所述过程步骤的至少一个映射。
7.根据权利要求6所述的系统,其中,所述规范存储库包括用于针对由所述过程知识引擎使用所述关系层跟踪的所述过程步骤存储来自所述执行引擎的更新的知识/过程状态数据库。
8.根据权利要求6所述的系统,其中,代理被指派给代理类并且过程步骤被指派给事务类,并且所述关系层按所述代理类和所述事务类组织。
9.根据权利要求6所述的系统,其中,所述过程定义层按多个过程步骤的各种排序组织。
10.根据权利要求6所述的系统,其中,所述对象层次结构层按事务层次结构和代理层次结构组织。
11.根据权利要求5所述的系统,其中,所述执行引擎利用所述证书映射管理所述代理。
12.根据权利要求7所述的系统,其中,所述执行引擎利用所述关系层相对于所述过程步骤管理所述代理。
13.根据权利要求6所述的系统,其中,所述系统包括中央系统和至少一个参与者处的本地系统,并且所述本地系统维持来自所述中央系统的与所述参与者有关的所述身份映射和过程步骤映射的副本。
14.一种用于跨领域中的至少两个参与者协调过程以允许在不同平台上操作的所述参与者的互操作的方法,各个参与者具有至少一个资源和一个代理,其中,来自参与者的代理向另一参与者请求资源,并且所述另一参与者根据请求提供所述资源,其中,从一个参与者到另一参与者的所述过程包括至少一个过程步骤,所述方法包括以下步骤:
a.提供识别所述领域的各个参与者、资源、代理和过程步骤的至少一个相关术语的过程规范语言;
b.提供规范存储库;
c.使用所述规范存储库中的所述术语来存储至少一个参与者、资源、代理和过程步骤的信息,其中,各个过程步骤由至少一个参与者、资源和/或代理定义,并且按事务层次结构组织;
d.针对从一个参与者的所述代理对来自另一参与者的所述资源的请求在所述规范存储库中识别相关过程步骤,根据请求提供所述资源;
e.执行识别的所述相关过程步骤;
f.基于存储在所述规范存储库中的用于所述代理和所述资源的信息针对所述资源管理请求所述资源的所述代理;
g.跟踪所述相关过程步骤;
h.提供知识/过程状态数据库;以及
i.利用跟踪的所述过程步骤更新所述知识/过程状态数据库。
15.根据权利要求14所述的方法,其中,存储在所述规范存储库中的所述资源的信息包括所述资源的身份和/或位置。
16.根据权利要求14所述的方法,其中,存储在所述规范存储库中的所述代理的信息包括所述代理访问至少一个资源的证书、权限和/或许可。
17.根据权利要求14所述的方法,该方法还包括以下步骤:
j.按原子资源和/或资源层次结构组织所述资源;以及
k.在所述规范存储库中提供按所述原子资源和/或资源层次结构组织的至少一个资源映射。
18.根据权利要求14所述的方法,该方法还包括以下步骤:
l.按身份、证书和/或代理层次结构组织一个或更多个所述参与者的所述代理;以及
m.在所述规范存储库中提供按所述身份、角色、证书和/或代理层次结构组织的至少一个映射。
19.根据权利要求14所述的方法,该方法还包括以下步骤:
n.按过程定义层、关系层和对象层次结构层组织参与者之间的所述过程步骤;以及
o.提供按所述过程定义层、所述关系层和所述对象层次结构层组织的至少一个映射。
20.根据权利要求15所述的方法,该方法还包括以下步骤:
p.将代理指派给代理类;以及
q.将过程步骤指派给事务类;
其中,所述关系层按所述代理类和所述事务类组织。
21.根据权利要求19所述的方法,该方法还包括以下步骤:
r.在所述过程定义层中组织多个过程步骤的各种排序。
22.根据权利要求19所述的方法,其中,所述对象层次结构层按事务层次结构和代理层次结构组织。
23.根据权利要求19所述的方法,其中,所述关系层用于跟踪所述相关过程步骤。
24.根据权利要求19所述的方法,其中,所述关系层用于管理所述代理。
CN202080103315.2A 2020-06-29 2020-06-29 用于跨不同系统、平台和/或业务的过程协调和互操作的系统 Pending CN117083603A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2020/040180 WO2022005453A1 (en) 2020-06-29 2020-06-29 System for process coordination and interoperability across different systems, platforms and/or businesses

Publications (1)

Publication Number Publication Date
CN117083603A true CN117083603A (zh) 2023-11-17

Family

ID=79317010

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080103315.2A Pending CN117083603A (zh) 2020-06-29 2020-06-29 用于跨不同系统、平台和/或业务的过程协调和互操作的系统

Country Status (5)

Country Link
EP (1) EP3956779A4 (zh)
KR (1) KR20230029479A (zh)
CN (1) CN117083603A (zh)
AU (1) AU2020456098A1 (zh)
WO (1) WO2022005453A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115689506B (zh) * 2022-11-07 2023-10-20 中国船舶重工集团公司第七一九研究所 一种船舶三维设计中跨系统物理接口管理方法
CN117252676B (zh) * 2023-11-20 2024-02-02 成都新希望金融信息有限公司 业务处理方法、装置、电子设备和指标策略系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6615199B1 (en) * 1999-08-31 2003-09-02 Accenture, Llp Abstraction factory in a base services pattern environment
US20070073771A1 (en) * 2005-09-28 2007-03-29 Baikov Chavdar S Method and system for directly mapping web services interfaces and java interfaces
JP2007128331A (ja) * 2005-11-04 2007-05-24 Inter Net Inishiateibu:Kk ネットワーク接続機器の自動生成機構

Also Published As

Publication number Publication date
AU2020456098A1 (en) 2023-02-09
EP3956779A1 (en) 2022-02-23
WO2022005453A1 (en) 2022-01-06
EP3956779A4 (en) 2023-01-11
KR20230029479A (ko) 2023-03-03

Similar Documents

Publication Publication Date Title
US11436613B2 (en) Computer-guided corporate governance with document generation and execution
Zhang et al. Blockchain technology use cases in healthcare
US20210027404A1 (en) System and method of reputation management and contract monitoring using blockchain
CA2716420C (en) Third party information transfer
Riso et al. Ethical sharing of health data in online platforms–which values should be considered?
US20030149594A1 (en) System and method for secure highway for real-time preadjudication and payment of medical claims
Hanseth et al. The dynamics of architecture-governance configurations: An assemblage theory approach
MXPA05004988A (es) Un sistema y procedimiento para subrogacion electronica, manejo de flujo de trabajo entre organizaciones, procesamiento de transaccion entre organizaciones e interaccion de usuario con en una red informatica optimizada.
US20050033605A1 (en) Configuring a semantic network to process health care transactions
US20060173672A1 (en) Processing health care transactions using a semantic network
US20230237349A1 (en) Digital consolidation
US20210065304A1 (en) Contract automation with blockchain based interaction and recording
US20200020440A1 (en) Computer-assist method using distributed ledger technology for operating and managing an enterprise
Pathak Information technology auditing: an evolving agenda
US20240007506A1 (en) Enterprise account aggregation and visualization system
CN117083603A (zh) 用于跨不同系统、平台和/或业务的过程协调和互操作的系统
US11803849B1 (en) Method and apparatus for decentralized micro businesses
AU2011217881A1 (en) Clinical payment network system and methods
US10810550B1 (en) System for process coordination and interoperability across different systems, platforms, and/or businesses
AU2020101898A4 (en) MHOC- Blockchain Technology: Medicine and Healthcare Observation Care using Blockchain Technology
US20210312555A1 (en) Computer-Guided Corporate Financing with Document Generation and Execution
US11748818B1 (en) System and method for healthcare revenue cycle management
Valenta et al. Enterprise Adoption of Telehealth: An Academic Medical Center's Experience Utilizing the Telehealth Service Implementation Model
Zeigler et al. Guiding principles for data architecture to support the Pathways Community HUB Model
Wilson et al. Digital financial services for health in support of universal health coverage: qualitative programmatic case studies from Kenya and Rwanda

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination