Chat for Compliance – a hacker’s view!
This week we bring you a real-life experience example about how the
qmsWrapper built-in chat
function can turn the compliance documenting process into an easily manageable one.
The ongoing quest for compliance can sometimes be challenging when the needs are not always clear. For example, developing new software is straightforward, customer needs or use cases, requirements, specification, test cases, validation testing… to name just a few. Assign resources, go!
Sometimes, however, the needs are rather technical and uncertain so trying to define the project for compliance is hard. How can a small team proceed when they are doing research or hacker type work?
The prevalence of the Off-The-Shelf (OTS) software is a reality of today’s life, and although medical devices usually don’t include hacks, when it comes to firmware it’s not uncommon that changes, hacks, are required to support the intended use.
So how to hack OTS firmware code, and still remain within the scope of compliance?
The question itself is tricky enough and here is a first-hand experience example where chat software was used as a functional starting point for establishing compliance in a hack software project!
A Real-Life Example
The opening scene:
Three developer guys are arguing with each other. The problem is that they need to add functionality to some firmware, that does not support that functionality. They didn’t write the firmware, it was provided by the manufacturer of the hardware they intend to use. So, they don’t even know where to start. The source code is “open” but…as usual, it’s really a big unknown…
What makes these guys special is that they are part of a medical device company and their latest device is trying to use a particular processor. Luckily for them, their company uses qmsWrapper.
The typical developer conversation starts with an everyday situation that can happen to all of us, compliance demands documentation, to show what development work was done:
- “You write the requirements doc !” -says the first.
- “Why would I? I don’t understand this stuff! I wouldn’t even know where to start!” -Says the second.
- “What’s to document?! We just have to hack it - that’s all!” - says the third.
- “We’re not even sure this driver will work, the RTOS does not have a bulk USB driver implemented for that processor. This is not a developer job, it’s more of a hacker job. …And as usual, management will just call it “pure research”, and anyway, in the end, we will be forced to document it all.”
All three heads down: - “Not good...”
Reluctantly they agreed that some form of documentation was needed:
- “Ok, so I’ll do the requirements” - says the first one.
Requirement 1.
Device requires to use USB Bulk to transfer data at up to 12 MB/sec speeds (limitation is isolation), but for a calculated real requirement of 3MB/sec.
Requirement 2.
In Processor USB transfer must use DMA.
Processor usage should remain about 25% in normal transfers.
- “Ok, I’ll do the system specifications” - says the second.
Firmware has to run on a TI Tiva microprocessor, using its inbuilt USB functionality.
Device firmware has to be written for RTOS from Texas Instruments.
- “Oh great!” - says the third – “you leave me to document all the nitty-gritty details. I really hate you guys…”- ofc he already has an escape plan.
And here comes the part where the story takes an innovative turn:
Although #3 is lazy, he’s smart. He decides to use the chat functionality that is part of qmsWrapper to create the perfect Topic forum, to capture the ongoing discussion and development for this particular hack work. He decides to use the Topic as a running development log of events.
He starts by opening a #Topic, then link’s it to the sub-project he called Device Firmware, adds the other two developers, and flags it as a QMS event.
He then starts the conversation.
“Hi, Guys,
I created a new #Topic called #Firmware Hack.
In this #Firmware Hack Topic, we will put all the implementation details related to this driver sub-project.
If you implement something, describe it here and we’ll all see it. At the end of every day, we’ll save all the notes and attach them to the project as meeting minutes. If you need to create specific project tasks, use that feature from the meeting minutes functionality in qmsWrapper.
This should really make our work a lot easier!
Yeah, we can turn our chats into the compliance documentation we need, and thereby save us from having to over document that we’re not sure about how to do yet.
We’ll keep the daily chats as meeting minutes and include action items and follow-up items to schedule any future actions in a meeting for reporting. Don’t worry, it’s all connected to the project.
When we do the meeting minutes, it's important that flag them for both QMS and DHF (Design History File) so the project manager can update that documentation as we figure it out. It will be easy for him to see what we were doing.
Also, I really want you guys to flag any Risk issues during that meeting minute save, and also any IP potential. The legal beagles will love that stuff and they’ll get the meeting minutes every day too, as proof.
I think we’re covered for now. So, how fast can we finish this hack?”
And so, faced with uncertain driver development/hacker task, the guys turned a documentation nightmare into an easily manageable work, by using the integrated chat in qmsWrapper to document for compliance.
In particular, the ability to flag compliance issues, automatically alerted the various players in the organization, about compliance issues without any fuss.
QMS Manager got a QMS notification and can now determine what QMS process to initiate. The Patent lawyer got the IP notification. The Risk Manager got the risk notification. The Documentation manager got the need for DHF changes to be done, with the details all in the meeting minutes.
Simple. Easy. Productive.
Chat for compliance.
There is nothing slack about qmsWrapper, and there is no Social Media hiding in the workplace.
qmsWrapper. It’s for work, it’s for compliance.