Pharmaceutical Quality System Software Design
Posted in Tech
on March 3rd, 2012 by
Stephen DeGrace
Topics:
jQuery,
AJAX,
Web Design,
Django
I don't know much, or anything, about how software for pharmaceutical quality systems is designed, so this is a speculative article about how I think it might be done, and I may not come up with any good answers about how they do it after defining the requirements. So this is just for the mental exercise. By "quality systems," I mean computer systems that replace paper documents in a traditional quality system. So, for example, out of spec investigation reports, inspection reports, nonconformance, deviations and so on. LIMS systems expand this to include absolutely all raw data. All modern computerized quality systems evolved from paper-based systems from before the computer era, and in my view the place to start is to examine the specifications and capabilities of the paper system and see how it can be replicated in a computer-based system. I'm imagining this as if I wanted to get into this business, how would I make the product, although that's not something I seriously intend.
In a paper based system, all raw data is recorded in a laboratory notebook which has been serialized and issued by Quality Assurance, or otherwise in a controlled form. Data from instruments is kept as print outs. Data is never discarded or obscured. So what happens if you make a mistake, say, have a brain fart and copy the wrong weight into the book? The same thing you do on any quality system document: you cross out the error with a single line, so that the original error can still be clearly seen. You write the correct value down as close to the error as you can. And you initial and date and give a reason for the cross out, such as "transcription error."
That simple example gives you the scope of the problem for anything less ambitious than a LIMS (Laboratory Information Management System), which is a similar problem but taking it to a whole new level because it can take paper completely out of the equation, whereas lesser systems can coexist as a sort of hybrid paper/electronic system.
The quality system consists of various "objects," such as documentation, inspections, OOSes, deviations, customer service incidents and nonconformances, each of which can be linked to multiple other objects of various types. Sounds like a job for an ORM and database (e.g., for a web-based system, Django and Postgresql). But then it gets complicated.
One, data must never be destroyed, so the delete function has to be tightly controlled. Just as in theory, anyone could take a match to paper documents, there is always going to be a system administrator who has access to the servers and can literally destroy data, so that has to be protected against on the level of human systems. However, the vast majority of users should have no ability to delete data, and in general, permissions for actions on objects have to be highly granular, divided into groups by job function, and tightly controlled, but configurable to match company policy and change with it if necessary. So far not so bad and still not hard for a good programmer to implement in Django in close cooperation with quality assurance professionals.
In fact, physical security of the records is an area where computer systems have a significant advantage over the paper based systems they replace. A properly programmed system without critical bugs affecting data integrity can make data available in multiple sites, not just one site as with paper data. With a proper system of nightly backups with multiple backup storage locations including off-site, a company can limit its risk of data loss to one day or even less even in the event of a catastrophe such as malicious act by an administrator with high security clearance, or a fire destroying a physical location. It is virtually impossible for a paper system to replicate the convenience and security of a computer system.
Here's where it gets fun. Changes. On paper, when someone makes a change, you get all of the following:
- The original text can be clearly read.
- A person has taken responsibility for the change. You know who did it.
- They dated the change, so you know when the change was performed down to the granularity of the calendar day.
- They had to give a reason for the change, which helps you to figure out what happened a year later say when you are asked by an auditor and everyone has forgotten exactly what happened.
Part of this can be implemented using a Change object which contains metadata about changes. Every time you click "save," you have to give a reason for the change. These objects are then associated with the quality system ID of the object. Your user ID and the timestamp is recorded along with the reason you gave. Django's contenttypes framework which the Comments system uses can be used to solve the problem of a generic information-bearing object that can be associated with any other kind of object.
Measures need to be taken on the level of the UI to minimize the possibility of one person making a change using someone else's account, the equivalent of forging a person's initials on paper, but much more likely to happen in real life because on computer systems, people don't see this kind of thing as a big deal and they have to be taught to view it the same as forgery. Sessions that time out after a period of inactivity and provide a clean interface to reauthenticate and pick up where you left off are essential, and the built-in Django session would need some hefty retrofitting with help from a UI that makes heavy use of Ajax and Javascript to make that happen. In general, for a web-based application, you would want to force the user to use a modern browser with good Javascript engine (forget about supporting older browsers, the company can mandate the browser and version if needed) and take heavy advantage of a Javascript library such as jQuery to provide a rich and convenient user experience and to elegantly handle the timeout and reauthentication problem.
So far so good. You could build this thing in Django with an app for each type of quality system object and some kind of framework that detects the apps, builds a menu for switching between their interfaces and provides other universal parts of the user experience. Another contenttypes type of object could be used to build associations between objects, for example, to connect a deviation to an inspection. You would also freely build in dependencies, for example, an inspection always has a single link to a document that describes how to do the inspection, so this would be implemented directly on the inspection object.
Where the whole thing grinds to a halt is on the audit trail. Basically, that's the part where you can't change anything without documenting what the former value was, and who did it, when and why. The change object associated with each save lets you demand a reason and record the user and time, but it is probably not convenient to have to save on each change to any field, so you can't easily store the former value. But if you let a person make as many changes to the object as they want and save, it becomes very difficult to track changes. One possible solution is to generate a whole new object with the same quality system ID every time you save, and increment a version number. Then you could scroll back through the version numbers to see the history of the object, although changes would not easily be highlighted, and finding all the differences if the user did not provide good notes with their change would be easier said than done.
It occurs to me for at least part of this problem, an ORM is not the best model, rather, you almost want something like the version control systems like Git and SVN that are used for software development. These systems are naturals at audit trail for documents, easily tracking changes and allowing reversion if necessary without ever losing records of changes. However, the part of the quality system are not a library of static documents, but a set of objects with dynamic behaviour and interaction so I think ultimately the ORM is the model to follow and it would be necessary to simply make it work.
I suppose one way to do it would be to connect the pre save signal with a sophisticated function that scans through fields in the object, or perhaps a subset of fields specified in the Model's Meta class, and looks for fields that have changed. Changed fields would have their name, old value and new value recorded with all changes concatenated in a block of raw text in the Change object. You then don't have a reason for each change, though, so you're demanding more from the user in terms of providing an explanation for multiple changes, than you are with the paper system.
The other possibility is to make heavy use of the Ajax and whenever a field which has been previously "touched" is altered, the interface will not allow any more fields to be edited until you save and give a reason. This would have to be enforced at the server level, too, to prevent hacking or bugs from allowing multiple changes through at once. You could still make multiple changes to a field that on paper would require more than one crossout, but the level of granularity would now be much closer to what you want, and any changes made at once likely to be related and done for the same reason.
Ideally, it would also be good to have some kind of message or task or request system which would allow users to send requests to each other links to some object or objects that the user could easily zoom to and start to act on.
As well, one major advantage of building a database of this nature is that you could mine it for data. Ideally, you would want to build in some kind of reporting mechanism, and even better, something that would allow client superusers to define their own reports, or allow reports to be easily commissioned to be developed. Here again the computer system has a major advantage over the paper system, which can only be data mined arduously.
Overall this project seems doable, but in terms of achieving the same level of compliance that humble paper can provide, the problem is surprisingly hard.
Comments:
There are 0 comments on this item. Be the first to comment.
Post a Comment
* Required field, your email will not be posted.