Design Input - DHF

[nehalmahajan55]

I have prepared a design input for a medical device which we are currently working on. But I am not sure if i am getting this right. I have attached it below hoping if someone could see it and guide me for any necessary changes

Design Input ID	Source	Description	Rationale	Acceptance Criteria	Relevant Stantards/Regulations
DI-001	User Need Requirements	The need for a portable ECG monitoring device for remote monitoring of cardiac activity	To address the increasing demand for convenient and accessible cardiac monitoring solutions, especially for patients with cardiac conditions or at risk of arrhythmias	The device must be portable, lightweight, and easy to use. It should provide accurate ECG measurements and support wireless data transmission for remote monitoring.	FDA 510(k) requirements, ISO 13485
DI-002	Regulatory Standards	Compliance with FDA regulations for medical devices and wireless communication standards	To ensure the device meets regulatory requirements for safety, performance, and interoperability.	The device must comply with FDA guidelines for Class II medical devices and Medical Device Directive and In Vitro Diagnostic Medical Devices Directive in the European Union, where it is classified as a Class IIb medical device, including validation of wireless communication security and performance. It should also adhere to relevant wireless communication standards such as Bluetooth Low Energy (BLE).	FDA 21 CFR Part 820, IEC 62304, ISO 14971, Bluetooth SIG standards
DI-003	Clinical Requirements	Accurate detection of arrhythmias and abnormal ECG patterns	To enable early detection and diagnosis of cardiac abnormalities, including arrhythmias, to facilitate timely medical intervention.	The device must have high sensitivity and specificity in detecting arrhythmia
DI-004	Technology Capabilities	Wireless signal transmission capabilities and integration with mobile applications for AI-based analysis.	To enable remote monitoring and analysis of ECG data using mobile devices equipped with AI algorithms.	The device must support wireless communication protocols such as Bluetooth or Wi-Fi for seamless data transmission to mobile applications. It should be compatible with iOS and Android platforms and allow integration with AI algorithms for real-time arrhythmia detection and analysis.
DI-005	Battery Life	Long battery life to support continuous monitoring and extended useage	To ensure uninterrupted monitoring and usability without frequent recharging.	The device should have a battery life of at least ?? hours under typical usage conditions. It should also provide low-battery alerts to users.
DI-006	Data Security and Privacy	Secure storage and transmission of patient data to protect confidentiality and comply with privacy regulations.	To safeguard sensitive patient information and maintain compliance with data protection laws.	The device must implement encryption algorithms and secure data transfer protocols to protect patient data during transmission. It should comply with HIPAA regulations and other applicable privacy laws.	HIPAA

 

[Tidge]

Design inputs need to be testable. The word "should" is a red flag.

 

[yodon]

As "user needs" those are ok. You can't exactly verify them, though. You would want to establish "engineering's answers" to those user needs (we call them system requirements) which provides verifiable requirements; e.g., exactly what your physical aspects (size, weight) are, what your sensitivity and specificity targets are. Coming in somewhat parallel to user needs are risk controls. If you have software, you'll also need specific software requirements (and software risk analysis with controls).

 

[nehalmahajan55]

As "user needs" those are ok. You can't exactly verify them, though. You would want to establish "engineering's answers" to those user needs (we call them system requirements) which provides verifiable requirements; e.g., exactly what your physical aspects (size, weight) are, what your sensitivity and specificity targets are. Coming in somewhat parallel to user needs are risk controls. If you have software, you'll also need specific software requirements (and software risk analysis with controls).

As being new to this role I am still not getting what is to written, do you have any idea where I could get a sample format to review or any other detailed information source.

 

[austin_howell]

Hi there, this is a topic I am pretty passionate about and have written up some different blog posts on this topic that might be helpful. Unfortunately, I haven't reached the lovely 10 posts count to post links...

Like others have mentioned you first needs to define your User Needs and then define Requirements separately. User Needs are atomic and tightly related to the intended use of the device, what you have shown above is a good starting point for that. Then you will have a decomposition of those User Needs into objectively verifiable Requirements. For example DI-004 "Wireless transmission capabilities...", this need should be decomposed into several engineering Requirements that might be things like "The product shall provide a Bluetooth (BLE) v5.3 wireless connection." There is a standard for that version of BLE and you can objectively test against that standard. Another example DI-005 "Long battery life...", from the perspective of the engineer what does "long battery life" mean? You would decompose that into several requirements around the battery with at least stating something like "The battery shall support 480 minutes of continuous operation and 960 minutes of stand by operation.".

Hope this helps!

 

[austin_howell]

Nehalmahajan55, I want to bring this back to forum as I hope that is can help someone in the future.

You asked me if I have anything specific to "Design Inputs" and I personally have a different perspective on that terms than I think most in the med-device space. I think of Design Inputs as a larger category that encompasses User Needs, Requirements, Risks, Standards, and anything that is an input to the design.

 

[austin_howell]

What are Medical Device User Needs -> What are Medical Device User Needs?
Needs vs. Requirements -> Deep Dive: Needs vs. Requirements
Basics of Writing Requirements -> Basics of Writing Requirements


I think what you have to start is well, a start. I would argue, and I think most would agree, that you need User Needs and Requirements. A User Need (UN) is tightly related to the Intended Use of the product and should describe the need or challenge in qualitative language. For example, "The User Needs to be able to deliver 3cc of solution to the patient's eye." This as a need can be decomposed into different Requirements for the product such as; "The product shall contain a minimum of 5cc's of solution." and there might be a rationale is to why you need more than 3cc's of solution in the product. I would argue typically each UN has multiple or many Requirements that are created as a result of it, but you should only have a handful of true User Needs.


Having both the UN's and the Requirements together in matrix is usually the typical tool people will use to show this decomposition. That said there are tools out there like Innoslate, Polarion, Jama, and DOORS that help you manage this traceability, but they are all pretty expensive except from maybe Innoslate. Having this traceability matrix will also help you tie in the risk items as well as you begin with that process.

 

[nehalmahajan55]

I think what you have to start is well, a start. I would argue, and I think most would agree, that you need User Needs and Requirements. A User Need (UN) is tightly related to the Intended Use of the product and should describe the need or challenge in qualitative language. For example, "The User Needs to be able to deliver 3cc of solution to the patient's eye." This as a need can be decomposed into different Requirements for the product such as; "The product shall contain a minimum of 5cc's of solution." and there might be a rationale is to why you need more than 3cc's of solution in the product. I would argue typically each UN has multiple or many Requirements that are created as a result of it, but you should only have a handful of true User Needs.

Thank you so much for taking time and replying to me
What do you think of this

User need: UN-1 Wireless Data Transmission
User requirement: REQ-1 The device shall be able to transmit data wirelessly
Design Input: DI-1 The device shall incorporate Bluetooth Low Energy (BLE) 5.0 technology for wireless data transmission

Do you think if this make the traceability between Design Input and User Requirements and now I am going in the right direction for writing design inputs

 

[EmiliaBedelia]

As mentioned above, "design input" can mean any inputs that you are designing your device around. The specific nomenclature doesn't really matter as long as you are taking user needs and decomposing them into detailed engineering requirements which you can verify through testing. You don't need a line item named "design input" as long as you have your needs and requirements defined appropriately.

User need: UN-1 Wireless Data Transmission
User requirement: REQ-1 The device shall be able to transmit data wirelessly
Design Input: DI-1 The device shall incorporate Bluetooth Low Energy (BLE) 5.0 technology for wireless data transmission

IMO, you don't need 3 separate lines here. In this example I would remove "Wireless Data Transmission" and rename the other 2 lines.
Thus your Design Inputs would read as follows:

User Need: The device shall be able to transmit data wirelessly.
Requirement: The device shall incorporate Bluetooth Low Energy (BLE) 5.0 technology for wireless data transmission.

As a regulatory person, I would recommend that you consider carefully how you reference standards and regulations. It can be difficult to complete the design and verification if the requirement is something like, "Device shall comply with EU MDR requirements". My suggestion is to review the standards and incorporate any requirements as a clear design specification as much as you can. For example, if the performance standard for your device gives an accuracy requirement of +/- 10%, I would state the design input as: "Device accuracy shall be no greater than +/- 10% per ISO 12345".