加密消息传递系统
文献发布时间：2023-06-19 11:06:50
本专利文档的公开内容的一部分包含受版权保护的材料。版权所有者不反对任何人对专利文档或专利公开内容的传真复制，因为它出现在美国专利商标局专利文件或记录中，但是以其他方式保留所有版权权利。
本专利申请要求2018年8月10日提交的美国专利申请62/717,691的权益，该申请连同本申请中引用的所有其他参考文献一起通过引用并入本文。
技术领域
本公开涉及一种消息传递系统，并且更具体地，涉及一种加密消息传递系统，该加密消息传递系统维护在该加密消息传递系统中共享的信息的保密性。
背景技术
因特网改进了许多行业中的通信。可通过因特网传送并跨各种设备访问消息和其他信息，经常与消息被发送时几乎同时地进行。
然而，一些行业已落后。例如，医疗行业中的许多通信依靠使用传真机，这是低效的、成本高的，并产生差的图像质量。这使医疗从业者变得难以与患者、其他医生或在他们自己的办公室内进行沟通。
要克服的问题之一是要求医疗行业严格遵守患者信息的保密性。这些要求中的一些由1996年的健康保险便携性和责任法案(HIPAA)规定的，HIPAA是在美国通过的为保护患者信息提供数据私密性和安全条款的立法。这种患者信息可以包括患者的敏感标识信息，诸如社会保障卡号、地址或其他信息。另外，因为医疗专业人员能够访问疾病和其他小毛病的测试结果和诊断，所以患者信息的意外暴露可能导致患者名誉受损。不遵守严格的保密标准可能削弱患者对其医疗服务提供商的信心或者甚至导致因违反HIPAA而承担法律责任。
因此，需要一种用于医疗行业的改进的通信方法。
发明内容
一种加密消息传递系统允许医疗行业的安全通信。加密消息传递系统可以被设计为遵守医疗行业中要求的各种用例的严格保密要求，诸如HIPAA所要求的保密要求。例如，加密消息传递系统可以包括为办公室间、办公室内或患者通信专门地设计的特征，同时维护正在加密消息传递系统内传送的信息的私密性。
在一个实施方案中，加密消息传递系统是由Medroster.com公司提供的Medroster软件产品。Medroster软件产品是用于医疗界的HIPAA安全通信平台。Medroster软件产品通过模拟医生、其工作人员和患者会如何在现实生活中通信来使这些用户之间的通信变得更安全且更高效。Medroster是跨平台的并且跨台式机、iOS、Android和平板工作。
HIPAA通过由联邦法规法典在45CFR 160、162和164中指定的HIPAA行政简化法规来实现，该联邦法规法典特此通过引用并入。具体地，第164.312(e)(ii)节讨论了用于防止未经授权访问正在通过电子通信网络传送的电子保护健康信息(或EPHI)的技术安全措施。美国卫生与人类服务部还已提供了联邦公报中的附加指南以及有关HIPAA所要求的安全标准的其他材料，这些也通过参考本专利申请的提交日期并入。
在一个实施方案中，加密消息传递系统包括一种从密钥服务器取出用于来自第一客户端设备的第一会话的第一加密密钥的方法，该第一加密密钥意在供与第二客户端设备相对应的医疗空间使用。医疗空间可以为医疗办公室、企业实体、HIPAA合规单位的一部分，或者在较大的医疗机构中，可以为由医疗行业使用的部门或任何分部。第一会话可以为从患者到医疗办公室的消息或者反之亦然。
医疗办公室可以包括多个医疗空间，诸如在一地点或医生办公室内的科室或部门。医疗空间的一些示例包括前台空间、后勤办公室空间、接待空间、收费空间、医生空间、其他工作人员空间或医疗办公室中的任何其他空间。在一个实施方案中，对于诸如医院的较大机构，为了加密消息传递系统的可管理性和易用性，可以将医疗地点定义为医院中的部门。
医疗空间可以对应于登录到第二客户端设备上的用户并且可以为可访问加密消息传递系统的任何类型的设备，诸如个人计算机、平板计算机、智能电话或智能设备。医疗空间可以对应于不止一个用户账户。例如，第二客户端设备可以作为第一用户登入。然而，医疗空间还可以对应于与相同医疗空间相关联的与第一用户不同的第二用户。第二用户可以登录到第二客户端设备或不同的客户端设备上。
加密消息传递系统包括使用第一加密密钥来对第一会话进行加密以创建第一加密会话。加密消息传递系统可以使用任何合适的加密方法，诸如高级加密标准(AES)、RSA(Rivest-Shamir-Adelman)或任何其他加密方案。加密消息传递系统包括：存储第一时间戳和第一会话标识符，该第一会话标识符唯一地标识具有第一加密密钥的第一加密会话；以及将第一加密会话传送到消息服务器。第一时间戳可以对应于当第一客户端设备已完成起草第一会话时、当第一客户端设备的用户指示要发送第一会话时、当第一会话已由第二客户端设备请求了时的时间或任何其他时间段。第一会话标识符可以为在加密消息传递系统中未重用于标识加密消息传递系统中的任何其他会话的唯一会话标识符。会话标识符可以为随机化会话标识符。这意味着第一会话标识符是使用加密消息传递系统的随机数生成器来生成的。这可以防止恶意用户容易地猜测加密消息传递系统中的会话的会话标识符，这可能使黑客入侵或访问第一会话的过程变得更困难。消息服务器可以为与密钥服务器不同的服务器。消息服务器还可以为与密钥服务器相同的服务器，诸如支持消息的特征的服务器和不同的虚拟化系统上的密钥服务器或在同一服务器上执行的应用。
加密消息传递系统包括：当根据第一时间戳超过第一会话的期满时段时，使得从消息服务器中删除第一加密消息。例如，加密消息传递系统可以包括向消息服务器发送消息以删除第一加密会话，或者消息服务器可以在没有来自另一服务器的消息的情况下自动地删除第一加密会话。期满时段可以为任何类型的期满时段，诸如一段时间(例如，1天、2天、3天、1周或其他时间长度)、对第一加密会话的访问尝试次数、对第一加密会话的成功访问尝试次数、已访问过第一加密会话的客户端的数量(例如，会话的所有方、会话的至少一方)或这些中的任一个的组合。
删除第一加密消息可以在第一加密会话已由第二客户端设备请求了之前或之后发生。加密消息传递系统包括从第二客户端设备接收要从消息服务器中检索第一加密会话的请求。
如果第一加密会话已被删除，则加密消息传递系统包括响应于第二客户端设备第一加密消息已被删除。如果第一加密会话尚未被删除，则加密消息传递系统包括基于第一会话标识符，使得在第二客户端设备处确定第二客户端设备是否已存储了第一解密密钥的副本。例如，第一解密密钥可以在第二客户端设备上被存储在高速缓存或其他存储器暂存器中。存储器暂存器还可以被加密以防止未经授权访问第一解密密钥。当第二客户端设备尚未存储第一解密密钥的副本时，加密消息传递系统包括接收在密钥服务器处对第一加密密钥的请求。
在一个实施方案中，加密消息传递系统包括会话特定的解密密钥。这意味着在第一加密会话中可以有一个或多个消息，诸如在用户之间来回以协调指定时间。第一解密密钥可以对与第一加密会话相关联的所有消息进行解密，而对会话中的每个具体消息无需附加解密密钥。进一步地，第一解密密钥可能无法对加密消息传递系统中的其他会话进行解密。例如，即使第二加密会话中包括的各方与第一加密会话中的各方相同，也可能无法使用第一解密密钥来对加密消息传递系统中的第二会话进行解密。
在一个实施方案中，加密消息传递系统包括短暂会话。这意味着，尽管必须将会话下载到客户端设备上以供查看，但是一旦会话已被关闭，就从客户端设备中删除会话。当在客户端设备处终止到加密消息传递系统的连接时，当在客户端设备处终止加密消息传递系统应用时，在客户端设备的超时时段(例如，在一段时间内连接到加密消息传递系统的服务器、在一段时间内尚未发生来自客户端设备的活动)或其他时，可能发生从客户端设备中删除。这允许加密消息传递系统通过限制存储会话的副本的计算机的数量来维护加密消息传递系统中的会话的保密。在一个实施方案中，客户端设备可以将加密会话保持在客户端设备的存储器中。这通过防止会话的重复下载来灵活地存储会话并节省带宽。
在一个实施方案中，加密消息传递系统包括一种用于安全消息传递系统的方法，该方法包括：从患者用户的设备接收使要发送到医疗办公室的第一功能单元的第一消息安全的请求。功能单元可以为加密消息传递系统的一个或多个用户的分组，这些用户在加密消息传递系统中分担责任。单个用户可以为不止一个功能单元的一部分。例如，患者用户可能正试图到达系统的医生、前台或其他功能单元。加密消息传递系统可以包括：响应于患者用户的请求，选择第一加密密钥；以及基于第一消息和第一加密密钥，创建安全第一消息。加密消息传递系统可以包括使得存储安全第一消息和安全第一消息的唯一标识符。加密消息传递系统确定第一消息意在供加密消息传递系统的哪些用户使用。由于可能有多个医疗办公室同时地使用加密消息传递系统，所以加密消息传递系统可以确定与医疗办公室相关联的用户。然后，基于与医疗办公室相关联的用户，加密消息传递系统确定与第一功能单元和医疗办公室相关联的安全消息传递系统的第一用户和第二用户并且将安全第一消息传送到这些用户。加密消息传递系统可以包括：基于安全第一消息的唯一标识符，使得确定第一解密密钥在传送第一安全消息之前被存储在第一用户的设备上；以及在第一位用户的设备上对第一安全消息进行解密。响应于第一用户和第二用户被确定，或者在其他时间，加密消息传递系统的其他实施方案可以检查在第一用户请求打开消息之前，第一解密密钥是否被存储在第一用户的设备上。
在一个实施方案中，加密消息传递系统包括确定第一解密密钥未被存储在第二用户的设备上。例如，加密消息传递系统包括：基于安全第一消息的唯一标识符，使得确定第一解密密钥在传送第一安全消息之前未被存储在第二用户的设备上；基于第二用户的设备未存储第一解密密钥，将第一解密密钥传送到第二用户的设备；以及在第二用户的设备上对第一安全消息进行解密。加密消息传递系统可以包括在不同的传输期间发生传送第一解密密钥和传送安全第一消息的地方。
在一个实施方案中，第一用户和第二用户可以为加密消息传递系统中不同的角色。例如，第一用户包括工作人员角色用户而第二用户包括医生角色用户。
在一个实施方式中，加密消息传递系统包括允许从医疗办公室到患者用户的响应。加密消息传递系统包括：从第一用户的设备接收使要发送到患者用户的第二消息安全的请求；响应于第一用户的请求，选择第二加密密钥；基于第二消息和第二加密密钥，创建安全第二消息；使得存储安全第二消息和安全第二消息的唯一标识符；将安全第二条消息传送到患者用户的设备；基于安全第二消息的唯一标识符，使得确定第二解密密钥在传送第二安全消息之前被存储在患者用户的设备上；以及在患者用户的设备上对第二安全消息进行解密。加密消息传递系统可以包括第一用户正在代表第二用户对患者用户做出响应的指示。例如，第二安全消息可以包括将第二安全消息指定为由与医生一起工作的工作人员成员发送以对第二安全消息做出响应的徽章或图标。
在一个实施方式中，患者用户打开来自第一用户的第二安全消息。加密消息传递系统可以包括：从第一用户的设备接收使要发送到患者用户的第二消息安全的请求；响应第一用户的请求，选择第二加密密钥；基于第二消息和第二加密密钥，创建安全第二消息；使得存储安全第二消息和安全第二消息的唯一标识符；将安全第二消息传送到患者用户的设备；基于安全第二消息的唯一标识符并且第二解密密钥在传送第二安全消息之前未被存储在患者用户的设备上，使得将第二解密密钥传送到患者用户的设备；以及在患者用户的设备上对第二安全消息进行解密。加密消息传递系统不检查患者用户是属于医疗机构还是功能单元。
在考虑以下详细描述和附图后，本发明的其他目的、特征和优点可以变得显而易见，在附图中，相似的附图标记在所有图中表示相似的特征。
附图说明
图1示出了分布式计算机网络。
图2示出了可在加密消息传递系统中使用的计算机系统。
图3示出了计算机系统的系统框图。
图4-5示出了移动设备的示例。
图6示出了移动设备的系统框图。
图7示出了加密消息传递系统的系统图。
图8示出了加密消息传递系统中的加密消息的流程。
图9示出了用于在加密消息传递系统中的消息传递功能空间的流程。
图10示出了加密消息传递系统的聊天加密概要。
图11示出了加密消息传递系统的当在加密消息传递系统中发送加密消息时的特性。
图12示出了加密消息传递系统的当在加密消息传递系统中发送加密消息时的特性。
图13示出了加密消息传递系统的当在加密消息传递系统中发送加密消息时的特性。
图14-39D示出了加密消息传递系统中的消息传递特征的屏幕。
图40-60示出了在加密消息传递系统中在注册过程期间引导用户的屏幕。
图61-73示出了加密消息传递系统中的入门教程的屏幕。
图74示出了用户简档的屏幕。
图75示出了地点简档的屏幕。
图76示出了地点简档转诊病人的屏幕。
图77-83示出了用户下拉列表规范的屏幕。
图84-85示出了转移用户界面的屏幕。
图86-89示出了人员/地点搜索功能的屏幕。
图90-94示出了提醒功能的屏幕。
图95-98示出了web信使应用中的聊天功能的屏幕。
图99-102示出了验证功能的屏幕。
图103示出了具有在线/离线状态能力的屏幕。
图104-111示出了关于如何为加密消息传递系统添加地点的一系列屏幕。
图112示出了具有参考点的搜索结果页面的屏幕。
图113示出了邀请表单的屏幕。
图114示出了邀请表单的屏幕，而没有将它们添加到现有的医疗实践中。
具体实施方式
加密消息传递系统包括为医疗行业专业人员提供不同的用例的各种特征。加密消息传递系统可以被设计为保护正在使用加密消息传递系统存储或传送的保密或敏感信息。这种信息的一些示例包括受HIPAA保护的电子保护健康信息(或ePHI)，诸如患者姓名、地址、社会保障号、程序代码、出生日期等。然而，加密消息传递系统还可以保护HIPAA未显式地涵盖的信息。
图1是并入本发明的实施方式的分布式计算机网络100的简化框图。计算机网络100包括许多客户端系统113、116和119以及经由多个通信链路128耦合到通信网络124的服务器系统122。通信网络124提供了用于允许分布式网络100的各种组件相互通信和交换信息的机制。
通信网络124它本身可以包括许多互连的计算机系统和通信链路。通信链路128可以为硬线链路、光链路、卫星或其他无线通信链路、波传播链路或用于信息通信的任何其他机制。通信链路128可以为DSL、电缆、以太网或其他硬线链路、无源或有源光链路、3G、3.5G、4G和其他移动性、卫星或其他无线通信链路、波传播链路或用于信息通信的任何其他机制。
可以使用各种通信协议来促进图1所示的各种系统之间的通信。这些通信协议可以包括VLAN、MPLS、TCP/IP、隧道、HTTP协议、无线应用协议(WAP)、供应商特定协议、定制协议和其他协议。虽然在一个实施方式中，通信网络124是因特网，但是在其他实施方式中，通信网络124可以为任何合适的通信网络，包括局域网(LAN)、广域网(WAN)、无线网络、内联网、专用网络、公用网络、交换网络以及这些的组合等。
图1中的分布式计算机网络100仅仅图示了并入本发明的实施方式，而不限制如权利要求中叙述的本发明的范围。本领域的普通技术人员将认识其他变化、修改和替代方案。例如，不止一个服务器系统122可以连接到通信网络124。作为另一示例，许多客户端系统113、116和119可以经由接入提供商(未示出)或经由某个其他服务器系统耦合到通信网络124。
客户端系统113、116和119通常从提供信息的服务器系统请求信息。由于这个原因，服务器系统通常具有比客户端系统更多的计算和存储容量。然而，取决于计算机系统是在请求还是提供信息，特定计算机系统可以作为客户端或服务器。附加地，尽管已使用客户端-服务器环境描述了本发明的各方面，但是应该显而易见的是，还可以在独立计算机系统中体现本发明。
服务器122负责从客户端系统113、116和119接收信息请求，执行满足请求所要求的处理，并且负责将与请求相对应的结果转发回到请求客户端系统。满足请求所要求的处理可以由服务器系统122执行或者可以替代地被委派给连接到通信网络124的其他服务器。
客户端系统113、116和119使得用户能够访问和查询服务器系统122存储的信息。在具体实施方式中，客户端系统可作为诸如台式机应用或移动智能电话或平板应用的独立应用运行。在另一实施方式中，在客户端系统上执行的“Web浏览器”应用使得用户能够选择、访问、检索或查询由服务器系统122存储的信息。Web浏览器的示例包括由微软公司提供的Internet Explorer浏览器程序、由Mozilla提供的Firefox浏览器、由Google提供的Chrome浏览器、由Apple提供的Safari浏览器等。
在客户端-服务器环境中，一些资源(例如，文件、音乐、视频或数据)被存储在客户端处，然而其他资源被存储在网络中别处(诸如服务器)或从网络中别处递送，并且可经由网络(例如，因特网)访问。因此，用户的数据可被存储在网络或“云”中。例如，用户可在客户端设备上的远程地存储在云(例如，服务器)上的文档上工作。客户端设备上的数据可与云同步。
图2示出了本发明的示例性客户端或服务器系统。在一个实施方式中，用户通过诸如图2所示的计算机工作站系统来与系统对接。图2示出了计算机系统201，该计算机系统包括监视器203、屏幕205、外壳207(还可以被称为系统单元、机柜或壳体)、键盘或其他人类输入设备209、鼠标或其他指点设备211。鼠标211可以具有诸如鼠标按钮213的一个或多个按钮。
应该理解，本发明不限于具体形状因数(例如，台式计算机形状因数)的任何计算设备，而是可包括各种形状因数的所有类型的计算设备。用户可与任何计算设备对接，这些计算设备包括智能电话、个人计算机、膝上型电脑、电子平板设备、全球定位系统(GPS)接收器、便携式媒体播放器、个人数字助理(PDA)、其他网络访问设备以及能够接收或传送数据的其他处理设备。
例如，在具体实施方案中，客户端设备可以为智能电话或平板设备，诸如AppleiPhone(例如，Apple iPhone 6)、Apple iPad(例如，Apple iPad、Apple iPad Pro或AppleiPad mini)、Apple iPod(例如，Apple iPod Touch)、Samsung Galaxy产品(例如，Galaxy S系列产品或Galaxy Note系列产品)、Google Nexus和Pixel设备(例如，Google Nexus 6、Google Nexus 7或Google Nexus 9)和Microsoft设备(例如，Microsoft Surface平板)。通常，智能电话包括可经由触摸屏显示器访问的电话部分(及相关无线电设备)和计算机部分。
存在用于存储电话部分(例如，联系人和电话号码)和计算机部分(例如，包括浏览器、图片、游戏、视频和音乐的应用)的数据的非易失性存储器。智能电话通常包括用于拍摄照片和视频的相机(例如，前置相机或后置相机或两者)。例如，智能电话或平板可用于拍摄实况视频，可将该实况视频流式传输到一个或多个其他设备。
外壳207收容熟悉的计算机组件，其中的一些未示出，诸如处理器、存储器、大容量存储设备217等。大容量存储设备217可以包括大容量磁盘驱动器、软盘、磁盘、光盘、磁光盘、固定盘、硬盘、CD-ROM、可记录CD、DVD、可记录DVD(例如，DVD-R、DVD+R、DVD-RW、DVD+RW、HD-DVD或蓝光盘)、闪速和其他非易失性固态存储装置(例如，USB闪存驱动器或固态驱动器(SSD))、电池后备易失性存储器、磁带存储装置、读取器和其他类似的介质以及这些的组合。
本发明的计算机实现的或计算机可执行版本或计算机程序产品可以使用计算机可读介质来实现，被存储在计算机可读介质上，或者与计算机可读介质相关联。计算机可读介质可以包括参与向一个或多个处理器提供指令以供执行的任何介质。这样的介质可以采取许多形式，包括但不限于非易失性、易失性和传输介质。非易失性介质包括例如闪速存储器或光盘或磁盘。易失性介质包括静态或动态存储器，诸如高速缓存存储器或RAM。传输介质包括同轴电缆、铜电线、光纤线路和布置在总线中的电线。传输介质还可采取电磁波、射频波、声波或光波的形式，诸如在无线电波和红外数据通信期间生成的那些波。
例如，本发明的软件的二进制机器可执行版本可以被存储或者驻留在RAM或高速缓存存储器中，或者存储在大容量存储设备217中。本发明的软件的源代码也可以被存储或者驻留在大容量存储设备217(例如，硬盘、磁盘、磁带或CD-ROM)上。作为另一个示例，可以经由电线、无线电波或通过诸如因特网的网络来传送本发明的代码。
图3示出了用于执行本发明的软件的计算机系统201的系统框图。如在图2中一样，计算机系统201包括监视器203、键盘209和大容量存储设备217。计算机系统201还包括诸如中央处理器302、系统存储器304、输入/输出(I/O)控制器306、显示适配器308、串行或通用串行总线(USB)端口312、网络接口318和扬声器320的子系统。本发明还可以与具有附加或更少的子系统的计算机系统一起使用。例如，计算机系统能包括不止一个处理器302(即，多处理器系统)或者系统可以包括高速缓存存储器。
诸如322的箭头表示计算机系统201的系统总线架构。然而，这些箭头图示了用于链接子系统的任何互连方案。例如，扬声器320能通过端口连接到其他子系统或者具有到中央处理器302的内部直接连接。处理器可以包括多个处理器或多核心处理器，其可以许可对信息进行并行处理。图3所示的计算机系统201只是适合于与本发明一起使用的计算机系统的示例。适合于与本发明一起使用的子系统的其他配置对本领域的普通技术人员而言可以是容易显而易见的。
计算机软件产品可以用各种合适的编程语言中的任一种加以编写，这些合适的编程语言诸如C、C++、C#、Pascal、Fortran、Perl、Matlab(来自MathWorks，www.mathworks.com)、SAS、SPSS、JavaScript、AJAX、Java、Python、Erlang和Ruby onRails。计算机软件产品可以为具有数据输入和数据显示模块的独立应用。替代地，计算机软件产品可以为可以被实例化为分布式对象的类。计算机软件产品还可以为组件软件，诸如Java Beans(来自Oracle公司)或Enterprise Java Beans(来自Oracle公司的EJB)。
用于系统的操作系统可以为以下项中的一个：Microsoft
本专利中使用的任何商标或服务标记是它们相应的所有者的财产。本专利中的任何公司、产品或服务名称仅用于标识目的。这些名称、徽标和品牌的使用不暗示认可。
此外，计算机可以连接到网络并且可以使用此网络对接到其他计算机。网络可以为内联网、互联网或因特网等。网络可以为有线网络(例如，使用铜)、电话网络、分组网络、光网络(例如，使用光纤)或无线网络或这些的任何组合。例如，可以使用运用诸如以下项的协议的无线网络来在本发明的系统的计算机和组件(或步骤)之间传递数据和其他信息：Wi-Fi(IEEE标准802.11、802.11a、802.11b、802.11e、802.11g、802.11i、802.11n、802.11ac和802.11ad，仅举几个示例)、近场通信(NFC)、射频标识(RFID)、移动或蜂窝无线(例如，2G、3G、4G、3GPP LTE、WiMAX、LTE、高级LTE、Flash-OFDM、HIPERMAN、iBurst、EDGE Evolution、UMTS、UMTS-TDD、1xRDD和EV-DO)。例如，可以将来自计算机的信号至少部分地以无线方式转移到组件或其他计算机。
在一个实施方式中，利用在计算机工作站系统上执行的Web浏览器，用户通过诸如因特网的网络来访问万维网(WWW)上的系统。Web浏览器用于下载包括HTML、XML、文本、PDF和Postscript的各种格式的Web页面或其他内容，并且可以用于将信息上传到系统的其他部分。Web浏览器可以使用统一资源标识符(URL)来标识Web上的资源以及在Web上转移文件时的超文本转移协议(HTTP)。
在其他实施方案中，用户通过本机应用和非本机应用中的任何一者或两者来访问系统。本机应用被在本地安装在特定计算系统上并特定于操作系统或该计算系统的一个或多个硬件设备或这些的组合。可经由直接互联网升级补丁机制或通过应用商店(例如，Apple iTunes和App store、Google Play商店、Windows Phone商店和Blackberry AppWorld商店)更新(例如，周期性地)这些应用(其有时还被称为“apps”)。
系统可在平台无关非本地应用中运行。例如，客户端可使用与一个或多个服务器的网络连接从一个或多个服务器通过Web应用访问系统并将Web应用加载在Web浏览器中。例如，Web应用可由Web浏览器通过因特网从应用服务器下载。也可从诸如磁盘的其他源获得非本机应用。
图4-5示出了可以为移动客户端的移动设备的示例。移动设备是如上所述的计算机的具体实施方案。图4示出了智能电话设备401，并且图5示出了平板设备501。智能电话的一些示例包括Apple iPhone、Samsung Galaxy和Google Nexus系列设备。平板设备的一些示例包括Apple iPad、Apple iPad Pro、Samsung Galaxy Tab和Google Nexus系列设备。
智能电话401具有包括屏幕403、按钮409、扬声器411、相机413和接近传感器435的外壳。屏幕可以为检测并接受来自手指触摸或触针的输入的触摸屏。触摸屏的技术可以为电阻式、电容式、红外网格、光学成像或压敏、色散信号、声脉冲辨识或其他。触摸屏是屏幕及作为计算机的鼠标和键盘的用户输入设备界面。
按钮409有时被称为起始按钮并且用于退出程序并使用户返回到起始屏幕。电话还可以在侧面包括诸如音量按钮和开关按钮的其他按钮(未显示)。接近检测器可检测用户的面部靠近电话，并且可禁用电话屏幕及其触摸传感器，使得在说话时可以没有来自用户的面部挨着屏幕的假输入。
平板501类似于智能电话。平板501具有包括屏幕503、按钮509和相机513的外壳。通常平板的屏幕(例如，触摸屏)比智能电话大，通常为7、8、9、1、3、4或更多英寸(对角线测量)。
图6示出了用于执行本发明的软件的移动设备601的系统框图。此框图表示智能电话或平板设备的组件。移动设备系统包括屏幕603(例如，触摸屏)、按钮609、扬声器611、相机613、运动传感器615、光传感器617、麦克风619、指示灯621和外部端口623(例如，USB端口或苹果闪电端口)。这些组件可经由总线625相互通信。
系统包括诸如移动网络连接627(例如，移动电话或移动数据)、Wi-Fi 629、蓝牙631、GPS 633(例如，检测GPS定位)的无线组件、诸如接近传感器的其他传感器635、CPU637、RAM存储器639、存储装置641(例如，非易失性存储器)和电池643(锂离子或锂聚合物电池)。电池向电子组件供应电力并是可再充电的，这允许系统为移动的。
图7示出了实施方案中的加密消息传递系统的系统图。加密消息传递系统包括通信地耦合到密钥服务器703和消息服务器705的加密消息传递系统服务器701。密钥服务器703和消息服务器705分别提供加密/解密密钥和消息，以支持由加密消息传递系统服务器701提供的各种特征。例如，加密消息传递系统服务器可以包括使用存储在密钥服务器703中的密钥来管理存储在消息服务器705中的消息的加密和解密的加密管理器特征。
通信特征允许使用加密消息传递系统在人们之间通信。例如，用户可以为用户707、709或711。不需要人们为要使用加密消息传递系统的登记或验证用户(例如，要加入加密消息传递系统的新邀请的用户)。进一步地，通信特征可以促进加密消息传递系统中的不同类型的通信方法。例如，加密消息传递系统可以提供聊天、电子邮件、网际协议语音、照片、视频或其他类型的通信方法。
角色特征允许加密消息传递系统实施对加密消息传递系统的特征的访问控制。例如，角色可以与数据库713中定义的空间或功能单元有关。某些空间可以能够访问其他角色可能没有的某些特征。例如，后勤办公室可以能够访问会计功能但不能访问医疗记录。作为另一示例，患者应该不能够访问其他用户的信息，诸如其他患者的医疗信息或将本身表示为医疗专业人员的消息传递特征。邀请特征允许加密消息传递系统的现有用户邀请其他人加入加密消息传递系统。被邀请人员可以与加密消息传递系统的任何角色如工作人员、医生、患者或其他角色相关联。
验证特征帮助加密消息传递系统确定人员是否实际上是他们声称的人员。例如，加密消息传递系统将验证用户是否实际上是医疗从业者，使得加密消息传递系统不被那些冒充医疗从业者滥用以得到经济利益。
示例消息传递用途
加密消息传递系统的一些用例的一些示例包括：
办公室间通信。医生或医疗办公室常常需要一种与其他医生或医疗办公室共享信息的方法。例如，办公室间通信包括医生的办公室例如通过每个相应的办公室的工作人员成员与另一医生的办公室谈话。利用办公室间通信，用户在特定医生的执业范围之外与医师进行通信以方便转诊病人，讨论患者问题或者只与同事聊天。办公室间通信的一些示例可以包括医生对医生(来自不同的办公室)或工作人员对工作人员通信。加密消息传递系统可以将任何医疗业务或机构称为地点。例如，来自第一地点的多面手可以为让患者去第二地点的专家的转诊者。然而，由于在信息医生的共享中可能包括敏感信息，所以必须使信息保密。进一步地，医生需要确保用于联系另一名医生的联系信息有效的方式。例如，联系信息可以是伪造的、不正确的或过时的。如果联系信息是伪造的，则恶意方可以假装为被转诊医生并获得敏感信息。
办公室内通信。加密消息传递系统可以包括具有负责不同角色的工作人员的医疗办公室不同的部门。办公室内消息传递的示例包括与一个医生办公室、医生、工作人员的通信和患者消息并且可以通过历史或会话和部门联系起来。例如，医疗办公室可以包括客户服务代表或接待员、收费专家、多名医生、患者或其他角色。办公室内通信的一些示例可以包括医生对医生、医生对工作人员或工作人员对工作人员通信。办公室内通信还可以包括与医生签约以提供服务的第三方。例如，医生可以选择将收费的一部分外包给第三方。加密消息传递系统可以被配置为允许被验证第三方访问加密消息传递系统并使它们与适用空间相关联(例如，第三方收费服务可以与后勤办公室空间相关联)。利用办公室内通信，医生-工作人员-患者用户可以相互通信。在一个实施方案中，办公室内通信被分成不同的空间。像大多数业务一样，医疗办公室很可能包括不同的部门。为了使地点内的通信合理化，加密消息传递系统允许用户虚拟地将其业务的结构重新创建为不同的部门或空间以给予用户每次与正确的人们进行通信的能力。例如，加密消息传递系统中的空间是指特定地点内的部门或子分部。医疗办公室中的空间的一些示例包括“前台”、“后勤办公室”、“收费”或“一般”。这还通过确保仅打算查看通信的人们能够查看通信来提供一层安全。
还可以在加密消息传递系统中使用空间来定义不同的任务并在医疗办公室中由谁处理任务。例如，尽管医生负责其患者的医疗护理，但是他们可能要求其办公室中的许多其他人的协助才能运行有效的医疗执业。医生可能不需要常常使用加密消息传递系统，因为医疗办公室中的大多数任务可以被委派给他们相应的空间(例如，向前台预约、如何向后勤办公室收费和其他示例)。
可以有对办公室内消息分类的不同方法。例如，可在医疗办公室处按消息历史或按特定部门搜索消息。
办公室对患者通信。办公室内通信的特定示例是办公室对患者通信。加密消息传递系统为工作人员和患者提供合理化通信渠道—消除对效率低的电话和电子邮件的需要。
当医疗专业人员登录到加密消息传递系统中时，他们被问为业务创建空间(或部门)。在添加工作人员之后，可将每个工作人员用户指派给他们正常工作的一个或多个部门或空间。这为若干功能服务：
每个空间内的所有通信都是安全的并且不能被无访问权的用户看见(按照HIPAA)；
用户可选择与整个部门而不是单独地与每个人员进行通信，从而节省宝贵的时间；
患者用户可直接与他们需要的部门/人员进行通信，而不必经过接待员—从而使医疗工作人员避免通过电子邮件和费时的电话呼叫来分类；以及
不同类型的用户可以与一角色相关联，该角色根据用户相应的角色来授予或限制加密消息传递系统的特征。示例可能是限制具有收费角色的用户查看医疗测试结果。
加密消息传递系统可以包括聊天特征。这允许加密消息传递系统的不同用户与和期望一样多的其他用户进行通信，诸如通过一对一消息传递或一对多消息传递。在一个实施方案中，聊天特征不包括预发送特征。这意味着在已起草整个消息之前不会从用户的设备转移键入的文本。这允许加密消息传递系统确保为了HIPAA合规而适当地使不完整的消息安全。
图8在一个实施方案中示出了在加密消息传递系统中对消息进行加密的流程。本申请包括包括有一系列步骤的流程，然而这些流程仅用于说明性目的。加密消息传递系统的各种实施方式可以包括比通过所包括的流程示出的更多或更少的步骤。
在步骤802中，加密消息传递系统包括取出加密密钥。加密密钥可以为已在加密消息传递系统中先前使用的、但是与要使用第一加密密钥来加密的会话的发送方唯一地相关联的加密密钥。发送方可以使针对诸如后勤办公室、工作人员、前台或其他空间或功能单元的特定功能单元的会话相关联。特定功能单元对应于医疗办公室的一个或多个用户。医疗办公室的但未与第一功能单元相关联的用户不允许访问会话。
在步骤804中，加密消息传递系统包括使用加密密钥来对会话进行加密。可以存储与会话相关联的信息。例如，加密会话可以与唯一标识符相关联，即使当会话被加密时，该唯一标识符也允许加密消息传递系统将会话标识为与发送方的会话。还可以包括消息的时间戳。
在步骤806中，加密消息传递系统包括将加密会话存储在消息服务器上。消息服务器可以与存储由加密消息传递系统使用的密钥的密钥服务器分离。
在步骤808中，加密消息传递系统包括检查会话的期满时段。例如，使用会话的时间戳，加密消息传递系统可以确定会话是否存在于加密消息传递系统中或者已期满。例如，如果会话的超时时段已期满，则加密消息传递系统可以删除加密会话。
在步骤810中，加密消息传递系统包括检查是否存储了解密密钥。例如，如果正在已经存储有应用解密密钥的设备上读取加密会话，则加密消息传递系统可能不需要转移解密密钥。否则，解密密钥被传送到设备以便对加密会话进行解密。在步骤812中，加密消息传递系统包括对加密会话进行解密。
图9在一个实施方案中示出了加密消息传递系统中的消息传递功能空间的流程。在步骤902中，加密消息传递系统包括从患者用户的设备接收要使消息安全的请求。消息还可以指定消息去往的功能单元和医疗办公室。
在步骤904中，加密消息传递系统包括存储安全第一消息和唯一标识符。例如，可以使用所选加密密钥来对用户的消息进行加密。
在步骤906中，加密消息传递系统包括确定与消息打算去往的医疗办公室相对应的医疗办公室用户。例如，加密消息传递系统可以向一个或多个医疗机构提供服务。即使用户是不止一个医疗办公室的患者，每个医疗办公室也需要维护他们相应的信息的保密，除非打算共享该信息。用户可以与医疗办公室相关联，这些用户诸如雇员、医生、工作人员、承包商、或与医疗办公室相关联的其他人。
在步骤908中，加密消息传递系统包括确定与第一功能单元相关联的安全消息传递系统的第一用户和第二用户。例如，并非与医疗办公室相关联的所有用户都可以为医生、工作人员、会计或在加密消息传递系统中指定的其他角色。每个功能单元仅只能访问加密消息传递系统中的所有或有限信息。
在步骤910中，加密消息传递系统包括将安全第一消息传送到与第一用户和第二用户相关联的设备。
加密
在一个实施方案中，加密消息传递系统包括用于访问通信的各种方法。加密消息传递系统可以允许用户使用他们的移动设备或浏览器来访问加密消息传递系统。这向用户提供了访问加密消息传递系统的设备不可知能力，同时提供了对加密消息传递系统的各种特征(诸如办公室间和办公室内消息传递)的访问。
在一个实施方案中，加密消息传递系统将用于对通信进行加密和解密的密钥的副本存储在密钥服务器上的加密消息传递系统中。这可以允许加密消息传递系统在紧急情形下例如当存在医疗紧急情况时访问通信，并且在加密消息传递系统中做出的通信可以帮助发现发生了什么。加密消息传递系统的替代实施方案还可以包括用于加密消息传递系统中的通信的端到端加密。例如，加密消息传递系统可以被适配用于在除医疗行业以外的行业例如金融中使用。取决于每个行业的要求，加密消息传递系统可以使用端到端加密来允许仅发送消息的用户和打算接收消息的用户打开消息并对其进行解密。
在一个实施方案中，在加密消息传递系统中发送的消息包括期满时段。例如，未加密或加密消息可以与它们被发送的时间相关联。期满时段可以为任何时间长度(例如，24小时、48小时、3天或任何其他时间段)。当已达到使用发送时间计算出的期满时段时，加密消息传递系统可以从邮件服务器或客户端设备中删除消息或用于对存储在加密消息传递系统服务器上的消息进行解密的密钥的副本。任选地，当已达到期满时段时，还可以删除密钥或消息的副本。
加密消息传递系统可以包括自动注销功能。例如，在已发生注销条件之后，可以自动地注销登录到设备中的用户。注销条件的一些示例包括登录的预定时间量、当连接到加密消息传递系统时的预定空闲时间量、当设备已被关闭或进入休眠模式时、或这些中的任一种的组合。
并入HIPAA合规通信的加密消息传递系统可包括用于从那里控制或访问信息的一个或多个计算机。图1示出了作为加密消息传递系统的组件的计算机的示例。计算机可以为连接到系统或者可以被嵌入在系统的电子设备中的单独的单元。在一个实施方式中，本发明包括在计算机工作站系统或服务器上执行的软件，如图1所示。
图10包括关于加密消息传递系统的加密特征的信息。可以针对存储在加密消息传递系统中的各条信息实现加密特征，这些消息诸如消息、聊天、患者信息、联系信息或加密消息传递系统中的任何其他条信息。加密特征可以在数据静止的同时并在数据运动时为存储在加密消息传递系统中的数据提供加密。
加密消息传递系统的实施方案可以使用不同类型的加密。可以由加密消息传递系统使用的加密的一些示例包括(1)密钥保留加密、(2)端到端加密或(3)混合加密。
在加密消息传递系统使用端到端加密的一个实施方案中，这意味着仅作为加密消息的接收方或发送方包括的已认证用户可以对加密消息进行解码。例如，用户的设备可以存储由用户使用的密钥。当使用端到端加密消息传递时，Medroster服务器不保持密钥的副本。
在加密消息传递系统使用混合加密的一个实施方案中，可以将端到端加密或密钥保留加密用于加密消息传递系统的消息的全部或子集。例如，针对医疗办公室内的聊天群组的加密消息可能不要求端到端加密或密钥保留加密，因为它很可能集中于医疗办公室内的更日常事务，诸如办公室内的午餐计划或协调事件。
在加密消息传递系统使用密钥保留加密的一个实施方案中，图10示出了加密消息传递系统的聊天加密概要。概要包括服务器1001(例如，运行由Medroster.com公司提供的软件的服务器)、PubNub服务器1005以及客户端设备A 1003和B 1007。PubNub服务器1005可以为能够支持实时发布/订阅消息传递的任何服务器。消息传递特征包括可以由加密消息传递系统调用的应用编程接口，以促进加密消息传递系统中的消息传递。例如，概要示出了客户端A 1003处的用户可以如何使用加密消息传递系统来向客户端B 1007处的另一用户传送消息。概要包括以下步骤：
步骤1：客户端A 1003通过加密连接(https)向Medroster服务器1001发送明文消息。该消息意在供客户端B 1007处的用户使用。
步骤2：Medroster服务器1001从数据库取出会话A<->B的密钥或者在丢失的情况下创建它并存储它。
步骤3：Medroster服务器1001使用会话密钥来对客户端消息进行加密并将加密消息发送到PubNub服务器1005—包括安全随机会话标识符。在一个实施方案中，安全随机会话标识符由Medroster服务器1001生成。Medroster服务器1001不会保留消息的副本，包括加密版本和未加密版本。然而，安全随机会话标识符唯一地标识加密形式的消息。
步骤4：PubNub服务器1005接收加密消息并将它推送给客户端B 1007。同时，向客户端A 1003推送递送的肯定应答。
步骤5：客户端B 1007接收加密消息。如果已经缓存在本地，则客户端B 1007使用与会话标识符ID相对应的密钥来对消息进行解密。
步骤6：如果会话标识符的密钥在本地丢失，则客户端B 1007通过加密连接(https)从Medroster服务器1001请求会话密钥并对消息进行解密。
图11示出了加密消息传递系统的当在加密消息传递系统中用客户端A 1003向Medroster服务器1001发送加密消息到客户端B 1007时的特性。一些特性包括：
·加密不是端到端的。Medroster服务器1001管理并存储密钥
·消息发送受到底层传输层安全(TLS)加密连接保护
·由服务器发送到客户端的密钥也受到底层TLS连接保护
·消息的解密仅在客户端上发生
·每个密钥与可以为一对一或群组聊天的会话相关联
·经由对会话的访问权限来限制对密钥的访问
·密钥被以加密形式存储(与静止数据加密相比)
在一个实施方案中，在加密消息传递系统中发送的消息包括期满时段。例如，未加密或加密消息可以与它们被发送的时间相关联。期满时段可以为任何时间长度(例如，24小时、48小时、3天或任何其他时间段)。当已达到使用发送时间计算出的期满时段时，加密消息传递系统可以删除消息或用于对存储在Medroster服务器1001上的消息进行解密的密钥的副本。任选地，当已达到期满时段时，还可以删除密钥或消息的副本。
图12示出了加密消息传递系统的当在加密消息传递系统中用Medroster服务器1001向PubNub服务器1005发送加密消息时的特性。一些特性包括：
·PubNub Server 1005限于加密内容
·他们看见的明文信息是会话标识符
·会话标识符被生成为转换为Base64的安全随机数。
·密钥被创建为安全随机字节，不可猜测
·这没留下猜测会话的参与者或密钥的机会
·由于用于消息加密的已认证加密方案的性质，PubNub可能无法在客户端未检测到(并拒绝)这些更改的情况下修改加密内容
·在Medroster服务器1001可以能够访问明文消息的同时，它们不是持久的。例如，Medroster服务器1001中的明文消息可能经受一种或多种保护措施，诸如自动删除、当已经过一定持续时间时删除或其他方法。
·PubNub存留消息，但是采用加密形式
图13示出了加密消息传递系统的当在加密消息传递系统中用客户端B 1007发送加密消息时的特性。一些特性包括：
·客户端在本地缓存加密密钥，但仅缓存在存储器中
·永不在客户端上以任何形式存留密钥
·永不在客户端上以任何形式存留任何消息
·认证加密：具有安全随机初始化向量(IV)和HMAC-SHA256的AES-256-ENC
·每个会话密钥实际上由两个单独的密钥或标签构成：一个用于加密而另一个用于消息认证代码(MAC)
·IV和MAC标签被包括在加密消息中
下表1示出了当数据静止时如何在加密消息传递系统中处理数据。例如，在存储九个用户的数据的图中示出表。对于每个用户，存储用户标识符、姓名、电话、电子邮件和类型。加密消息传递系统在每列基础上存储在应用级别上加密的敏感信息。使用认证加密(具有HMAC-SHA256的AES-256-ENC)以按安全随机IV存储信息。单独的加密和认证密钥是从Rails应用秘密导出的。
表1
电子邮件通常是用于查找记录的字段，诸如以上所示的表1。例如，当对用户信息进行搜索时，通常使用用户的电子邮件来在加密消息传递系统中标识用户。认证加密在这里可能不起作用，因为它是非确定性的，这引起查找失败。加密消息传递系统可以在合成初始化向量(SIV)模式下使用AES以确保安全与确定性之间的最佳权衡。利用AES-SIV确切匹配搜索是可能的，范围、次序等查询可能不是可能的。
表1示出了当数据静止时如何在加密消息传递系统中处理姓名数据。可以在针对每个条目使用安全随机IV的ENC模式下使用AES来查询中未使用的列进行加密以保证最佳可能的安全。例如，可以使用AES来对姓名数据进行加密。可搜索列和不可搜索列都用HMACSHA256标签进行认证。IV和MAC标签连同加密值一起被存储。
在一个实施方案中，当数据静止时在加密消息传递系统中处理聊天密钥、邀请和用户数据。对于聊天密钥数据，认证可能是不可搜索的(单个会话的认证密钥)并且加密—不可搜索(单个会话的加密密钥)。对于邀请数据，电子邮件—可搜索，移动电话数据—可搜索，受邀者类型—可搜索(例如，医生、患者、工作人员)，名字—不可搜索，并且姓氏—不可搜索。对于用户数据，电子邮件—可搜索，电话号码—可搜索，未确认电子邮件-可搜索，名字—不可搜索，姓氏—不可搜索，职称—不可搜索，并且专业—不可搜索。
委派用途
在一个实施方案中，尽管加密消息传递系统被设计用于在医疗办公室或地点中使用，但是医生可以为加密消息传递系统的不频繁用户。例如，与医生相关联的工作人员可能大部分时间使用加密消息传递系统。患者和医生也可以访问加密消息传递系统，但是使用加密消息传递系统花费的时间比工作人员少。例如，单个医生取决于他们的执业可能具有数千名患者。并非所有这些患者都可能在任何给定时间点要求医疗护理，使得大多数医生的患者可能不需要使用加密消息传递系统。
进一步地，并非来自或到患者的每一消息可能要求医生的直接参与。作为示例，医生可能需要与患者协调以安排预约。然而，医生很少会本身访问加密消息传递系统来安排预约。工作人员可以代表医生使用加密消息传递系统来传送邮件以与患者协调。这减少医生的工作量，使得他们可集中于向他们的患者提供医疗护理。
加密消息传递系统允许工作人员代表医生行动，同时对每个特定用户负责。例如，即使当代表医生发送消息时，消息也可以将医疗办公室、医疗地点、特定工作人员成员或这些的任何组合指示为消息的来源。在一个实施方案中，加密消息传递系统的所有用户都具有加密消息传递系统的单独且验证的账户。这意味着，尽管用户可能正在代表医生用户、医疗地点、医疗空间或用户的其他分组发送消息，但是实际用户的身份与消息包括在一起。例如，从代表前台的工作人员用户A给患者用户的消息可以指示用户A和前台空间都负责消息。当患者用户查看消息时，加密消息传递系统指示该消息是从代表医生用户的用户A从前台空间发送的。如果例如用户A休假或否则无法响应，则可以将患者用户的响应传送到前台空间的用户A和其他用户。前台空间的用户B然后可以继续处理会话，即使他们不是发送了第一消息的初始用户A。用户B的响应然后可以指示他们是代表前台的消息的发送方。用户A还可能接收到用户B已对患者用户的消息做出响应的指示。在这种情形下，用户A和B正在作为医生用户的代理；即使当其他用户正在代表他们行动时，也可能不需要向医生用户通知这些消息。
在一个实施方案中，加密消息传递系统可以包括用于指示各条重要信息的徽章。例如，徽章可以用于标识用户正在代表响应的特定医生。例如，共享医疗办公室可能包括两个或更多个医生。共享医疗办公室可以在两个或更多个医生之间共享一个或多个工作人员用户。当工作人员用户与加密消息传递系统中的消息包括在一起时，消息可以包括工作人员用户的徽章，从而指示他们正在代表共享医疗办公室的哪一个医生响应。
屏幕
图14-39示出了当在移动设备上执行的应用上访问时加密消息传递系统的屏幕。屏幕是移动设备例如Apple公司的
在一个实施方案中，加密消息传递系统(1)允许人员或办公室之间的HIPAA合规一对一聊天(2)促进办公室内通信，诸如允许工作人员代表医生行动，而无需医生的明确监督(例如，加密消息传递系统可能主要由工作人员和患者使用)。可以将加密消息传递系统划分成不同的部分。加密消息传递系统中的医疗地点可以为医疗办公室、企业实体、HIPAA合规单位，或者在较大的医疗机构中，可以为由医疗行业使用的部门或任何分部。
医疗办公室可以包括多个医疗空间，诸如在一地点或医生办公室内的科室或部门。医疗空间的一些示例包括前台空间、后勤办公室空间、接待空间、收费空间、医生空间、其他工作人员空间或医疗办公室中的任何其他空间。在一个实施方案中，对于诸如医院的较大机构，为了加密消息传递系统的可管理性和易用性，可以将医疗地点定义为医院中的部门。
例如，可以按医生5％工作人员85％患者10％的时间访问加密消息传递系统。图14示出了地点聊天中的屏幕。“地点聊天”界面(或“一般”空间聊天)是用户在他们登录到加密消息传递系统时可以看见的第一屏幕。“地点聊天”对属于该特定地点的所有用户开放并且不能被删除。“地点聊天”是供地点中的所有工作人员非患者用户在患者无法看见的情况下相互通信的消息传递界面。没有患者可访问“地点聊天”。图14包括：
1401.“左滑出”：此菜单按钮在被按时可以通过将屏幕向右滑动起作用，从而使左侧对接菜单暴露。按这个可以将用户带到“左侧菜单规范”
1402.“会话标题按钮”：此特征可以在每个聊天屏幕界面上显示会话标题。取决于用户已选择的会话样式，它可以改变。当与用户一对一讲话时，会话标题应该显示该用户的姓名。当在一地点/空间内部时，该地点/空间的标题应该出现。当被按时，此按钮可以显示参与此地点/空间/群组消息的用户
1403.“菜单滑出”：当被按时，此“联系人”按钮可以通过将屏幕向左滑动起作用，从而使左侧对接联系人列表暴露
1404.用户图像
1405.用户姓名
1406.“徽章”(用户类型医生/工作人员/患者)
1407.时间戳
1408.日期戳
1409.文本输入区域：轻敲文本输入区域以键入使键盘弹出
1410.发送按钮：轻敲发送按钮使得为用户在聊天界面上显示消息并隐藏键盘。
可从“地点聊天”界面以及任何其他聊天界面访问“左侧菜单”。屏幕向右滑动并且菜单看得见。此功能是为了提供用于地点、空间和直达消息以及任何其他菜单项(例如，转诊病人、提醒、邀请、注销、编辑地方)的导航区域。空间(按钮)：定向到空间聊天界面(打开群组聊天，但是仅限于有权访问特定空间的用户。)
图15A-15B示出了用于紧急/重要消息的两个屏幕。例如，这包括直达消息特征：当用户通过从其联系人列表中选择该用户来联系另一用户时，那两个用户之间的聊天记录可以出现。如果菜单可见，则该用户姓名可以出现在直达消息下。此菜单的功能是为了使所有用户的会话保持被高效地组织。从直达消息中选择用户姓名可以使用户共享的聊天记录出现，与联系人列表相同。当不同时则可以删除消息历史直达消息。如果用户是患者，则可以将它们包含在患者标签下并在同事情况下反之亦然。图15包括：
1501.示出标记为紧急的消息
1502.示出标记为紧急的消息
1503.在线/离线指示器。当用户在线时显示绿色/当离线时显示灰色
1504.示出允许消息发送方将消息指定为看见、紧急或重要的菜单。
图16示出了用于更改地点的屏幕。例如，用户可能属于不止一个空间或地点。图16包括：
1601.切换按钮
1602.地点面板：按不同地点可以打开该地点以供用户通信。可以改变与该具体地点相关的所有会话/联系人/设定。
图17A-17B示出了用于切换地点的两个屏幕。这些图包括：
1701.选择改变地点特征。
1702.示出用户可以切换到的地点。这些是用户在加密消息传递系统中所属的地点。
图18示出了“右键菜单”功能。“右键菜单”功能可以为用于加密消息传递系统的任何混杂导航的总受器，例如联系人、设定和转诊病人等。因为和办公室内有关的不同功能性与办公室间消息传递(内部/外部)相反，所以菜单选项各不相同。按任何按钮可以将用户带到相应的屏幕。
图18示出了右键菜单(例如，办公室间)的屏幕。图18包括：
1801.示出通知
1802.示出用户的联系人
1803.示出转诊病人特征
1804.示出邀请特征。
这可以进一步包括联系人按钮过滤用户；搜索可以过滤用户(参考搜索规范)；在线/离线指示器；按用户可以滑过以示出具有更多详细联系信息(用户简档规范)的简档视图。
图19示出了用户简档(患者)的屏幕。用户简档可以示出和与特定患者类型用户进行通信有关的相关信息。患者和医生/工作人员简档是类似的，但是患者具有更多的选项。图19包括：
1901.按“与…聊天”面板可以在用户A与“Bill Lordes”之间打开直达消息。
1902.可以连接到电话中的外部电子邮件应用
1903.可以在用户电话中打开电话拨号器界面
用户简档还包括：
转诊病人—可以打开包含相关用户信息的自动填充的转诊病人表单(参见转诊病人规范)
提醒—可以打开自动填充的提醒
图20A-20B示出了用户简档(医生)的屏幕和医生目录屏幕。例如，联系人列表可以自动地在您的团队(作为相同地点的医生和工作人员)、患者(属于用户的地点的患者用户)和外部用户(属于不同地点的非患者用户)之间分离。所有列表的外观/功能可能相同。按用户可以切换到用户的简档屏幕。从那里，他们可选择以不同的方式联系用户。对于医生类型用户，用户可以具有更多的选项以便包括将患者转诊给另一用户并为该用户创建提醒。“转诊”按钮可以打开填充有数据的“创建新转诊病人”屏幕。图20包括：
2001.选择团队
2002.向团队示出团队。状态指示器示出特定用户是否在线
2003.按“与...聊天”面板可以在用户A与“Larry Wright”之间打开直达消息。
2004.可以连接到电话中的外部电子邮件应用
2005.可以在用户电话中打开电话拨号器界面。
图21-2IB示出了接收到的转诊病人的屏幕。转诊病人过程需要用户A(医生)向用户C(接收医生)发送用户B(患者)的信息/联系信息以及有关所述转诊病人的细节。当用户A向用户C发送所述“转诊病人”时，用户B现在为用户B的联系人列表的一部分，并且反之亦然。他们现在具有以与医生用户将必须与作为医生用户的地点的一部分的任何其他患者用户进行通信相同的方式进一步通信的能力。用户C现在属于用户A和用户B两者的地点。医生/工作人员类型用户可以看见所有新的/未打开的转诊病人的列表视图，其可以类似于目录列表工作。“存档”转诊病人按钮可以切换到存档转诊病人，其看起来为确切相同和新的转诊病人。图21-2IB包括：
2101.接收到的转诊病人信息面板包括：患者姓名和在线/离线状态、发送了转诊病人的医生姓名/位置以及时间戳。按面板可以打开转诊病人细节
2102.来自所述转诊病人的任何备注都在这里
2103.转诊病人文档可以自动地生成并显示患者用户(被转诊用户)联系信息。点击“与(用户)聊天”链接可以自动地打开与该用户的会话。可以显示聊天界面
2104.这可以打开用户的他们在其电话中使用的电子邮件系统
2105.这可以使用用户的电话拨号系统界面来打开
2106.“存档转诊病人”：这可以从“新的”选项卡中移除此具体转诊病人并将它移动到“存档”选项卡。它可以具有相同的视图和功能
2107.接收到的每个转诊病人可以给予与发送医生用户进行通信以用于可访问性目的的选项。转诊病人表单还可以显示链接，该链接当被选择时，接收用户可打开与发送用户的聊天
2108.用于创建新的转诊病人的按钮。
图22A-22B示出了用于创建转诊病人的两个屏幕。加密消息传递系统允许发送转诊病人。由于这可以由医生频繁地使用，所以它需要为简单的、快速的且无缝的。图22-22B包括：
2201.(联系人列表)当被选择时，从医生联系人中选取
2202.(自动填充)发送自动地添加的用户信息
2203.(自动填充)发送用户地点
2204.(联系人列表)从患者联系人中选取
2205.备注
2206.以“TO”形式向用户发送
图23A-24示出了通知的屏幕。当用户具有他们尚未查看的消息时，通知可以是可见的。当消息尚未被阅读时，用户可以在左侧菜单按钮上查看具有未读消息数的绿色气泡。当按钮被点击时，通知消失。当用户具有未读转诊病人时，他们可以在右侧联系人列表菜单图标上查看具有未读消息数的红色气泡。当它被打开时，通知消失。图24包括：
2401.在“所有、紧急和重要”之间切换可以在该屏幕中示出具有该标签的那些消息
2402.这些是新的未读消息
2403.按消息摘要可以在聊天中打开消息。
图25A-26B示出了邀请的屏幕。邀请用户可以选取如何邀请新用户到加密消息传递系统或现有用户以加入地点，如2501所示。如2601所示，邀请用户可以访问允许加密消息传递系统在邀请用户的设备中查看要邀请的联系人的同步联系人特征。邀请用户的邀请可以指定在哪里邀请用户(例如，医疗空间)和用户类型(例如，功能单元)。
图27A-27B示出了用于搜索用户的屏幕。当用户已经与加密消息传递系统中的当前用户连接时，加密消息传递系统提供用户已连接的通知，如2701所示。
图28A-28B示出了办公室间消息传递的屏幕，如2801所示。
图29示出了用于针对加密消息传递系统进行设定的屏幕，如2901所示。
图30示出了用于针对加密消息传递系统编辑简档的屏幕，如3001所示。
图31A-31C示出了用于在加密消息传递系统中设定通知的屏幕，如3101所示。
图32A-32B示出了加密消息传递系统中的账户设定的屏幕，如3201所示。
图33示出了加密消息传递系统中管理员的屏幕，如3301所示。地点的管理员可以为医生类型用户或工作人员类型用户。
图34A-35C示出了用于在加密消息传递系统中作为管理员编辑地点的屏幕，如3401和3501所示。
图36A-36D示出了用于管理员在加密消息传递系统中编辑用户对特征的访问的屏幕，如3601所示。
图37A-37C示出了用于患者类型用户的注册的屏幕。图37A-37C包括：
3701.用户键入电话号码
3702.用户键入由电子邮件提供的邀请代码
3703.患者姓名、电话号码和邀请日期
3704.地点/受邀者信息：地点名称、医生姓名、地点地址、地点电话号码
3705.用户键入/验证电子邮件
3706.用户键入/验证密码
3707.在这里包含徽标
这向作为能够访问加密消息传递系统的患者的新用户授予访问权。用户患者被添加到地点联系人列表。
图38A-38D示出了用于地点的医生或其他管理员邀请用户的屏幕。图38A-38D包括：
3801.用户点击邀请按钮以从左侧查看第二屏幕。
3802.用户点击“邀请用户加入地点”以访问电话联系人列表以从左侧查看第三屏幕
3803.示出在用户的电话簿中具有复选框的所有联系人。选中框可以将联系人添加到向其发送邀请的用户的列表。联系人是否为电话号码/电子邮件地址可能取决于邀请的发送方式
3804.点击以完成邀请
3805.点击以从左侧返回到第二屏幕。
图39A-39D示出了用于医生或其他管理员邀请用户尝试加密消息传递系统的屏幕。图39A-39D包括：
3901.用户点击邀请按钮以从左侧查看第二屏幕
3902.用户点击“邀请用户加入地点”以从左侧访问第三屏幕中示出的电话联系人列表
3903.示出在用户的电话簿中具有复选框的所有联系人。选中框可以将联系人添加到向其发送邀请的用户的列表。联系人是否为电话号码/电子邮件地址可能取决于邀请的发送方式。
3904.点击以完成邀请。
3905.点击以从左侧返回到第二屏幕。
可以通过文本消息、电子邮件或其他合适的方法向受邀者做出要使用加密消息传递系统的邀请。例如，文本消息可以包括消息：“(用户名/姓)已邀请您尝试Medroster.com！与您的同事和患者进行通信的最佳方式！点击链接下载(链接)”。
被验证用户
在用户成为认证用户并被允许访问加密消息传递系统的特征之前，加密消息传递系统可能要求多次身份验证。这意味着加密消息传递系统的用户在它们被认证为加密消息传递系统中的有效用户之前必须完成两个或更多个身份验证步骤。可能要求不同类型的用户提供不同的验证步骤。例如，加密消息传递系统要求在新用户被允许向加密消息传递系统注册之前登记为新地点、患者或医生。
可以用于将新用户验证为医生或地点的信息的一些示例可以包括传真号码、电话号码(例如，企业电话号码、个人电话号码、移动电话号码)、国家提供商标识符(NPI)号码、物理地址或这些的任何组合。在一个实施方案中，转诊新用户的转诊用户还可以作为验证步骤。可以用于将新用户验证为患者的信息的一些示例可以包括地址、移动电话号码、电子邮件地址、医生提供的代码或这些的任何组合。在一个实施方案中，加密消息传递系统不要求登记为患者的新用户提供社会保障号码或驾驶执照号码作为验证步骤。加密消息传递系统可以能够访问此信息，但是出于保密目的不需要它(例如，患者可能不向医生提供这种信息，这种信息在被访问的情况下容易被其他人滥用)。加密消息传递系统可以使用其他信息来标识患者，诸如他们向医疗办公室登记的电话号码。
加密消息传递系统可以与第三方数据库对接，以收集可以用于验证地点或医生的信息。当新用户试图登记新地点或新用户时，可以使用来自第三方数据库的信息来确认新地点或新用户是他们所说的人。例如，可能要求新用户确认来自第三方数据库的信息。例如，第三方数据库可以为登记医生的州登记处。
图40-61示出了加密消息传递系统的屏幕。屏幕包括从在计算设备(例如，个人计算机、平板、智能电话)上执行的浏览器或被设计为在智能电话或平板上执行的应用捕获的屏幕。
图40-61示出了在注册过程期间引导用户的屏幕。注册过程用于回答以下问题：
·用户是否被邀请？
·用户是医生还是工作人员成员？
·用户是否在我们的数据库中？
·地点是否在我们的数据库中？
图40示出了注册过程的打开屏幕。图40包括：
4001.如果用户尚未被邀请—继续到图41
4002.如果用户已经由传真/电子邮件/文本接收到邀请代码—继续到图42
图41示出了收集用户信息的屏幕。图41包括：
4101.为了确定用户是否有资格创建/拥有地点，他们必须是医生。加密消息传递系统可以使用用户的名/姓来搜索数据库以得到用户预加载的信息
4102.如果在数据库中存在具有该姓名的用户，则可以将他们定向到图43。如果未找到，则可以将他们定向到图45。
图42示出了输入邀请代码的屏幕。具有邀请代码的用户可能已通过电子邮件、传真或文本从另一用户接收到邀请代码。这也是用于用户相互自我验证的方式。如果医生邀请某人，则那意味着他们对该人员对加密消息传递系统的访问负责，从而给予一层安全并使它变得HIPAA合规。图42包括
4201.用户在这里键入邀请代码
4202.如果邀请代码正确/有效，则它取决于用户的信息是否在加密消息传递系统的数据库中而不取决于他们可以被定向到的位置。如果它们在数据库中，则可以将它们定向到图44以验证其信息正确。如果未找到它们，则可以将他们带到图45以完成其完整简档。
图43示出了用于选取在医疗提供商的列表中找到的特定身份的屏幕。例如，如果用户的名和姓与数据库中的用户匹配，则除非姓名很不常见，否则将假定可能存在具有相同名和姓的多个用户。在这种情况下，用户可以连同他们相应的营业地址一起从数据库中的名/姓的列表选取。用户可以使用其地址来缩小列表并找到自己。图43包括：
4301.如果用户需要缩小列表，则他们可使用此下拉列表来选择其具体状态
4302.如果用户搜遍列表并且不能在我们的数据库中找到自己，则他们可以选取“创建账户”并被定向到图45。
4303.当/如果用户为自己找到正确的数据库信息时，他们可以选择自己并被定向到图46以确认其身份。如果不能找到数据库信息，则可以将用户定向到图45。
图44示出了用于验证数据库信息的屏幕。如果用户被邀请并且其信息恰好在我们的数据库中，则可以向他们示出加密消息传递系统可能已经为他们提供的数据。图44包括：
4402.如果用户未将所显示的信息辨识为他们自己的，则可以给予他们手动地创建他们自己的账户的选项，诸如图45所示。
4404.如果用户的信息正确，则存在两种可能的情况：
ο第一情况是用户属于已经由另一用户建立的地点。在那种情况下，被邀请用户可以跳过“地点搜索”过程并被定向到图47的屏幕以完成其账户信息。这可能被地点的工作人员最频繁地使用，因为他们可能被医生邀请
ο第二情况是此用户可能已被不属于与第一用户相同的地点的用户邀请了。在这种情况下，用户可以搜索他相应的地点，被定向到5以完成账户信息，然后定向到地点搜索。
图45示出了用于完成用户简档的屏幕。如果用户的信息不正确/不能被找到，则可以将他们定向到此屏幕。图45包括：
4501.医疗职称的完整列表。例如，加密的消息传递系统可以与第三方数据库接口以确定与医师相关联的任何职称，例如可在http://www.pamf.org/physicians/titles.html处获得的职称。如果用户已经在前一个屏幕中填入了信息(例如，名)，则这些字段应该包含用户先前提供的东西
4502.医疗职称的完整列表。例如，加密消息传递系统可以与第三方数据库对接以确定与医师相关联的任何职称，诸如可在http://www.mclarenhealthplan.org/HealthAdvantage/AVIoficalSpecialtiesAdv.aspx处获得的职称
4503.这可以让用户完成如图46所示的其账户信息屏幕。针对医生和工作人员成员两者示出了这些字段。
图46示出了用于确认身份的屏幕。为了验证用户的身份，加密消息传递系统可以收集其NPI#和其性别4601。如果两个数据点与我们的数据库匹配，则当用户按“继续”4602时，可以将用户定向到图47的屏幕。
图47示出了用于完成账户的屏幕。图47包括：
4701.所有字段都是必需的字段
4702.如果收集了所有信息，电子邮件和密码匹配，则可以将用户定向到搜索其地点。如果他们已被邀请，则可以将用户带到其仪表板。如果用户是新的并且需要验证其地点或验证其账户，则可以将它们置于管理保持状态以使其账户被验证。
图48示出了用于电子邮件验证的屏幕。图48包括：
4801.在用户键入其账户信息之后，他们可以查看此屏幕。同时，可以向用户提供的电子邮件地址发送电子邮件(图50所示的示例电子邮件)。电子邮件可以包含用于验证账户的链接。
图49示出了当在验证之前尝试登录时的屏幕，如4901所示。如果用户在他们已经由电子邮件验证了其账户之前试图登录，则他们可以看见此屏幕。如果用户尚未接收到电子邮件，则他们可以选择点击链接以重新发送电子邮件。
图50示出了如5001所示验证账户的电子邮件。这是用户可以接收来验证其账户的电子邮件。如果他们选择如图49所示重新发送其验证电子邮件则可以使用同一电子邮件。如果点击链接，则可以将他们定向到图49所示的屏幕，其给予其电子邮件被验证的确认。
图51示出了如5101所示电子邮件验证完成的屏幕。在用户点击验证电子邮件中的链接之后，他们可以看见此屏幕。按“继续”按钮可以将用户带到其注册过程中的下一个屏幕。
图52示出了用于执行地点搜索的屏幕。用户可以在搜索栏中搜索他们的地点(5201)，并且如果可能的地点的列表太长，则它们可以按状态(5202)或按邮政编码(5203)缩小。可能存在用户不能通过我们的数据库搜索找到他们相应的地点、但是他们的地点已经被建立的情况。在这种情况下，加密消息传递系统可能必须找出某种其他方式来验证他们所属的地点(讨论)。如果他们的地点不在我们的数据库中，则他们可以选择创建地点，但是可能需要进一步验证。
图53示出了用于确认地点的屏幕。当/如果用户找到他们的正确地点时，可以将他们定向到此屏幕以验证这是正确信息。图53包括：
5302.如果信息不正确，则用户可以选择否，并且被指示要创建他们的地点。如先前陈述的，在用户不能找到其正确地点但是它确实存在的情况下，加密消息传递系统可能需要找出避免创建重复地点的情况的方式。
5303.如果地点信息正确并且这是要针对此地点注册的第一用户，则可以指示用户验证自己。如果不是要针对此地点注册的第一用户，则可以将他们重定向到诸如图59的屏幕，使得地点管理员可以验证他们。
图54示出了用于电话验证的屏幕。如果加密消息传递系统尚不能够验证用户，则加密消息传递系统将使用加密消息传递系统在数据库中具有的主要电话号码，一旦用户选择“继续”，我们的系统就可以呼叫用户并提供验证码。图54包括：
5401.用户的来自数据库的主要电话号码
5403.按“继续”可以提示系统呼叫电话号码并移动到下一个屏幕
5404.按“手动验证”可以让使用户查看图59所示的屏幕并将用户信息发送到“管理员验证”屏幕。
图55示出了用于电话验证的附加屏幕。例如，在用户提示系统呼叫数据库提供的电话号码之后，用户可以接收到对该号码的呼叫。系统可以向用户提供要键入到文本字段中的代码。图55包括：
5501.验证码的文本字段。在正确的验证码情况下按继续可以将用户带到图57所示的屏幕。不正确的验证码可以将用户带到图56所示的屏幕。
5502.按“手动验证”可以将用户带到管理员验证屏幕。
图56示出了当已发生电话验证错误时的屏幕。如果用户键入不正确的代码，则他们可以查看此屏幕。图56包括：
5601.用户可以选择接收另一呼叫或手动地验证其信息。此循环可以继续直到用户键入正确的验证码为止。按继续可以将用户发送到图54所示的屏幕以重新发送呼叫
5602.手动验证。
图57示出了验证已完成的屏幕，如5701所示。如果用户从正确的电话号码呼叫并且按继续，则他们可以来到此屏幕。按继续可以将他们带到仪表板。如果工作人员成员登记并找到其地点，但是其地点在加密消息传递系统中不是活动的，则他们被示出要求他们要求医生注册并激活地点的消息。这可能类似于图59所示的屏幕(图4g1—与具有不同消息的4g相同)。
图58示出了用于创建地点的屏幕。图58包括：
5801.在某些情况(约时间的百分之十)下，地点可能不在数据库中，或者由于一种原因或另一种原因，信息可能不准确。如果是这种情况，则可以将用户定向到此屏幕以创建其地点简档。此用户必须是医生，使他的信息通过我们的数据库验证，并且负责此地点(HIPAA)以建立此地点。如果不能通过我们的系统验证医生用户，则可能不允许用户创建地点(HIPAA)。工作人员不能创建地点(HIPAA)
5802.当完成时，并且仅当所有信息都完整而且通过我们的数据库验证了用户时，才可以指示用户等待管理员通过加密消息传递系统来验证其账户。他们可能处于管理员保持状态，诸如图59所示的屏幕。
图59示出了用于管理员验证的屏幕，如5901所示。当用户试图加入已经建立的地点时，可能需要由该地点的账户管理员验证他们。当用户到达此阶段时，由于担心违反HIPAA，他们不能与其他用户进行通信，不能查看地点的用户或空间，只能查看在加密消息传递系统中用于地点的名称。用户在点击“返回到首页”时可以被允许查看加密消息传递系统的短教程并查看仪表板。
图60示出了用于邀请其他人加入地点的屏幕。当用户被邀请加入地点时，他们可能已经通过点击电子邮件中的链接确认了其地点。当他们完成账户信息时，他们可以查看此页面，此页面示出了他们已完成注册，他们加入的地点，并且可以能够访问仪表板。图60包括：
6001.用户被邀请到的地点
6002.确认按钮转向仪表板，从而给予用户对地点的访问权。
图61示出了实现加密消息传递系统的特征的网站的流程。该流程为每个用例提供一流程。每个图标签对应于流程图和图40-60中标识的具体图。在该流程中使用的一些术语的定义包括：
不存在地点：不在我们的数据库中的地点。用户必须创建。
新地点：在加密消息传递系统中尚不活动但在数据库中的地点
活动地点/现有地点：用户正在主动地通信的地点
非受邀请用户：在没有邀请代码的情况下注册medroster.com的用户
不活动状态：用户可访问仪表板并搜查教程但是不能够访问与其他地点用户的通信。
在下面提供的表2在右侧行上标识加密消息传递系统的用例以及特定用例将使用的流程的图表标识符的列表。图标识符作为图40-60的标题被包括。
表2
图62-73示出了入门教程的屏幕。例如，在针对加密消息传递系统注册之后，可以将医生/工作人员用户定向到他们的仪表板。当他们被登记时，加密消息传递系统还可以给予用户站点的漫游以便使他们熟悉环境。另外，在登陆教程结束时，可以给予用户邀请其同事尝试加密消息传递系统的机会。对于每一屏幕，如果用户点击“继续”，则屏幕可以移动到序列中的下一个屏幕。如果他们点击“关闭教程”复选框，则可以将他们定向到其仪表板。
图74示出了用户简档的屏幕。这允许用户/放置简档以给其他用户提供对信息的容易访问、连接的方式，并且给予加密消息传递系统更多社交感。简档被分成两个部分：用户信息和地点信息。图74包括：
7401.按“邀请到地点”可以向用户发送加入用户的地点的邀请(参见图46)
7402.按“社交连接”按钮可以向用户发送“同事请求”，并且在被接受的情况下，可以将用户添加到您的社交地点中的用户(参见社交连接规范)
7403.这是用户的主要信息可以位于的地方，包括教育和专业知识。
7404.当用户编辑其简档并创建“关于我”部分时，这是可以查看该信息的地方。
7405.此部分可以列出用户的他作为其成员的地点。点击“请求加入”可以向该地点的管理员发送要成为该地点的成员的请求。
图75示出了地点简档的屏幕。地点简档类似于用户资简档，因为它给予关于地点以及用户可与该地点连接的不同方式的更多详细信息。图75包括：
7501.选择“发送转诊病人”可以打开可以给予用户通过自动填充列表将转诊病人直接发送到地点的能力的模态(参见发送地点转诊病人对话)
7502.如果仍然尚未通过加密消息传递系统激活地点，则“邀请加入Medroster”可以是可见的。如果它们是活动的，则按钮可以读为“请求加入地点”。点击“请求加入地点”可以向该地点发送可以允许用户加入地点的连接请求。
7503.这可以示出关于地点的信息。
7504.此“花名册”可以示出哪些用户连接到此地点/为地点的成员。它还可以给予用户要查看那些用户的简档并那样与他们连接的选项。
图76示出了地点简档转诊病人的屏幕。这种模态可以向用户提供将患者转诊病人发送到另一地点的快速方式。图76包括：
7601.医生/工作人员可以将他们希望转诊的医生的姓名键入到自动填充列表中。
7602.在点击返回之后，患者的姓名/信息可能会填充此屏幕。可以将多个患者添加到此列表并一次转诊。
7603.这示出了患者将被转诊到哪里。
7604.在点击“发送转诊病人”之后，可以将被转诊患者的信息发送到被选择的地点。还可以将患者的信息添加到用户的当前地点的“发送的转诊病人”。
图77-83示出了用户下拉列表规范的屏幕。用户下拉列表可以在顶部导航栏右侧被访问并组织以遵循层次。可以根据用户的类型限制对用户下拉列表的某些特征的访问。例如，仅管理员可编辑人们、地点、地点简档或人们简档以及用户访问控制。
图77示出了web应用下拉列表的屏幕。图77包括：
7701.主页：转向最后访问的地点的仪表板
7702.地点：到图78所示的屏幕
7703.人们：到图79所示的屏幕
7704.用户验证：(在别处讨论)
7705.编辑个人简档：到图80所示的屏幕
7706.注销：使用户登出加密消息传递系统并打开主页。
图78示出了web应用地点页面的屏幕。图78包括：
7801.“新地点”：将用户带入登记过程。因为用户已经将其所有个人信息键入到系统中，所以他们可以跳过该部分并直接转向地点搜索屏幕。可以在“新地点”规范中对此进一步说明。
7802.“人们”：到图79所示的屏幕
7803.“编辑地点”：到图81所示的屏幕
7804.“打开”：打开所选地点的仪表板。
图79示出了web应用人们页面的屏幕。图79包括：
7901.“邀请人们”按钮打开邀请模态
7902.此下拉列表允许用户在各地点之间切换。当用户选择新地点时，屏幕可以刷新以示出该用户数据库。
7903.“医生”选项卡可以示出仅所选具体地点中的医生用户。
7904.“工作人员”选项卡可以示出仅所选具体地点中的工作人员用户。
7905.“患者”选项卡可以示出仅所选具体地点中的患者用户。
7906.每行可以示出不同用户的姓名、他们能够访问的空间以及用户是否为管理员。
7907.如果所列出的用户具有管理员状态，则“检查”可以落在管理员类别下。如果不是，则可能有一个X。
7908.“编辑”链接打开到图80，即用于编辑用户的个人信息的模态。
7909.“移除”链接打开用于从地点中移除用户的对话框。
7910.“消息”链接可以在仪表板上打开与用户的会话。
图80示出了用于编辑用户简档的屏幕。图80包括：
8001.“新消息”按钮可以在仪表板上打开与用户的新会话。
8002.“管理员状态”下拉列表可以包含选择“管理员”和“非管理员”。如果“管理员”被选择，则用户可以具有所有管理员能力。
8003.用户信息
8004.“用户类型”下拉列表可以包含选择“医生”、“工作人员”和“患者”。这可以影响用户在整个网站中的标签。
8005.检查空间群组可以允许用户访问该具体空间。取消选中空间群组可以禁止用户访问空间。
“保存改变”按钮可以更新数据库中所有改变的信息。
图81示出了用于编辑地点的屏幕。图81包括：
8101.首页—转向所选地点的仪表板
8102.用户的地点的下拉列表
8103.地点的面向用户的名称。可能广泛地影响数据库地点名称和名称站点
8104和8105.用于地点简档/数据库
8106.可能广泛得更新地点信息/数据库
8107.“编辑”可以让用户改变空间的名称(参见第10点。)
8108.“打开”可以将用户带到所选空间打开的仪表板
8109.“移除”可以打开询问用户是否确定他们想要移除它的模态(移除/取消选项)
8110.“编辑”空间的视图。
图82示出了用于编辑个人简档的屏幕。图82包括：
8201.标题：对于列表使用http://www.pamf.org/physicians/titles.html。
8202.用户信息
8203.电子邮件
8204.专业：对于列表使用可在http://www.mclarenhealthplan.org/HealthAdvantage/AListofDefmitionsofMedicalSpecialtiesAdv.aspx处获得的数据。
8205.手机电话号码—用于与Dr App交叉引用
8206.工作号码：当用户在患者的联系人列表中并且患者按“电话”按钮时呼叫的号码。
8207.编辑图像：图像适用作为整个用户站点的简档图像。打开文件浏览器以选取图像。
8208.编辑密码
8209.管理员特权：示出检查用户是否为管理员，如果用户不是则示出X
8210.保存所有改变并将用户带到前一个页面。
图83示出了用于编辑密码的屏幕。图83包括：
8301.当前密码必须与用户的当前密码匹配
8302.新密码必须匹配。
图84-85示出了被转移用户界面的屏幕。例如，被转移用户界面可以用于允许将诸如医生/工作人员用户(A)的转移用户将与患者(P)用户的会话传递给另一医生/工作人员用户(B)。当发生这个时，A-P会话被关闭，整个A-P会话被复制到B-P会话。加密消息传递系统可以检查先前是否已经通过了会话，使得那些消息可能不被再次复制(仅从最后转移点开始复制消息)。B和P可以能够在“他们的”的会话中查看A与P之间的对应，并且本身继续讨论。图84包括：
8401.此图标当被点击时，可以向用户提供被允许访问此具体空间的用户(排除患者)的下拉列表。
8402.选择这些用户中的一个可以将可见聊天的整个对应“转移”到所选择的任何人。这样做可以有效地移除从您的控件到所选用户的对应。
8403.转移用户正在与之讲话的患者/用户—要转移
8404.转移用户(您自己)。
图85示出了描绘用户看见他们在所述转移之后接收到的对应的屏幕。图85包括：
8501.接收用户
8502.被转移用户(具有对应)
8503.接收用户
8504.对应可以作为新对应出现在您的直达消息下
8505.转移用户与被转移用户之间的所有对应都可以用于供查看，并且从这时起，转移用户不再控制此对应。这现在是活动对应并且接收用户必要时可以继续与被转移用户聊天。
图86-89示出了人们/地点搜索特征的屏幕。为了找到要邀请以加入地点、创建连接或发送转诊病人的同事，医生/工作人员可能需要搜索数据库的能力。医生和工作人员可以能够搜索其他医生或其他地点，查看用户/地点简档并且发送消息/连接请求。图86示出了同事搜索的屏幕。图86包括：
8601.为了启动搜索，医生/工作人员可开始在顶部导航栏上的搜索栏中键入。一旦医生/工作人员命中返回，搜索结果屏幕就可以示出适合所搜索的文本的所有用户。
8602.医生/工作人员可以选择搜索医生和地点。选择“人们”可以在数据库中搜索医生。选择“地点”可以按名称或地址搜索地点
8603.一旦将名称键入到搜索字段中，具有匹配名称的医生可以填充页面。可以连同医生的姓名一起示出其位置、地点和教育，以给搜索医生/工作人员提供更多的信息以帮助他们找到正确的用户。
8604.点击“连接+”可以将所选用户添加到原始用户联系人列表。
8605.点击“发送消息”可以给予医生/工作人员通讯联系另一医生的快速方式。
图87示出了地点搜索特征的屏幕。图87包括：
8701.为了启动搜索，医生/工作人员可开始在顶部导航栏上的搜索栏中键入内容。一旦医生/工作人员命中返回，搜索结果屏幕就可以示出适合所搜索的文本的所有地点。
8702.医生/工作人员可以选择搜索用户和地点。选择“人们”可以搜索用户。选择“地点”可以按名称或地址搜索地点
8703.一旦将地点键入到搜索字段中，具有匹配名称的地点就可以填充页面。连同地点名称一起，搜索医生/工作人员可以看见该地点的主要电话线路和传真电话号码。
8704.点击“连接+”可以将地点添加到左侧栏上的用户“地点”列表。在地点下，可以列出该地点的空间。用户现在可以能够以患者将能够与他/她所属的那个地点的空间进行通信的相同方式与那个地点的空间进行通信。如果用户试图与在加密消息传递系统上当前不活动的地点连接，则可以将用户定向到图88上示出的屏幕。在那里，用户可以被提示业务不活动并给予通过传真邀请地点的选项。
图88示出了未找到地点的屏幕。在地点被搜索并且尚未变得在加密消息传递系统上活动的情况下，搜索医生/工作人员可以查看此消息。他们可以选择向该地点发送邀请。图88包括：
8801.如果医生/工作人员选择邀请地点加入加密消息传递系统，则该地点可以接收到我们在数据库中对于该地点具有的传真号码的传真。传真可以给予关于谁在邀请他们、如何加入以及他们是否在加密消息传递系统上等待转诊病人的信息。
图89示出了用户可以使用来注册加密消息传递系统的传真，如8901所示。
图90-93示出了web和信使应用中的提醒特征的信息。提醒特征充当用于工作人员用户目前或在将来的预定时间通过电话、文本、电子邮件或通过应用与患者用户进行通信的方式。图90示出了用于工作人员创建提醒的屏幕。图90包括：
9001.创建提醒选项卡显示此界面
9002.所有提醒界面选项卡
9003.“联系信息”：患者姓名文本字段是自动填写的，并且可以填入其他字段(“家庭号码”、“单元号码”、“电子邮件地址”)
9004.复选框：患者用户可以在所有选中选择处接收“提醒”(例如，可以通过应用提醒此用户，他们可以接收到其手机的文本，可以接收电子邮件。)
9005.单元号码可以始终接收文本消息
9006.预约时间：当向患者用户发送提醒时，患者用户可以接收到以下信息：可以举行预约的地点、医生姓名、预约日期/时间和备注(若提供的话)。
9007.现在：当按“完成”时，这可以立即向患者用户发送消息。
9008.“具体时间”：这可以在所选确切时间向患者用户发送提醒。
9009.“在预约之前”：选择此选项可以将患者的预约时间用作变量。微调框的选项应该不高于7，并且下拉列表的选项应该为：日、周、月。
9010.“备注”：工作人员应该希望提供的任何额外信息可以进入此文本字段(任选)。所有其他信息都是完成表单所必需的。
9011.“取消”：表单可以删除，并将用户带回到仪表板
9012.“完成”：选择“完成”可以将提醒存档，直到打算发送它或者在工作人员已选择了该选项的情况下立即发送它为止。它还可以将提醒发送到图91(所有提醒)所示的屏幕上的表单。
图91示出了针对工作人员的所有提醒界面的屏幕。图91包括：
9101.选择“所有提醒”选项卡可以显示此屏幕
9102.在提醒已完成之后，来自所述提醒的所有数据可以在这里显示
9103.选择“编辑”按钮可以显示“创建提醒”屏幕，但是来自所选提醒的所有信息可以被完全填入。选择“取消”可以从列表中删除提醒，并且可能不将它发送到患者用户。
图92A-92B示出了针对患者的提醒界面的屏幕。图92A-92B包括：
9201.选择“提醒”图标(4)可以显示此屏幕
9202.“提醒摘要列表”可以显示医生姓名、患者用户的预约日期/时间(不是接收时间)以及来自“备注”字段的文本的短样本，后面是类似于历史中的消息摘要的省略号
9203.预约日期/时间
9204.“提醒”图标
9205.“返回按钮”可以将用户带回到提醒屏幕
9206.“提醒”：来自此屏幕的所有信息都是从图90的除位置外的字段中拉出的。可以根据提醒发送自哪里自动地加载地点信息
9207.来自“备注”字段的任何文本可以在这里显示
提醒可以在预约日期已过去之后消失。
图93示出了用于患者提醒的电子邮件的副本，如9301所示。可以将来自患者提醒表单(例如，图90)的用户变量插入在电子邮件的相关部分中。图94示出了应用中患者提醒的副本，如9401所示。
图95-98示出了web信使应用中的聊天特征的屏幕。图95示出了信使中的聊天特征的屏幕。当用户选择文本栏左侧的(！)图标时，紧急/重要框可能弹出。当被选择时，可以将消息标记为紧急或重要。
图96示出了通知的屏幕，如9601所示。当用户接收到被标记为紧急、重要或转诊病人的消息时，可以在这里通知他们。每个可以是下拉列表。每个条目是未读/重要消息。当从下拉列表中选择一个条目时，会话可以在用户的仪表板上打开，并且可以将所选消息滚动到视图中。每个条目具有允许关闭它(并将它从紧急/重要菜单中移除)的按钮。菜单可以包括小数字图标以示出剩余有多少紧急消息。
图97示出了优先级特征。用户选择紧急/重要消息的方式仍然相同。具有变化的唯一事情是用户可在已发送消息之后标记/取消标记消息的方式。图97包括：
9701.这示出表明消息既不重要也不紧急的状态。这些图标是可点击的。如果图标未被标记，则用户现在可以在事实之后获得将任何消息标记为紧急/重要的能力
9702.这示出标记为“重要”的图标。无论发送用户发送标记为重要的消息，还是在接收用户将消息视为重要的情况下，这可能看起来相同。
9703.这示出标记为紧急的消息。它具有与重要图标相同的功能性。可同时标记紧急和重要两者。
如果用户想要将他们已接收到的消息标记为紧急/重要，则他们可以能够这样做，但是它可能对另外看见该消息的任何人不可见。当用户在他们将消息发送到该用户之前标记消息时，可能发生这个。
图98A-98B示出了移动应用中的聊天特征的屏幕。紧急/重要消息应该在历史列表中并在会话视图中具有颜色编码的指示器。红色惊叹号用于紧急。黄色或橙色符号像警告标志一样用于重要。图98A-98B包括：
9801.紧急消息
9802.重要信息
9803.保持消息可以使屏幕变暗并显示消息
9804.按“标记为看见”可以像正常那样示出消息。没有颜色或图标。也可以从通知中移除。
图99示出了用户等待被验证的屏幕，如9901所示。对此特征的访问可能限于医生和工作人员类型用户，不是针对患者类型用户的。当用户(医生或工作人员)由于其账户尚未被地点管理员验证而处于“保持”状态时，他们可以查看此屏幕。它可以向用户示出他们的信息以及也在等待被同一地点验证的任何其他用户信息。一旦用户已被验证，他们就可以被给予对仪表板的访问并且可能不再看见此屏幕。可执行置于所列出的一个办公室位置和状态下的所有用户：(1)用户...活动、待定激活、被验证、待定验证、HIPPA授权和(2)邀请(通过电子邮件、文本、NPI、办公室号码)、验证(通过传真、电话)并由所有者(管理员或医生)授权。图99包括来自注册过程的用户信息；“管理员”是地点的管理员用户；3.“被验证”是地点的被验证用户；“关联的”是通过关联到另一医生被验证的用户；“受邀请”意味着他们被邀请但是仍然尚未被验证；“待定”是自己注册了但是仍然尚未被验证的用户。
图100示出了转病人诊模态的屏幕。图100包括：
10001.按以打开模态
10002.“转入”是从其他医生/地点接收到的转诊病人
10003.“转出”是从您的地点发送的转诊病人
10004.“接受”按钮可以将用户添加到您的“患者”联系人列表
10005.“拒绝”可以将用户从此列表中移除。
图101-102示出了用于管理员手动地验证新用户的屏幕。在用户完成其注册过程以加入加密消息传递系统中已经存在/运营的地点之后，该地点的管理员可以查看可以给予关于试图加入的用户的详细信息的此表单，并且被给予要接受/拒绝对其地点的访问的选项。图101包括：
10101.管理员从此按钮访问
10102.可以从用户的登记过程的表单中拉出所有可见信息。地点/地址可以为用户正在试图加入的地点
10103.按接受按钮可以将用户添加到地点。他们可以具有完全访问权限(除了管理员特权之外)并且通过关联来验证。按这个还可以向他们发送“接受”电子邮件并将它们从此列表中移除。拒绝按钮还可以将它们从列表中移除，以及向他们发送拒绝电子邮件。他们可能未被给予访问权。
图102可以是可见的以便加密消息传递系统工作人员查看和编辑，如10201所示。当用户不能验证自己或他们正在创建的地点时，我们可能需要在内部做那个。当点击接受时，用户然后可能接收到陈述他的验证的电子邮件并且可能具有对medroster.com的完全访问权。当被拒绝时，可以向用户发送拒绝电子邮件。当任何一个接受/拒绝被按时，用户从此列表消失。
加密消息传递系统可以包括在线/离线状态能力以允许用户在web和移动设备上(稍后，在历史或联系人进入之后)看见什么用户在线和离线。图103示出了具有在线/离线状态能力的屏幕。图103包括：
10301.绿色点(或空白点)指示用户在线
10302.灰色点(或阴影点)指示用户离线。
在线用户应该被一起分组在顶部。在线用户应该是字母顺序的。离线用户应该被一起分组在底部。离线用户应该是字母顺序的。
如果患者类型用户设法从一空间联系某人并且没有工作人员在线，则该用户应该接收到说没有人在线的消息，而当某人在线时可以返回他们的消息。
图104-111示出了关于如何为加密消息传递系统添加地点的一系列屏幕。加密消息传递系统可以将任何医疗业务或机构称为地点。
加密消息传递系统可以允许多种方法创建地点。例如，创建新地点可以在注册过程期间发生。如果用户希望激活/创建新地点，则用户将需要在单独的电子邮件地址下注册(例如，使用在加密消息传递系统中不存在的电子邮件)。为了解决此问题，加密消息传递系统允许用户在他们被登入(例如，使用已经存储在加密消息传递系统中的电子邮件登录到加密消息传递系统中)时激活/创建新地点的能力。
图104示出了对地点进行搜索的屏幕。与注册过程类似，用户将需要首先搜索他们正在试图创建/激活的地点。他们可能被指示去寻找他们的地点，并且如果他们不能找到其地点，则他们可以选择创建他们自己的地点。图104包括：
10401.键入要搜索的地点的名称或地址
10402.按州缩小
10403.按邮政编码缩小
10404.选择具体地点可以将用户带到确认页面(图105)
10405.与搜索字段匹配的地点的列表
10406.如果地点不在数据库中，则用户可创建他们自己的地点并等待管理批准(图106)。
图105示出了用于确认地点的屏幕。例如，可以在用户已从图104中选择了地点之后向用户呈现屏幕。图105包括：
10501.所选地点的显示
10502.用户可能需要键入地点的国家提供商标识符(NPI)以确认
10503.点击确认可以对照数据库信息来检查NPI。如果正确，则可以向用户示出图108以供电话确认
10504.如果用户没有NPI，则可以向他们示出图108(手动验证)
10505.如果选择了错误的地点，则用户可返回(返回到地点搜索图104)。
图106示出了用于创建地点的屏幕。可以将在图104上选择“创建地点”的用户定向到此屏幕。图106包括：
10601.用户将信息键入到所有字段中
10602.如果收集了所有信息，则用户可以继续到手动验证屏幕(图108)。
图107示出了用于验证地点的屏幕。使用加密消息传递系统在数据库中具有的主要电话号码，一旦加密消息传递系统选择“继续”，加密消息传递系统就可以呼叫用户并提供验证码。图107包括：
10701.来自数据库的用户主要电话号码
10702.按“继续”可以提示系统拨打#1中的电话号码并且移动到下一个屏幕(图108)。
10703.按“手动验证”可以将用户带到图111所示的屏幕并将用户信息发送到“管理员验证”屏幕。
图108示出了用于验证电话的屏幕。在用户提示系统呼叫数据库提供的电话号码之后，用户可能接收到对该号码的呼叫。加密消息传递系统可以向用户提供要键入到文本字段中的代码。图108包括：
10801.验证码的文本字段。在正确的验证码情况下按继续可以将用户带到图110所示的屏幕。不正确的代码可以将用户带到图109所示的屏幕。
10802.按“手动验证”可以将用户的数据带到管理员验证屏幕。
图109示出了当存在电话验证错误时的屏幕。如果用户键入不正确的代码，则他们可以查看此屏幕。图109包括：
10901.用户可以选择接收另一呼叫或手动地验证其信息。此循环可以继续直到用户键入正确的验证码为止。按继续可以将用户发送到107以重新发送呼叫。
10902.手动验证。
图110示出了当电话验证成功地完成时的屏幕。按继续11001可以将他们带到仪表板。
图111示出了用于执行手动验证的屏幕11101。例如，如果用户试图创建/激活地点但是不能验证NPI或主要电话号码，则用户可能必须由加密消息传递系统管理员验证。点击“返回到仪表板”可以将他们带回到账户页面。他们应该始终被登入。
图112示出了具有参考点的搜索结果页面的屏幕，如11201所示。参考点可以包括全名、执业区域、地址或其他相关用户信息。参考点可以由最靠近地点位置的从业者排序并按从最靠近到最远的降序(基于搜索用户的地理位置信息)列出。
图113示出了邀请表单的屏幕，如11301所示。例如，此屏幕示出了如何将同事添加到加密消息传递系统。此屏幕将邀请细节合并在单个屏幕上，以简单地将用户添加到Medroster团队。
图114示出了邀请表单的屏幕，而无需将他们添加到现有医疗执业，如11401所示。例如，这可以用于邀请用户尝试Medroster平台，而不将他们添加到您的团队。
已出于图示和描述的目的呈现了本发明的描述。它不旨在为详尽的或者将本发明限于所描述的精确形式，并且鉴于以上教导，许多修改和变化是可能的。实施方式被选取和描述以便最好地说明本发明的原理及其实际应用。本描述可以使得本领域的其他技术人员能够在各种实施方式中并按如适于特定用途的各种修改最好地利用和实践本发明。本发明的范围由以下权利要求限定。
- 加密消息传递系统
- 自动化设备和机器人的消息传递方法及动态消息传递系统