User Interface of Unknown Provenance (UOUP) applicability

#1
Looking to understand timing of when UOUP actually applies. This is my understanding of the timing of events.

IEC62366-1:2007 released- initial version
IEC62366-1:2007 Am1 released in 2014- includes UOUP
IEC62366-1:2015- updated for clarity

Can you confirm the timing of these events is correct. If correct does this imply that UOUP applies to any product development before the release of amendment # 1 in 2014. Also when a standard is released what is the time frame that companies have for compliance? e.g. do we have 3 years from release of standard or is it in effect immediately.
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
It's my understanding (and that's not to say it's right) that, irrespective of the releases of the standards, if you didn't develop a UI in accordance with the standard (and gather the applicable records), you can adopt the standard moving forward, as you modify the UI.

The 3rd paragraph in Annex C seems to support this:

The PROCESS of this annex can be applied to UOUP for A USER INTERFACE or part of a USER INTERFACE for which adequate RECORDS of the development using the USABILITY ENGINEERING PROCESS of IEC 62366-1:— are not available. However, if any modifications are made to the USER INTERFACE or its parts, only the unchanged parts of the USER INTERFACE remain UOUP and the changed parts of the USER INTERFACE are subject to 5.1 to 5.8.

So, essentially, do the gap analysis and begin applying the standard for changes moving forward.
 

Tobias_HF

Starting to get Involved
#3
I always thought that the Annex C (formerly known as Annex K) is for medical devices that were brought to market before 2007.
Since 2007 there is the original standard. So everything released after that should follow the 2007 version. Then there was a lot of confusion about legacy devices, so the Annex K amendment described what to do with existing products (2014), that are on the market and did not follow the 2007 standard. I assume because they were on the market before 2007.
The Annex C (2015) describes this in a bit more detail.

In my understanding the critical date is 2007 - but I know that NB also think of 2014 as the relevant date. So when you developed between 2007 to 2014, you basically could just evade the standard - which I think is a bad thing to do.

Cheers
Tobias
 

yodon

Staff member
Super Moderator
#4
It's quite possible that the product was developed for a market that didn't 'require' compliance to 62366 and the UI was developed outside the UE process. They then decided that they wanted to enter a market where 62366 was recognized as a way to meet applicable regulatory requirements.

It's also quite possible that they got market clearance without demonstrating compliance and now it's more of a focus. Dates of when things did / didn't happen are mostly irrelevant.
 

lisasolo

Starting to get Involved
#5
It's my understanding (and that's not to say it's right) that, irrespective of the releases of the standards, if you didn't develop a UI in accordance with the standard (and gather the applicable records), you can adopt the standard moving forward, as you modify the UI.

The 3rd paragraph in Annex C seems to support this:

The PROCESS of this annex can be applied to UOUP for A USER INTERFACE or part of a USER INTERFACE for which adequate RECORDS of the development using the USABILITY ENGINEERING PROCESS of IEC 62366-1:— are not available. However, if any modifications are made to the USER INTERFACE or its parts, only the unchanged parts of the USER INTERFACE remain UOUP and the changed parts of the USER INTERFACE are subject to 5.1 to 5.8.

So, essentially, do the gap analysis and begin applying the standard for changes moving forward.
I would like to interpret this paragraph in this way as well- that Annex C can be used even if the product was commercialized after the date of publication, if you do not have adequate records of the IEC 62366-1 usability engineering process.

We have not yet implemented the usability engineering process detailed in IEC 62366:2015. So we have products commercialized after its publication date, but still it is too late to integrate the processes in the design and development of these products. Is the general consensus that Annex C would still be appropriate to use? Or could we be required to follow sections 5.1-5.9 retroactively?
 

Ronen E

Problem Solver
Staff member
Moderator
#6
I would like to interpret this paragraph in this way as well- that Annex C can be used even if the product was commercialized after the date of publication, if you do not have adequate records of the IEC 62366-1 usability engineering process.

We have not yet implemented the usability engineering process detailed in IEC 62366:2015. So we have products commercialized after its publication date, but still it is too late to integrate the processes in the design and development of these products. Is the general consensus that Annex C would still be appropriate to use? Or could we be required to follow sections 5.1-5.9 retroactively?
I think you don't have a choice. Otherwise the standard would have been written such that there are two paths, of equal standing and presentation, to choose from. This is quite clearly not the case. Annex C looks more like a back door or an emergency exit.

Having an already existing design is not an impenetrable barrier to a full implementation of ss. 5.1-5.9. I would begin with a gap analysis and prepare a preliminary, hi-level work plan. If the conclusion is that some elements can't be implemented because the D&D process "is over", you can initiate a design change (mini?) project, aimed at creating a UI (actually a device) compliant with IEC 62366-1:2015. A part of this project would be the implementation of ss. 5.1-5.9.

WRT dates - IEC 62366-1:2015's UOUP provision specifically talks of IEC 62366-1. Prior to the 2015 version there were no -1 & -2 parts, so in my understanding Annex C should be read to apply from the release date of the 2015 version, i.e. Feb. 2015. Compliance with previous versions is quite irrelevant IMO, because they're now superseded (and anyway, apparently the furthest one can take the UOUP provision is the 2014 amendment - not a great extension in terms of issue date). IMO if one wants to declare compliance with the 2015 version through the UOUP path, one must address the requirements and definitions in that version. Standard compliance is not intended to be a mix-and-match exercise.
 

lisasolo

Starting to get Involved
#7
I think you don't have a choice. Otherwise the standard would have been written such that there are two paths, of equal standing and presentation, to choose from. This is quite clearly not the case. Annex C looks more like a back door or an emergency exit.

Having an already existing design is not an impenetrable barrier to a full implementation of ss. 5.1-5.9. I would begin with a gap analysis and prepare a preliminary, hi-level work plan. If the conclusion is that some elements can't be implemented because the D&D process "is over", you can initiate a design change (mini?) project, aimed at creating a UI (actually a device) compliant with IEC 62366-1:2015. A part of this project would be the implementation of ss. 5.1-5.9.

WRT dates - IEC 62366-1:2015's UOUP provision specifically talks of IEC 62366-1. Prior to the 2015 version there were no -1 & -2 parts, so in my understanding Annex C should be read to apply from the release date of the 2015 version, i.e. Feb. 2015. Compliance with previous versions is quite irrelevant IMO, because they're now superseded (and anyway, apparently the furthest one can take the UOUP provision is the 2014 amendment - not a great extension in terms of issue date). IMO if one wants to declare compliance with the 2015 version through the UOUP path, one must address the requirements and definitions in that version. Standard compliance is not intended to be a mix-and-match exercise.
Hm ok so you think that this section of Annex C isn't applicable to my situation?:

"The PROCESS of this annex can be applied to UOUP for A USER INTERFACE or part of a USER INTERFACE for which adequate RECORDS of the development using the USABILITY ENGINEERING PROCESS of IEC 62366-1:— are not available. However, if any modifications are made to the USER INTERFACE or its parts, only the unchanged parts of the USER INTERFACE remain UOUP and the changed parts of the USER INTERFACE are subject to 5.1 to 5.8."

Any changes or new products from here on out would use follow 5.1-5.9, but this paragraph implies to me that I could use the Annex C process for our existing products. Our products were commercialized in mid-2015-2016, so a design change project at this point does not seem reasonable.
 

Ronen E

Problem Solver
Staff member
Moderator
#8
Annex C is a very much watered down version of the standard's usability engineering process. If it is available to anyone who comes aboard and decides to implement the standard at any point in time, on any device, why would anyone bother going through ss. 5.1-5.9? Why not develop a device without addressing usability at all, and then, once the design is released to the market, conveniently apply Annex C alone? If that was the standard's intention, ss. 5.1-5.9 could have been put in an Informative annex (read: made into guidance for those who want to go above and beyond) rather than being the standard's high road. But they weren't.
 
Thread starter Similar threads Forum Replies Date
A User interface Language Requirements - EU MDR EU Medical Device Regulations 1
D Software User Interface Languages for LVD and IVD CE Marking (Conformité Européene) / CB Scheme 2
A Cassette Representation - GUI (Graphical User Interface) on my medical device - A mammography Device Other Medical Device Related Standards 0
R Medical device software without user interface Other Medical Device and Orthopedic Related Topics 3
Ed Panek Splitting UI (User Interface) into two development paths 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
A Software Medical Devices without User Interface EU Medical Device Regulations 5
S Class I Medical Device GUI (Graphic User Interface) EU Translation Requirements EU Medical Device Regulations 2
thisby_ Medical Device Software - User Interface Language - 93/42 CE ISO 13485:2016 - Medical Device Quality Management Systems 15
W User Interface Label language Requirements ISO 13485:2016 - Medical Device Quality Management Systems 12
T Documenting hazardous situations associated with user/patient population ISO 14971 - Medical Device Risk Management 3
A The refund of 510(k) user fee Medical Device and FDA Regulations and Standards News 0
S User evaluation for self monitoring blood glucose test systems US Food and Drug Administration (FDA) 4
P Equipment 21 CFR 820.70(g) - User Requirements Document for Off the shelf equipment 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 7
S Forced ServiceNow validation - No change in our current user and functional requirements IT (Information Technology) Service Management 6
Q User Requirement Specification for HR (Human Resource Management System) Manufacturing and Related Processes 1
P Electrosurgical Device User Need: Cord Flexibility -> Requirement Other Medical Device and Orthopedic Related Topics 4
S Recommendation for user friendly Gaga R&R and Cpk software Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 10
B ISO 11607-1 for surgical instruments sterilized by end user Other Medical Device Related Standards 1
M User manual / instructions for use for class II device always required? Medical Device and FDA Regulations and Standards News 3
D Do User Manuals (Not Device Labeling) HAVE to be in their national languages for these countries? Will English Hardcopy not do? EU Medical Device Regulations 12
F EUDAMED UDI Medical Devices User's Guide Medical Device and FDA Regulations and Standards News 6
M Informational US FDA Medical Device User Fee Rates for Fiscal Year 2020 Medical Device and FDA Regulations and Standards News 0
K EU MDR Art. 22 - Device + insertion pack - User manual and Labeling EU Medical Device Regulations 4
G Posting Measuring Equipment Accuracy for User Information General Measurement Device and Calibration Topics 4
M Does ISO 13485 or MDR require you to state the origins of customer requirements or user needs? Design and Development of Products and Processes 2
V Sequence of performing risk assessment: User_FMEA (User Errors) vs Design Inputs FMEA and Control Plans 1
R Publication of user information in manufacturer website for medical devices Other Medical Device Regulations World-Wide 2
Ed Panek User Feedback both negative and positive and acting upon those metrics 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
P Detection rating for a user (surgeon) related failure mode in DFMEA APQP and PPAP 3
Marc Search - Search for Discussion Threads started by a specific User Elsmar Xenforo Forum Software Instructions and Help 0
Marc Search for Posts - By specific User Name(s) Elsmar Xenforo Forum Software Instructions and Help 1
M Digital user manuals CE Marking (Conformité Européene) / CB Scheme 0
Marc User Agents of Forum Visitors - 6 November 2018 Forum News and General Information 0
Marc User Post Counts - 20181101 Elsmar Cove Forum Suggestions, Complaints, Problems and Bug Reports 0
Marc Forum User Name - I Want to Change my Forum User Name Elsmar Xenforo Forum Software Instructions and Help 0
Marc 9 September 2018 - Upcoming User Group Changes Forum News and General Information 1
shrutisancheti EU User manual / operator manual / service manual guidance document(s) CE Marking (Conformité Européene) / CB Scheme 2
D How to deal with user needs when it is obvious the design meets the user need 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
shrutisancheti Upgrading medical device at healthcare establishments (user facility) 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
D Definition User Needs - Concrete definition for "User Needs" as required by the FDA Definitions, Acronyms, Abbreviations and Interpretations Listed Alphabetically 2
M User Errors and Product Nonconformances Nonconformance and Corrective Action 22
G Design and development of user centric audit report visualisation tool Design and Development of Products and Processes 5
T New to WEEE Directive - Selling a medical device directly to a professional end-user RoHS, REACH, ELV, IMDS and Restricted Substances 1
Ajit Basrur Looking for examples of "User Training" - ISO 13485 section 7.2.1 d) ISO 13485:2016 - Medical Device Quality Management Systems 6
J TOPCON PP-70 Optical Comparator - User Manual Needed General Measurement Device and Calibration Topics 0
P Datron/Wavetek 4808 Option 70 Wideband Source - User and Service Manuals needed General Measurement Device and Calibration Topics 2
J Who is the Customer - Who is the End User Manufacturing and Related Processes 2
S Trying to understand 7.2.1(d) of ISO 13485 - Medical Device User Training ISO 13485:2016 - Medical Device Quality Management Systems 8
JoCam User Manual Release before CE Mark EU Medical Device Regulations 5
D User Requirements Tracing - Verification and Validation Requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1

Similar threads

Top Bottom