Medical Device supplemented with a Mobile Application

E

elmagnifico

Hi all,

I am a UX designer in a consultant company that develops an app which works together with a medical device. The medical device saves the same data after usage and send this information to the mobile device thanks to the Bluetooth service. The mobile device is being developed by another consultant company by the way.

Now, I am writing the specification and other documentation for the mobile app according to the 62366 standard. Are we doing the right thing? Or should there be just one documentation including both the medical device and the mobile app?

If we do it separately for the mobile app, what methods can we use for the verification and validation?

I am really confused now. Some input would be very helpful to ask better questions.

Cheers...
 
M

maaquilino

Re: What if a medical device is supplemented with a mobile application

There?s no set way to do documentation; in my experience, some projects do requirements for each component separately, while others put everything into one document (most design documentation has been done separately rather than all in one document). Many times, it was the size and complexity of the system being built that determined whether requirements went in one document or several. It?s the information that?s captured that?s important, not how many documents it?s captured in. One of the most important things to ensure is traceability, so based on how the documents are structured and how many of them there are, that may make traceability easier, or harder, to document. In every FDA audit I've been involved with, the first document they asked for was the traceability matrix, and if that had mistakes, the FDA settled in and dug down even deeper.

The current project I?m on is also a medical device with a mobile app. The device itself is being developed by the manufacturing company, while the app is being designed by a consultant firm. We put all the requirements for the device, mobile app, communications, etc., in one Requirements Specification document; the device and mobile app have separate Design Specs. The verification (unit testing) is done for each device/mobile app by the developer of that component, with integration testing done on site with both device and mobile app development groups participating. The validation (OQ and PQ) of the device and mobile app is being done by the manufacturing company.

Any documentation around the mobile app should also be compliant with whatever other appropriate standards apply to the medical device. For example, the project I?m on falls under the FDA?s CFR 820, and the mobile app is integral to the use of the device, so the medical app also has to be compliant with that. I used the FDA guidance below for this, along with IEC 62366.

http://www.fda.gov/downloads/medica...onandguidance/guidancedocuments/ucm263366.pdf
 

Attachments

  • Mobile Medical Applications MMA-1741.pdf
    269.4 KB · Views: 164
Last edited by a moderator:
E

elmagnifico

Re: What if a medical device is supplemented with a mobile application

Hi Maaquilino,

Thank you very much for the information already. I am really glad I have found someone with the experience on something that i need badly. I would like to describe my situation better to get some more help from you and the others if possible;

My company and our client didn't have experience in this field before. When they gave me the task I was responsible for the visual design of the app but then it turned into something bigger that includes all these standards. We had a tight schedule and I already delivered the design to the front-end developers. Unfortunately, I am trying to create the necessary documents related to the standards now which I realized that it was wrong after reading many articles on the net. At the same time, reading too much confused me more because they say different things and they write specifications in different styles. That's why, I ended up here to get some recommendations.

Our app is under this category "Mobile Apps for which FDA intends to exercise enforcement discretion (meaning that FDA does not intend to enforce requirements under the FD&C Act)"

Right now, I am trying to create a document which is a copy of two documents. First one is;

Usability-specification-document-template.doc (attached)

Second one is;
"IEC 62366 Medical devices ? Application of usability engineering to medical devices" provides under the title "Usability Engineering Process" (I call it reverse usability engineering now :) )


This is the steps of the usability engineering process according to IEC 62366 which I try to follow;

(attached picture)

Difficulties I have right now with that document;

- Defining frequently used functions

We have some functions which were already placed on the main menu. One of them is settings which has menu options for the user to enter data. Apparently, they are not frequently used functions but i don't see another place in the document to mention about the specifications related to these settings. Where should I put them?

Usability Specification

- According to the standards again, usability specifications should be testable for the verification step. Does it mean that every specification should include numbers such as "confirm button should be bigger than 200x600px"? If so what will be my reference for such specification? Do I have to find anatomic/cognitive reference for each design elements?

- If I say "Confirm button should be blue", is that a specification? or should it be "confirm button should have rgb values of 0, 0, 40"
This specification can't be there before designing.Then, should i have another section apart from "usability specification" in the document which mentions about all the design details such as "confirm" word should be written with Calibri font?

Usability Validation Plan

-What kind of plan it should be? I have no clue.

User Interface Design and Implementation

-What should i put here?
-Should I mention about the functions? Or should I explain every screen one by one with screenshots?
-What about the implementation? Is it related with coding of the app? What should we have there?

Usability Verification

- Is there a common method to perform? What will be the focus during the verification? Could you give me an example?
- Is this about the functions such as "USER rates the treatment by giving selecting stars 1 to 5"? When I want to verify this what will I do? Will I use the finalized app on an iphone to rate? They what will be the result? It is tested and the user is able to rate between 1 and 5. We will promote the app for both iphone and android platforms? Should we verify all these functions on all possible iphone and android devices?

Usability Validation

Is there a common method? We already did a user test during the design to see if the icons or titles on the menu are understandable? Should we do something similar again with a real phone this time? Should we do it for all the possible functions inside the app?

I am sorry that I asked too much. I will be appreciate if you answer as much as you want. If you know any similar documentation related to the medical apps I would appreciate double.
 

Attachments

  • usability-specification-document-template.doc
    116 KB · Views: 420
  • usability.jpg
    usability.jpg
    50.8 KB · Views: 364
M

maaquilino

Re: What if a medical device is supplemented with a mobile application

Most of my medical device experience has been using the FDA, European and Chinese standards, along with ISO and IEC. I don’t do a separate document for usability; much of the information in the document you provided I have in my requirements documents and risk analysis. I have several documents - The User Requirements Specification (URS or FS) outlines the functions the customer wants; these are high-level requirements. The Software Requirements Specification (SRS) takes these requirements and details them out; this gives much more information about each function and also lets the software developer know what they need to develop. So if the customer wants specific fields on specific screens, or wants buttons to be a certain color, those details go in the SRS. Anything that defines what a function should do, where it goes, or what it looks like, I have in the SRS. And every requirement in the SRS must be testable. I don’t test that something is x pixels in size – unless a specific requirement in the SRS states it has to be. Usually those types of things aren’t in the SRS as users generally don’t care what size a button is. The only time I’ve seen something similar in an SRS is when there’s a business reason something has to be a particular shape or size.

Many people have different definitions for the terms verification and validation. How I’ve used it, and seen it used, for 25+ years is that verification is done during unit testing by the developer; they’re testing that what they coded works as they coded it. And that doesn’t always translate to meeting the requirements in the SRS ;) They also do integration testing to ensure the entire system works as developed.

Validation contains OQ and PQ testing; OQ testing is testing to each of the requirements of the SRS; this ensures that the requirements were met. So each SRS requirement will have one or several tests for it. When I did OQ testing, I also always looked for whether or not the system flow was smooth, if the system was user friendly, if buttons and fields were in the right – or common sense – places, if the system was intuitive, etc. OQ testing is done independently of development and is usually done on a test system in a test environment. PQ testing is testing done by the users and is done to the URS or FS requirements. This testing is done using pre-defined tests based on the User Manual, Procedures, or Work Instructions that user will follow once the system is manufactured and put into the live environment for use. PQ testing is done in a test environment on the actual system that will be used for going into the production system manufacturing product. In other words, if you’re developing a medical device that includes a software system, PQ testing will take place on the actual system hardware and software that development believes will be made in production. PQ tells you whether the users are satisfied the system met their expectations; it covers process flow, user friendliness, if the instructions for use are correct, if the user is trained well to the instructions. It also tells you whether or not the entire system works as an integrated unit and is ready for production and the Process Validation.
 
E

elmagnifico

Re: What if a medical device is supplemented with a mobile application

Thanks for the answer again! I was trying the minimalize the tasks according to examples inside 62366 but I have learned new tasks to add from you. I wonder if you could judge one of my specification and exemplify these tasks accordingly?

One of the primary operating function and the requirements related to it listed below ;

Logging in to the mobile application
-USER have a master pin code
-Pin code should consist four numerical character
-USER should see how many characters being entered
-The numbers entered are replaced by circles and remains hidden
-If the pin code is right, USER should reach to the main menu
-If the pin code is wrong, USER will see an option to receive a new pin code by email

Is this a good way to list requirements? Is there a better way or some standards?
Now if I want to write a validation plan for these requirements what should be the format?
How can we verify these requirements? in which format we should verbalize it?
How can we verify these requirements? in which format we should verbalize it?

- How much time is required for whole documentation? Right now, our front-end developers are building the app and I am trying to prepare these documents according to the 62366 standards? Can I create (or find a proper template) a validation plan/verification/validation template now to apply later?
- Is there any difference between validation plan and the validation itself? Or will we just perform validation tasks according to the validation plan? If so, why the validation plan comes before "user interface design and implementation" in the guideline part of 62366?

Do you think I may find a complete medical device app example including whole documentation? Are they secret documents like patterns or free to share after the launch?
 
Top Bottom