• 他们在一个国家气象站注册了帐户，该气象站向他们提供关于飓风状态的警报。
• 他们访问当地政府网站了解关于避难所的细节，但他们没有获得有关哪些避难所已关闭和新开了哪些避难所的最新信息。
• 他们访问当地政府网站了解关于避难所的细节，但他们没有获得有关哪些避难所已关闭和新开了哪些避难所的最新信息。
• 许多自愿者提供了食物。所有沟通都是通过断断续续的、临时的社交媒体或口头传播。

• 在自然灾难期间，受影响的居民需要一个综合门户来获取基本信息，以便能够利用可用的服务。
• 在受灾期间购买服务不应依赖于现金或卡。信贷工具应该支持虚拟货币，比如手机钱包。
• 该门户应是一个安全的环境，其中所有各方都应经过验证且尽职尽责。
• 该应用程序应允许居民发布他们的服务。
• 该系统应能定位最近的避难所和服务提供者。
• 该门户应支持失踪人员搜索。
• 该环境应可信且透明，以防资金管理不善。
• 有关服务可用性的最新信息应实时提供给所有各方。
• 该系统应支持对居民和供应品进行追踪。
• 基于实时居民跟踪信息，可以启动救助工作。
• 该门户应能集成由服务提供者独立管理的现有生态系统。
• 政府当局应拥有实时的需求信息，以便评估要发放的资金金额。
• 灾后，政府当局应能根据数据对参与方给予报酬或奖励。

• 服务提供者同意向避难所提供所需的材料，在接受来自政府的资金后没有兑现承诺。但是，在服务提供者使用相关细节更新其企业解决方案/数据库后，他声称已将资金用于一些预期的活动。
• 政府官员声称已将资金发放给服务提供者和居民（通过向他们的手机钱包增加资金），但资金没有到达相关方。
• 政府声称已通过居民的手机钱包向他们提供了一些资金，但居民没有收到这些资金。
• 某个人的医疗服务需要昂贵的治疗费用，而该居民无法承担，则该医疗服务有资格享受政府资金。这需要一种可信且透明的设置，帮助政府验证资金的使用。
• 一个居民申请了一项服务，而且服务提供者接受了这项服务申请。但该服务提供者从未提供这些供应品，而且声称没有收到该申请。该申请似乎在他的系统上删除或取消了。
• 从政府到服务提供者的款项结算很耗时，因为结算清单很长，而且需要验证。

• 区块链通过其不可变性提供了一个安全的环境，其中的记录一旦创建就无法篡改。这创造了一个支持责任性和治理的可信环境，从而解决了上述存在冲突的用户案例。
• 区块链使用了一个共享分布式账本，确保事务和数据在创建后能立即发送给所有相关方。这促进了尽早结算。

• 手机或卫星电话可用来跟踪居民和运输车辆。
• 装载食品和医疗供应品的纸箱上的 RFID 标签，可以帮助记录避难所的供应品接收情况。
• 最新的天气和交通数据信息可用来提供通往最近避难所或供应者的最佳路线。

• 自动记录注册用户的位置。
• 提供实时天气更新 – 卫星图片、危险级别。
• 提供现有应急管理系统的集成点。
• 通过分析来帮助尽早检测失踪人员。
• 地图……
  • 显示各个地点（主要是避难所）收容的用户数。另外，支持标出某个特定的注册用户。
  • 显示服务位置，比如避难所、食物、医疗。
  • 推荐通往避难所和服务提供者的最佳路线。
  • 提供地理栅栏来防止居民跨越边界。

• 政府（灾难管理部门）
• 电信公司
• 避难所
• 食品供应者
• 运输者
• 医疗用品供应者
• 医疗服务提供者
• 居民

High level illustration:

• 政府创建联盟并提供一个商业平台来销售他们的服务。
• 政府创建联盟并提供一个商业平台来销售他们的服务。
• 政府可以向参与此网络的组织提供奖励和税收优惠。
• 政府将技术服务外包给 IT 公司，该公司为此解决方案提供平台（区块链环境、移动应用程序等）。
• 免费提供一些基本的应用功能（跟踪家人、查看天气条件、预定避难所、购买食物、医疗用品和运输，等等）。一些高级功能是付费提供的（跟踪好友、地理栅栏、医疗专业服务等）。
• 居民在此网络上使用自己的手机钱包购买服务。如果出现财务损失，他们可以利用政府资金来补足钱包。让居民能自行购买服务，这减轻了政府与服务提供者之间的结算负担。