Closed joereddington closed 6 years ago
I've already written a developement project. The next policy to write is on Post Market surveillance. In short - this is "What's your process for gathering information about your device after you've sold it, and what's the process for making changes on the basis of that information.
I'm reading this for background information.
First draft:
This policy is to provide early warning of quality problems within medical software produced by eQuality time and to specify input into corrective and preventive action processes
eQuality Time will collect and process the following sources of information for post market surveillance:
- User complaints
- Unsolicited user feedback (regardless of channel - so social media is included)
- Test results - both within and external to the project
- Literature reviews.
There will be clear instructions for users on how to deliver any feedback. We will also periodically be conducting user survays and other forms of proactive research.
All information received will be reviewed by at least one member of eQuality Time staff. Any concerns, or feature requests will be entered into the project issue tracker and and assessed acording to our continuous improvement policy.
I'm looking at Risk Assessment today. I'm working on this file: risk-assessment-and-policy-template.docx (which is currently very incomplete) and I've identified the following risks:
I've also been reading these case studies which were unhelpful, and these slides which were a little bit more in depth. It's pretty clear that the format of the risk assessment will change. Right now I only need to make sure that I get the full list down and know what actions need to be taken over them.
In order to help find the missing risks, I've asked a few knowledgable people on facebook and I'll come back to them shortly.
@greg-westnine and I have a meeting at 2pm today to go over our progress on this. Will report back...
One minute minutes of meeting with @greg-westnine today:
I'm going to continue working on the risk assessment policy, and Greg will look at the Continuous Integration, and Document Management Policies. With a priority on Document Management. (Rest of the meeting focused on Javascript which is outside the scope of this issue.
Current State of policies is:
Development, Development policy v0-2.docx, Development procedure v0-1.docx
Document Management, (In preparation)
Risk Management, risk-assessment-and-policy-template.docx - at the moment this is a very broad collection of possible risks - one of the topics of today's meeting was putting it into a shape that is correct for medical device registration.
Continuous Improvement (In preparation)
Post Market Surveillance ( PMS policy.docx
(I should be very clear - these are polices that are being developed and are definitely not binding yet - they will need a lot of work, and then approval by the Trustees before they become official.
Okay, I have redrafted the Risk assessment (but not the policy) risk-assessment-and-policy-template.docx.
Part of the redrafting has involved me doing some serious thinking about what it should look like, and I'm much happier with the risks we have down at the moment.
I did some more work on risk policy (different to the assessment) and came up with this :
Risk Management Policy
As part of managing the health and safety our projects and organisation, we must control the risks in and in some cases outside, the workplace. We must also thoroughly assess any risks involved in our projects. To do this we need to think about what might cause harm to people and decide whether we are taking reasonable steps to prevent that harm. We are required by law to carry out a risk assessment.
It is our policy that:
Staff (including volunteers and contractors) have responsibility for ensuring their working space is safe when working from home. Risk assessments consider wider issues than physical harm; in particular it is worth considering risks around release of privileged information, or emotional pressure (for example, our book camps can involve the exploration of difficult issues). . When completing a risk assessment for an activity it should be sent to X, and it should include a date for review. Completed risk assessments should be displayed publically where practical.
Next action is to put that in a proper format and send it out.
I did a little research on risk management and found this helpful (once you get past the pop-ups). It makes the valid point that you cannot reasonably conduct a risk assessment for a medical device until you know the scope and intended purpose of the that device. Possibly there is some tension here between defining a generic risk management policy for all types of risks (like safety at work) and risks that relate to being the manufacturer of a medical device.
Working on this now. Reviewing the Document Management Policy (arrived by different channel)
Okay, so let me think about this from my point of view.
I've made a range of edits, updated the version number and uploaded here: Document Management Policy v0-2.docx. Most of my edits are for the purpose of simplifying, some are to remove the policy from procedure, but they are all relatively minor. I've also attempted to make the policy self-demonstrating, because we may as well have a worked example.
Whatsapp - Meeting with @greg-westnine - he's going to review the DMP policy and he's about a third of the way throught the CI policy. We've got a tentative deadline to have a pack of policies I can send to trustees on Mondy, (Ideally if Document Management one arrives early we'll send it early).
Here is the first draft CI policy. Continuous Improvement procedure v0-1.docx
Excellent. Will review once I've taken a swing at the risk assesment.
I've rewritten the risk policy to include some scope aspects. OVF risk assessment v0.1.docx
Looking at the CI policy. Did some very quick 'house style' formatting before switching track changes on...
Some minor rewordings, but otherwise totally fine.
OVF risk assessment v0.1.docx
Okay let's look at next actions on this - I think I have to go through the Developement policy again, and @greg-westnine is revising the DM policy, but otherwise I think we're looking good to send policies to trustees on Monday, and possibly before.
Starting to look at the Development policy again.
The process for today is:
Find the file.
Editing in libre office due to my own silliness, before I covert it back to word I should remember to:
I have made some updates to the Dev Policy since it was last linked from here. There is also 1 missing section (on Problem Resolution). We may need to merge 2 versions now. I have also done some updates to the Dev Procedure and written a separate doc to describe how we implement the policy. Will upload all 3 in a short while.
Ah - okay,
So this is as far as I got with Libre office. Development.policy.v0-3.docx, which was quite fun. When you (greg) upload a new version, I'll merge them together, a lot of the edits I made were thinking aloud so it's likely to be pretty easy, but I'll work on something else until then. :)
(Possibly worth adding something to the DM policy to consider the simultaneous editing problem 🤣)
Current status of development docs: Development policy v0-3.docx
Development.procedure.v0-2.docx
Implementing Dev Policy in Github.docx
For me the problem of simultaneous editing is due to where we store documents. There needs to be a better way than linking them to comments.
Reviewing document. Here now.
Quite a few edits and comments - I've tried to simplify were possible - let me know if you think I've over-simplified for MHRA purposes.
I'll have a quick read through of the other documents now.
And indeed I had a quick look - they look fine to me - unsure if they should be controlled doucments - certainly I'd like to get the other ones through first.
Reviewing the issue overall - @greg-westnine did you get a chance to double check the changes I made to DM policy?
(my next action is to go and get the other policy from the other laptop)
Generally accepted your changes to CI. Couple of other typos and 1 question. Continuous.Improvement.Policy.v0-2.docx
Some accepted changes but also various comments. Development.policy.v0-4.docx
Hope to finish this today, reviewing docs now.
Reviewed, I aggree with a bunch of the comments and have put some back, made some decisions about the rest, and have a small set to talk to you about, but I think we can send it to trustees with those unresolved.
Development.policy.v0-5.docx
CI also great. Continuous.Improvement.Policy.v0-3.docx
Dear all,
As you know we're working to register the Open Voice Factory as a medical device. Part of the process is showing that we have some polices in place for compliance. Our contractor and I have spend some time developing these and would like your Approval to make them official.
There are five policies in all, you can find them here and all comments are welcome - you can see that in some places I've left both my and our contractors point of view in the word document do you can weigh in if you like.
Ideally we'd start with the Document Management Policy, and I appreciate that relatively few of you will want to get into the details of the development policy.
Okay, I'll send that sortly.
Okay, I've sent the link to the policies to the trustees, there should be comments soon.
In the meantime, next time @greg-westnine and I chat we'll go through all the outstanding comments.
The only other thing for me to do is to make a list of controlled documents somewhere. That should be private (because it might include allegations of abuse) so I'll create it in the Trustee-only but of dropbox).
These have been sent to trustees and no problems have arisen yet.
@greg-westnine and I will talk about some changes to the documents on Monday, and I've got some actions (above) in the meantime.
Following a meeting today I've created two new issues to replace this one: https://github.com/eQualityTime/TheOpenVoiceFactory/issues/73 is for the next stage of the process, and https://github.com/eQualityTime/TheOpenVoiceFactory/issues/72 is for the actions I should be doing to implement the polciies.
Otherwise I'm waiting for Trustee feedback on the issues (which Greg and I will then go over.
Had call with @greg-westnine and went over the developer policy - we're inaggreement about Development.policy.v0-6.docx
@willwade could I ask you a favour? I'm a bit unsure about the risk assessment and could do with someone to look over it and see if I've missed anything...
Updated the risk assessment today
As part of our Open Voice Factory project we are putting in place particular policies that are needed for medical device registration.
Our consulting developer (@greg-westnine) has recommended the following five policies (based on his experience, this isn’t a standard set):
And we have drafted these five polices to go to Trustee approval.
Plan
Resources