Talk:DCM4MD:Project Use Cases

Case 1 is the conventional ICU or OR scenario where there is an 'anchor' piece of equipment that doesn't ordinarily move, for example a patient monitor or fixed 'concentrator'.

The same effect can be gotten by reference to a switch port with a well-known association with a room or other location: the software determines from the switch what piece of equipment is attached. A necessary precondition here is that there is a well-known unique identifier (e.g. MAC address) for the piece of equipment, ascertainable over the network. This requires comprehensive pre-configuration so that some software has access to a more or less complete inventory of equipment and identifiers.

Observations:

There are some implicit assumptions about the actors that need a closer look here. There are major differences in relevant capabilities among devices and among 'managers' or gateways that impact the scenarios.

There is a tacit assumption that the goal includes having patient identity flow back to the device. What is really necessary is that the system as a whole have a reliable association of patient and data. Some devices simply do not have the capability of holding a patient identity.

Equipment doesn't usually report location, more commonly it is established by configuration in the manager or possibly the EHR.

Time synchronization has a somewhat tangential relationship to these scenarios, and should probably be treated as a separate factor. It is true that if a device or manager is reporting time with observations, it must be well synchronized for the identity transactions not to be nonsense, but for the purposes of this part of the analysis, why not say that this must be so but that the time issue will be analyzed separately.

John rhoads 04:31, 31 January 2011 (UTC)