Unless I have completely misunderstood something, let me share my thoughts.
Again, I am completely ignorant about your device, but let me have a theoretical example.
To make it very simple, let say the transferring device you have is collecting patient body temperature by Bluetooth communication , really keep it very simple, from multiple measurement devices attached to the patients and your device transfers these measurements to the central monitoring "server" for further processing and analysis.
So we get the body temperature of multiple patients via Bluetooth communication, we store temporarily it and than we transfer it, let say via Bluetooth to the analysis server station.
In my imagination I would raise the following potential hazards. It is not an extensive list, rarely the ideas first come into my mind.
1., Patient mix-up
There is a potential that our device transfers body temperature for a different patient than it was actually measured.
Severity:
The extent of such mistake should be evaluated by physician. Could be major, because patient may get drug that actually they do not have to and it cause a very not expected side effect in her/his condition, furthermore this drug may hide in a future the actual status of the patient, really I can not determine the extent of it.
Several hazardous situations can relate to this hazard, my thoughts would be:
1., when receiving the data, it's already corrupted for patient identifier and we are not aware of that we actually transfer the corrupted data,
2., when we are transferring the data, regardless we have received the correctly assigned body temperature data to the patient it is corrupted at the server side we are transferring to and patients are mixed up.
Probability, that these hazardous situations can occur also up to the physician who knows the extent and the landscape of this whole scenario.
The causes for these two could be:
1., a, sensors are mixing up patient data and we receive already corrupted data
1., b., Bluetooth communication is falsifying the correct data from sensor (due difference of different Bluetooth protocol, lack of false-safe communication for communication interruption cases, I am only guessing ... )
2., a., Due to our implementation (database storage, calculation, whatever mechanism we have that use the patient data) we corrupt the patient data.
It can be when due to our implementation consideration (our design and our corresponding code) of the Bluetooth protocol (may be we use a public library for this, but that again can fail to do it properly).
It can be, because the database we use corrupt the patient data (data format mix-up, truncation of patient identifier, anything).
It can be, because we do pre-calculation or formatting of the received data and our algorithm falsify the patient data, or the way than we store it does so.
2., b., Due to our implementation of the transfer Bluetooth communication, it mixes up the patient data. Or again, there is a probability, that regardless the communications are implemented correctly, the difference of the the different versions of the protocol may cause mix up.
Risk control measures to eliminate or to limit these causes:
I have no idea, it should be worked out with the engineers and the physician.
Because physician can decide if the planned control possibly reduce the probability of the hazardous situation to occur.
Moreover physician can decide if the device can be considered as safe for medical use. No on else can do so.
I would not like to be too long, but some more hazard category, I would raise for this case.
2., Measurement mix-up
Body temperatures can be measured in Celsius, Fahrenheit, whatever.
There is a hazard that we mix up this essential measurement.
3., Body temperature chronological order mix-up
There is a hazard, that we do not receive/store/transfer these data in a correct chronological order.
4., Bluetooth communication fraud.
Yes, somehow we need to consider the hazard when someone intentionally fraud the data due to security leak.
5., Data loss
There is several scenarios can drive to it, typical example of the boundary situation when our database gets full. Or when our maintenance mechanism in place on the database.
This would be my far not comprehensive example, just for a food of thoughts.
Well, it can happen, when someone opens up Pandora's jar though
Cheers!
Ps.:
One more thing ...
The more or less expected content of the hazard analysis somehow should detail the following:
1., Identified hazards
2., Hazardous situations when the hazard can occur and lead to patient harm (1:n relation per hazard)
3., Severity per hazardous situation
4., Potential causes of the hazardous situation (some of us may say of the hazard, I have some doubts if the hazard itself can be elaborated into causes at the first place), its also 1:n relation to the hazardous situation
5., Initial Probability of the hazardous situation (initial probability, considering none of the actual implementation)
6., Risk evaluation of the hazardous situation based on the severity and initial probability.
7., Description of the Risk control measure in place to reduce the risk.
It is a common debate, the some of us considers verification as a risk control measure.
NO.
It needs to be a kind intelligence built in the device. Professional literature stipulates to consider design, protective measure, information on safety as a potential method in this order.
8., Residual severity evaluation. I have doubts if it can be different than the initial severity. I know, there is a tendency to say severity can be reduced, but clearly, as long as we have that behaviour in place in the device than how on earth can the severity to be reduced?
9., Residual probability, when the risk control measure in place.
10., Residual risk based on 8., and 9., .
11., Risk/Benefit analysis and decision of the control measure. (moreover there is a risk/benefit assessment for the device as a whole at the end looking into all identified hazards and work carried out as related to those)
12., Verification method and particular way of it as regard to the applied risk control measure to ensure its effectiveness.
I think more or less that's all.