Great writeup highlighting limitations of the Zio monitor. The human heart beats, on average, 100,000 times a day. A 14-day zio monitor looks at about 1.4 million heart beats. From this perspective, a limit of 500 asymptomatic transmissions seems like a drop in the bucket. Another challenge is the "signal to noise" problem. How many of those asymptomatic transmissions are noise? For example, patient movement may create artifact that may trigger a transmission. The heart does not function as a steady state organ. It is very dynamic and asymptomatic "extra" or "missed" heart beats are fairly common. Many of these events may not be clinically relevant. Also to consider is the limited time a physician has to scan these reports. Perhaps AI can help separate "wheat from the chaff" and save providers time, provide more accurate and clinically relevant data, and improve the overall quality. Increasing the limit beyond 500 may overwhelm clinicians with more data, with the risk that important events may be missed.
Thank you for sharing your perspective from a clinical point of view. These are great points. I wonder to what extent this type of information and insights is available in the early phase of design and development. I think this type of input would be very useful in facilitating the trade offs that is naturally present in the design process. Thanks again!
I appreciate you addressing assumptions and documentation in this article. In either a small business or large, there will be employee turnover that results in lost knowledge and history. Small businesses grow and staff are promoted/move to better opportunities. Large businesses shift priorities and persons change departments. The undocumented rationale for design decisions gets lost during employee turnover in these cases. When new persons picking up the project they are unsure and unwilling to go against what was previously established (regardless of if the rationale is documented). We tend to assume that the last person did the work correctly and that it is important, we just don’t know why.
Suggested methods for documenting assumptions are through memos, meeting minutes, power points, or design tools stored. All of which should be stored in the DHF. It provides a glimpse at what design trade-offs were considered and why a choice was made. It also provides an opportunity for the rest of the team to weigh in and either validate the assumption or propose alternatives. In this manner the assumption will live on, and the team gets awareness to the assumption.
Great writeup highlighting limitations of the Zio monitor. The human heart beats, on average, 100,000 times a day. A 14-day zio monitor looks at about 1.4 million heart beats. From this perspective, a limit of 500 asymptomatic transmissions seems like a drop in the bucket. Another challenge is the "signal to noise" problem. How many of those asymptomatic transmissions are noise? For example, patient movement may create artifact that may trigger a transmission. The heart does not function as a steady state organ. It is very dynamic and asymptomatic "extra" or "missed" heart beats are fairly common. Many of these events may not be clinically relevant. Also to consider is the limited time a physician has to scan these reports. Perhaps AI can help separate "wheat from the chaff" and save providers time, provide more accurate and clinically relevant data, and improve the overall quality. Increasing the limit beyond 500 may overwhelm clinicians with more data, with the risk that important events may be missed.
Thank you for sharing your perspective from a clinical point of view. These are great points. I wonder to what extent this type of information and insights is available in the early phase of design and development. I think this type of input would be very useful in facilitating the trade offs that is naturally present in the design process. Thanks again!
I appreciate you addressing assumptions and documentation in this article. In either a small business or large, there will be employee turnover that results in lost knowledge and history. Small businesses grow and staff are promoted/move to better opportunities. Large businesses shift priorities and persons change departments. The undocumented rationale for design decisions gets lost during employee turnover in these cases. When new persons picking up the project they are unsure and unwilling to go against what was previously established (regardless of if the rationale is documented). We tend to assume that the last person did the work correctly and that it is important, we just don’t know why.
Suggested methods for documenting assumptions are through memos, meeting minutes, power points, or design tools stored. All of which should be stored in the DHF. It provides a glimpse at what design trade-offs were considered and why a choice was made. It also provides an opportunity for the rest of the team to weigh in and either validate the assumption or propose alternatives. In this manner the assumption will live on, and the team gets awareness to the assumption.
Thank you Ben for your insightful comment and suggestions!