Some physiology data needs to be published with ever 'tick' of the engine, but much more doesn't. Most of the data published with each 'tick' needs only best-effort delivery, provided each 'tick' of data is seen as a coherent set by the subscribers. This is to ensure a module sees consistent physiology state, even if it's not receiving every 'tick' of data. Some data, such as an EKG waveform, needs to be published each tick with reliable delivery.
Most of the data generated by the physiology engine has little or no meaningful change on short time scales. Because of this, it can be updated much less frequently, and has little impact on design decisions.
Because of the sizable data throughput generated by the physiology engine, and the need to support modules connected over the public internet, data sent to modules should be minimized as much as reasonably possible. Additionally, because it is a design goal to be able to run the manikin software entirely on embedded computing hardware, a secondary priority is to reduce computational overhead where possible.
All data within a Topic shares the same QoS.
DDS provides coherent access to data changes, but RTPS restricts coherent access to a single Topic. Thus, most of the physiology data that needs to be published with every 'tick' need to live in a single Topic. Because this is a sizable amount of data, and modules will likely only want to subscribe to a small subset of it, the DDS Publisher implementation wrapping the physiology engine should provide writer-side filtering.
Data requiring less-frequent publication can probably be sorted into Topics based on content rather than performance requirements. Presumably, these groupings will become self-evident as the AMM Common Data Model (CDM) is defined.
Useful sections in the DDS Specification:
Good high-level breakdown of how to use DDS.
More details on how to actually read data from DDS when it's updated.
An alternative architecture on how to handle data updates with a much more thorough discusion of this access pattern.
This describes how DDS provides info about every Topic and every reader & writer connected to a domain. They could be very useful for monitoring & logging.
Super useful ladder diagrams depicting how DDS is designed to actually be used. These would've been very useful to see much earlier in the document.