SOLUTION ARCHITECTURE AND

TECHNICAL OVERVIEW

Decentralized platform for coordinationand administration of healthcare and benefits

ENABLING TECHNOLOGIES

Blockchain

Distributed ledgers

Smart Contracts

Relationship logic

Data Management

Aggregation, linking

Cognitive Computing

NLP, machinelearning

Behavioral Analytics

Historical,forecasting

Cloud Computing

Distributed nodes,storage

GUIDING DESIGN PRINCIPLES

• Distributed immutable ledger• Used for tracking all events and content

• Synchronization protocol• Real time event based synchronization

• Inheritance• Ensure multi tier inheritance of properties

• Protocol entity pairs• Encapsulate all elements of relationship between two parties

• Stacking and linking• Hyper linking of objects and properties

• Application container• End user application with defined usage

• Edge applications sync to container• Standardized applications that inherit the container and protocol properties

• Extensible data model• Public and private data, event and context

• Loose coupling• Avoid or minimize point to point integration

• Standards• Support for all data and network standards at layer below protocol

• Interfaces• Event, data and security envelope

• Separation of concerns• Encapsulation by function & purpose

PLATFORM COMPONENTS

• Care.Wallet Application container

• Card Stack

• Coin Pile

• Care.Protocol

• Protocol Pairs

• Protocol Endpoints

• Event Ledger

• Event Handler

• Identify and Access Management

• Smart Contract Library

• Data Model

• Data Hub

• Operational Data Store

• Care.Vault, Care.Cabinet & Care.Record

• Care.Marketplace

• Integration layer

• Distributed Processing nodes

• Network Topology Manager

• Open API and services

SOLVE.CARE PLATFORM TECHNICAL COMPONENTS

SOLVE.CARE ARCHITECTURE

• Platform is based on event driven architecture

• Designed to synchronize entities, wallets, cards, coins etc.

• Requires little to no direct integration

• Supports integration with 3rd party systems and entities via loose coupling

SOLVE.CARE ARCHITECTURE

• Solve.Care platform is designed on a hybrid architectural approach

• Distributed ledger

• Authorized entity model

• Event based architecture

• Stateless transactions

• Service orientation

• Loose coupling

• Stateful relationships

• Data and protocol encryption

SOLVE.CARE ARCHITECTURE

• Care.Protocol is the foundation for the event based approach

• Designed to deliver events to all parties to whom event is of interest

• Entity can read an event

• By pairing with an entity

• Subscribing to an event

• Accessing event ledger

• Access to events is based on public-private hierarchy

• Protocol node

• Paired entity

• Shared

• Ledger access

• All events are stored in blockchain ledger

CARE.PROTOCOL.PAIRS

• Each entity has a 32 digit protocol ID

• Using the protocol ID, entity registers on the network

• Forms protocol pairs

• Two entities form a pair called Care.Protocol.Pair (protocol pair)

• They “sign” a contract that binds them to rules of relationship

• Wallets, cards, coins, endpoints are then governed by pair rules

• An entity can be part of multiple pairs

• Protocol pair captures all elements of the relationship

• Protocol pair definition is kept in blockchain and is contract between parties

CARE.PROTOCOL.PAIR DEFINITION

• Events between the pair

• Nomenclature

• Method

• Timeliness

• Content accompanying events

• Format

• Standards

• Relationship contracts• Rules of relationships

• Transactional contracts

• Access contracts

• Audit contracts

• Relationship Context• Care.Cabinet

• External data sources

• Reference data

• Shared data dictionary

• Access and delegation

• Public data

• Private data

• Sharing

• Care.Cabinet

• Designation, location and access

• Shared cabinet folders

• Private cabinet folders

CARE.PROTOCOL ENDPOINTS

• Endpoints are connection points to external systems and entities

• Endpoints allow for exchange of events without integration

• Endpoints are SOA integration and service access points

• Endpoints can be for public use or limited (protocol pair or entity)

• Endpoints can be configured for different transports

• SMTP, HTTP, HTTPS, FTP, Web-service, SQL, JMS, others

• Endpoints can be extended to support new transports

• Endpoints can inherit and enforce protocol pair contracts

• Content, format, standards, timeliness, consent etc.

PROTOCOL EVENT HIERARCHY

• Organized into event hierarchy• Protocol events – published to all nodes• Pair events – published to all entity pairs of a kind• Pair entity events – published to specific entity you are paired with• Delegated events – event authorized for publishing to a delegation (non-pair)• Subscribed events – events can be read from the distributed ledger directly

• Primary and multiple secondary tags

• Access

• Transaction

• Control

• Query-Response

• Admin

• Additional event tags can be defined and visible to protocol pair entities

CARE.PROTOCOL EVENT TYPES

CARE.PROTOCOL EVENT FLOW

CARE.WALLET FRAMEWORK

• Care.Wallet is the end user application container

• Designed for ease of usage

• Contains cards and coins

• Hold user profile and preferences

• Pairs with other entities (wallets)

• Publishes local services for cards and coins to access

• Provides access to device features

• Creates uniformity of user experience

• Syncs with Care.Protocol

• Processes incoming events

• Enforces access control

CARE.WALLET SERVICES

• Care.Wallet publishes a number of micro services

• Identity services

• Protocol services

• Data services

• Device services

• Subscription services

• Personalization services

• Services are abstracted for ease to use and compatibility

• Community and clients can use services to publish smart cards, coins, protocol pairs, endpoints etc.

CARE.WALLET SUPPORTS MACHINE LEARNING

• Care.Wallet captures all necessary data for Care.Cards to use machine learning algorithms

• Available data (strictly subject to wallet holder permissions)

• Behavioral

• Utilization

• Demographic

• Access and sharing

• Device and GIS

• Data is completely anonymized, all personal, device and identification information is removed

• Care.Community can use the data to implement machine learning for Care.Cards and protocol pairs

CARE.CARD IS A SMART APPLICATION

• Can be informational and actionable

• Lives in Care.Wallet

• Inherits all wallet properties

• Has access to all wallet services

• Has 4 edges, 4 corners and 2 sides

• Is designed to create a uniform user experience

• Can be grouped and stacked with cards in the wallet

• Can be linked with cards in other wallets

• Can be read by other wallets (access control)

• Can be published to marketplace and subscribed

• Automatically updated

CARE.CARD STRUCTURE

• Two sides

• Public Side

• Private Side

• Four edges

• Control: publisher, subscriber, purpose, cost, metadata

• Security: Encryption, access control, privacy and permissions

• Intelligence: Context, logic, rules, contracts…

• Sync: Link, stack, group and synchronization parameters

• Edges can be configured differently for two sides of the card

CARE.CARD ACTIONS

• Four corners can be used to configure user actions for the card

• Each corner can be associated with following actions

• Link card to other cards

• Flip between public and private side

• Shuffle through a deck of cards

• Share card with another entity/wallet

• Control permissions and access

• Search card or deck

• Custom action defined by card developer

CONSENT CARDS

• Consent in healthcare has special regulatory and legal meaning• Consent cards are a specific type of card, standard in all Care.Wallets• Consent cards are designed to manage and store all consents

• Data capture

• Receive clinical services

• Record sharing

• Behavioral analytics

• Directives and wills

• And many more uses

• Consent cards will be reviewed, published or commented by legal experts

• Care.Community can easily link appropriate consent card to their Care.Card

• Solve.Care foundation will invest in and manage consent cards• Protect all consumers• Enable Care.Community to be compliant with appropriate laws

DISTRIBUTED LEDGER TECHNOLOGY (BLOCKCHAIN)

• Solve.Care platform uses Hyperledger as a framework for building building and managing distributed ledger

• Permissioned blockchain with a Certificate Authority for granting access to the network• Voting-based consensus model for high performance and fault tolerance

• Endorsement• Ordering• Validation

BLOCKCHAIN BUSINESS NETWORK LAYERS

• Consensus Layer• confirming validity of transactions included into a block

• Identity Services• enables registration of system entities during network setup and operation

• Smart Contract Layer• responsible for transaction processing

• Data Mart• unified interface for accessing data sources

• Communication Layer• enabling communication channels for peer-to-peer message interchange

• Policy Layer• system policy management for consensus, groups and other

• Gateway• provides interaction between multiple blockchains

TRANSACTION FLOW

• Multilateral transaction nature, typical for complex domains is represented as a set of bilateral transactions

• Set of transactions is determined by smart contract logic

• Transaction stages

• Transaction request – initiated by a client

• Signature verification, transaction proposal check, ensure submitted for first time, verification signature and client authorization

• Verification of proposal responses, comparing proposal responses and execution of endorsement policy

• Ordering – publishing of transaction proposals to the Ordering Service

• Transaction validation – validation of transactions within the block

• Ledger update – channel chain being updated with the block

USE OF SMART CONTRACTS

• Solve.Care platform uses Smart contracts to implement business logic specific to Care.Protocol pairs

• Pair-specific business logic defined by smart contracts

• Each smart contract has it’s exclusively scoped state, which can’t be accesses directlyby another smart contract

• Smart contract can invoke another smart contract in order to access it’s state

SMART CONTRACTS INTERACTION WITH THE LEDGER

PLATFORM SMART CONTRACT LIBRARY

• Access contracts

• Data collection and use contracts

• Privacy and security contracts

• Consent contracts

• Compliance contracts

• Subscription contracts

• License contracts

• Permitted use contracts

PAIR SMART CONTRACT LIBRARY

• Insurer <-> Provider Pair

• Credentialing contracts

• Pricing contracts

• Performance contracts

• Payment contracts

• Insurer <-> Insured Pair

• Eligibility contracts

• Enrollment contracts

• Utilization contracts

• Payment contracts

CARE.VAULT

• Care.Vault is internal content repository with ability to link and aggregate payload, structured data and blockchain ledgers

• Care.Vault is instantiated for a protocol pair and is governed by rules of the pair relationship

CARE.VAULT

EXTENSIBILITY AND CONFIGURABILITY

• Data model

• Entity pairs

• End points

• End user application container

• Container applications

• Security and access control

EXTENSIBLE DATA MODEL

• Solve.Care data model is a key determinant in achieving a flexible, expandable and evolving platform for benefit administration across the globe

• The data model follows the decentralized design of the overall solution approach and is expandable by the community

• The data model is decomposed into protocol pairs, smart cards, tokens and shared entities such as identity and events

• A true innovation of the Solve.Care data model is that it supports decentralized entities that publish data to remain in sync

• Each object in Solve.Care has a defined linking and data syncing definition

• This approach makes it very flexible, powerful and expandable:

• Protocol pairs encapsulation of pair intelligence and transactions

• Linking and syncing of pair entities

• Stacked cards and linked stacks to handle complex data relationships

• Audit log of every event, transaction and interaction

• Open, published, expandable and peer approved

DATA HUB

• Data Hub is a data aggregation and integration layer

• Data Hub offers standardized data services

• Data quality

• Data de-duplication

• Data conversion

• Data hub is a data switch and not an operational data store

• Data hub is designed to abstract services independent of underlying stack

• Can use any data technology that client or community prefers

• ETL engine

• DQ engine

• MDM framework

SECURITY AND PRIVACY

• Encrypted protocol

• Separately configurable encryption standard for event and content

• Compliant with VPN, tunneling and data packet encryption

• Encrypted cards

• Separately configurable encryption standard for public and private data

• Encrypted wallet

• Access control

• Two factor authentication

• Non transferable

• Encrypted cloud backup and restore (optional)

• Comprehensive audit

• Events, access, content, users, devices, location

• Designed to exceed security standards for federal and state agencies

ENTITY, EVENT AND CONTENT SECURITY

• Content security

• Encryption

• Public content

• Private content

• Delegated content

• Event security

• Protocol

• Pair

• Entity

• Event

• Entity security

• Access control

• Protocol ID

• Pair Type

• Pair ID

• Event subscription

• Event ledger

DISTRIBUTED PROCESSING NODES

• Different types of processing nodes

• Processing nodes management

• Authorization

• Graduation

• Minimum volume guarantee

• Service Level Agreements

• Concept of gas applied to healthcare transactions

INNOVATIVE USE OF TECHNOLOGIES

• Innovative synchronization protocol• Linking, stacking, grouping and synchronization of entities and wallets

• Cutting edge technologies• Distributed ledgers, smart contracts, blockchain

• Domain extensions• Ability to inject domain context into protocol, card, coin and wallet

• Cognitive and learning• Behavioral and utilization analytics built into application container• Machine learning services

• Standardized user experience• Care.Card behavior is pre-defined and optimized through behavioral analytics

• Extensibility of protocol, card, coin and wallet• Every element of platform is designed to be community extensible and configurable

• Encapsulated pair relationships• Smart contracts enforce relationship rules

• Embedded capabilities• Data management, identity and access management, machine learning & behavioral analytics

TECHNICAL GOVERNANCE

• Platform Architecture Council (PAC) is responsible for overall platform architecture

• Governs 7 architectural layers

• Infrastructure

• Security

• Blockchain

• Event

• Information

• Component

• Business

Business

Component

Information

Event

Blockchain

Security

Infrastructure

PRODUCT MANAGEMENT COUNCIL (PMC)

• Charter - Responsible for roadmap creation, review, approval and changes

• Chaired by company CEO and CTO

• Members

• Sales

• Marketing

• Development

• Community

• Support and Dev-ops

• Professional services, delivery and integration

• Community representation is nominated via online community forum

• Meets monthly or as needed

PLATFORM ARCHITECTURE COUNCIL (PAC)

• Charter

• Platform Architecture Council (PAC) is responsible for the architecture and design of the platform in terms of sustainability, scalability, security, extensibility and ease of usage

• Function

• Approve technical design and specification all 7 layers of architecture

• Conduct market research and proof of concept projects on new technologies

• Approve adoption of new technologies

• PAC is chaired by CTO and composed of following representatives:

• Development

• Community

• Support and Dev-ops

• Professional services, delivery and integration

• PMC

• Meets monthly

• All meeting decisions are published to community

LET US REDEFINECARE, COST AND CONVENIENCE!

Contact us at info@solve.careVisit us at www.solve.care