There's a big difference between a centralized and decentralized model here.

* Centralized, there's a single (or only a few) worldwide APIs that you need approval to work with. This also hinders interoperability of different end-user app implementations.

* Decentralized, anyone can set up a distribution server and require whatever authentication they'd like for it. A local government, a hospital, the Red Cross, etc. The framework becomes nothing more than a decentralized protocol that can potentially even be repurposed for other novel uses.

For the decentralized approach, bear in mind that there's nothing preventing a third party from hosting and managing a distribution server on behalf of someone else. So (for example) the CDC could host a server (and handle authentication) for a state or county government that didn't feel up to the task.

Another example, say the local hospital has their own database (possibly hosted by the state or Google or whoever). They can feed their (authenticated, locally collected) data to a local authority (the city or county), which only needs to accept data from trusted institutions (ie all the hospitals in the area). They can in turn feed this inherently trustworthy data to a state system, and so on. If each entity in this hierarchy makes their dataset publicly available, then users can independently decide which datasets are relevant to them (perhaps they traveled recently?) and check them on a daily basis.