Table 2.

Assessment of blockchain in the federation management.

FEDERATION MANAGEMENT
Do you need to store data or state?	YES. The data to be stored are represented by the identifiers of federation members and their related information (e.g., keys used to verify the integrity of the messages).
Do you have immutability or data integrity requirements?	NO. HCO identifiers should not change. However, the set of identifiers may change in time, as well as some of the additional information stored may need to be updated (e.g., public/private keys may need to be refreshed as well as digital certificates). Data integrity YES. The federation membership should contain only the identifier of effective members. Identifiers should not be tampered or created.
Do you have non-repudiation requirements?	NO. Non-repudiation is desirable, but it is not currently a requirement.
Do you need to support multiple writers for the same data?	YES. Let us recall that the data stored are a set with all the identities of participating members. As a consequence, this set can be updated by any member that wants to leave or by a new member that is trying to join the federation.
Is there a TTP and is it always online?	NO. A TTP need to be assumed as bootstrap node to be accessed by members that want to join the federation. However, this node is not guaranteed to be always online.
Are writers known and trusted?	YES. In our context, we are considering the creation of a federation among collaboration entities. Thus, participating members must be known and trusted.

HCO, health-care organization; TTP, trusted third party.