Filed under: Business, Compliance, Healthcare, Regulatory
Security implementation details:
security is part of the law required for part 11 compliance here is what the law says itself
Sec. 11.300 Controls for identification codes/passwords.
Persons who use electronic signatures based upon use of identification codes in combination with passwords shall employ controls to ensure their security and integrity. Such controls shall include:
(a) Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password.
(b) Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g., to cover such events as password aging).
(c) Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices that bear or generate identification code or password information, and to issue temporary or permanent replacements using suitable, rigorous controls.
(d) Use of transaction safeguards to prevent unauthorized use of passwords and/or identification codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system security unit, and, as appropriate, to organizational management.
(e) Initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or password information to ensure that they function properly and have not been altered in an unauthorized manner.
Here are some foundation security requirements for a part 11 compliant system
1 – Unique accounts for each user
2 – Encrypted connection to the system (SSL)
3- Complex Password required (numbers, symbols, length)
4 – Required to change password every 90 days
5 – Password history no reuse within a year
6 – 3 failed attempts lockout system (send notification to administrator)
7 – synchronize time on all servers
8 – show the username, name, and last logged in date on the screen at all times
9 – after 20 minutes log out account
10 – only allow one login at a time per an account
11 – log all activity in an audit log
12 – display version of software on screen (about screen)
13 – encrypt password is hash so it is irreversible and not viewable by anyone
14 – train people on security to thwart attempts at social engineering
With these feature requirements you can see that a part 11 security system has a pretty high level of requirement, but having the features is not enough you need to validation process and training to complete compliance.
Filed under: Business, Compliance, Healthcare, Regulatory
Auditing implementation details:
Auditing is part of the law required for part 11 compliance here is what the law says itself
e) Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying.
This essentially means you need to collect who is performing the action, what they are doing (record the before and after values), the date and time of the activity, a reason for the activity if not specified implemented in the module.
There are several other aspects of auditing required including time synchronization and unique usernames and passwords. Without these two things the audit logs don’t really mean anything it is a holistic thing and this explains why it is so important!
It is really valuable to have auditing across the entire system so that you can confirm roles security and authorization levels as well. Security logging, system access logging, and electronic signature logging are all required and useful for testing of a system as well.
Filed under: Business, Compliance, Healthcare, Regulatory
The 3 areas (pillars) of compliance
1 – Features
When you are building software for part 11 compliance you need to ensure you meet the features present in the law, this is known as feature level compliance and is only applicable to a specific version. Any change in a system requires revalidation of the features
2 – Validation
Validation of the features listed above is a second-level where you have the features to meet the law, now you have to prove with empirical evidence that you meet the requirements this evidence needs to be physical and linked to a process with integrity. The key works here are you need physical artifacts that stand on their own as validation (Test worksheets, signatures and reviewers signatures, screen captures, logs, etc..)
3 – Training
An often overlooked aspect of any system is training and proof of training, you must ensure the people who use the validated software are trained in it, and that training maps to the validation and features to ensure proper function without training the other 2 areas are pointless as there can be user errors and no accountability.
We will map the features of the law into a software system in a later exercise but essentially there are two main areas of specialty
1. Auditing: This is proof of what is happening by who and how it is changing, in a way that there is no chance of the system not working
2. Security: This is the biggest nut to crack in that you have to have best practice security (encryption, Authentication/Authorization, unique accounts, on screen indicators, password resets, 90 day password changes, password history, complexity, etc.. secure communication lines this is a large area and one of most important, and synchronized time on all system.
3. E-Signatures (optional):If your software is converting paper to electronic and electronic is the primary store, then you must create an e-signature system that has security, auditing and is also a statement of intent within the system to ensure the signature is valid.
Validation is another big piece you need a process that maps features to specifications to tests and this all is robust and transparent. Any function of software must be validated, with empirical evidence and physical artifacts, all best practice with clear and concise process.
Training is the third and this entails with going through all functions for each role, and having the student and instructor confirm that they understand and agree training was adequate, this is for the entire process.
In a later segment we will go through more detail of the processes required for compliance and meeting the requirements.
This weeks pattern is the Memento Pattern. We will spend this week reviewing this pattern, how it is used and what its intent is for. For some more in-depth definition you can see here and here are some useful descriptions, but to appreciate this we will review the intent and possible solutions and applications for this pattern in everyday work.
Here is the intent of the Memento pattern: “Without violating encapsulation, capture and externalize an object’s internal state so that the object can be returned to this state later. A Magic cookie encapsulating check point capability, promote undo or rollback to full object status.”
Example application for this pattern has been to support undo or rollback, other common implementations are a finite state machine. In my own personal development projects I have used memento pattern to create and audit trail with full play-back of the payloads as an encapsulation exercise.
What is it?
The FDA is a government regulatory authority and CFR is short for “Code of Federal Regulations” which is basically another work for Federal Law. Each Cabinet in government and governmental body has a Title in the CFR that dictates the laws that apply to a particular governmental body so the first part of this CFR 21 is basically CFR Title 21, which is the body of laws under which the FDA is regulated. the second part (“Part 11”) is a sub-section under the law that is applied to specific circumstances. Part 11 in this case applies to Clinical Trials and electronic record keeping for clinical trials.
Sec. 11.1 Scope.
(a) The regulations in this part set forth the criteria under which the agency considers electronic records, electronic signatures, and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally equivalent to paper records and handwritten signatures executed on paper.
(b) This part applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted, under any records requirements set forth in agency regulations. This part also applies to electronic records submitted to the agency under requirements of the Federal Food, Drug, and Cosmetic Act and the Public Health Service Act, even if such records are not specifically identified in agency regulations. However, this part does not apply to paper records that are, or have been, transmitted by electronic means.
An interesting thing about CFR 21 Part 11 or more specifically and generally referred to as Part 11 compliance is that there are 2 points of view.
1 – it is just a law and has some ambiguity at that, you can see the law here: Law :and information here: Title 21 CFR Part 11, it is very small barley fits on 2 pieces of paper and has enormous consequences for software used in the regulated area of Clinical Trials.
2 – Whenever you have a legal area there is what the law says and second is the interpretation of the law, or more specially the interpretation and enforcement of the law.
You have cases that have been taken to court and interestingly enough have had impact on how things are enforced and what you need to do to come under compliance. One such court case : here, essentially explains that you cannot grand-father electronic systems into compliance because of the risks and downstream effect, so this court case says that any systems that fall into compliance need to meet the new laws circa 1998.
What is this important?
If you wanted to innovate and differentiate yourself in this industry there is a big barrier to entry and interestingly enough regulatory compliance is expensive and also risky business so it creates a value moat if you can understand and use regulatory compliance to your advantage.
If you can pass a Part 11 Audit it has extreme value to show not only that your software does what it says it does, it does what the law requires, which ensures safety, security and proper function.
The most important part of this regulation is that you need to be certain that data in a clinical trial are true and exact, this impacts whether people live or die. Because of high risk and importance of the software systems once you get a system compliant it reaps enormous benefits in that you charge more money for the software, training, and validation of the system setups.
NCover 1.5.8 Errors (profiler connection not established or [ncover] Index was outside the bounds of the array)
I am creating a NANT and NCover build that is braking randomly, the tests and bulid succeed, but the nany scripts break with profile error, then once I fixed that it was an array out of bounds error.)
The profile connection error was related to elevated permissions on Vista or windows 7, once you run build script as admin or remove UAC this resolved the issue. The correct approach on this would be to dig deeper into the identity and permissions the build script has to execute and ensure this is covered.
The issue with index out of bounds, appears to be a bug with NCover 1.5.6 or greater. If you grab NCover 1.5.5 it appears to work without issue and this resolved my problems. You can download NCover 1.5.5 here:
Documentation… The bane of many developers and architects, who would rather write code or prototypes, maybe even tests or bug fixes. Documentation has been a topic of great controversy, pitting Agile against Waterfall. There have been many attempts over the decades to replace technical or functional specifications with Domain Specific Languages (DSLs) that can auto-generate code from a written document. What is unfortunate is that the value of good documentation is lost in the mix usually because of some common pitfalls.
Pitfall # 1 –The goal and reasoning behind documentation is not clear.
Pitfall # 2 – The value of the documentation is not usually given to those who create it, and ultimately it is usually a lower priority than code and as a process is usually not followed so code and documentation get out of sync.
Pitfall # 3 – Developers have not been training appropriately around good practices, and guidance, these are usually given to analysts and project managers, who don’t know the code or technical capability as well.
Pitfall # 4 – Time…. usually as a lower priority no time is given to documentation and many modern practices (Agile) value readable code over documentation (Thought I would argue a functional specification is similar to a story, but perhaps more technical in business terms.)
In my previous posts I have discussed how important people are to making a great startup, In this post I will outline the characteristics that I think make for great people to help make you startup or your business a success.
I think the number one character trait in looking for great people is simple… Integrity. If you think about it, this is a great characteristic and makes for easy decisions, but how do you know if a person has integrity? This is the most challenging aspect of this requirement, however you can read how people respond to problems, you can examine a resume and look for any red flags that show lapses in integrity, but to start to answer this question lets look at the core qualities of integrity so we can unpack this and see if there is some guidance we can use to make this clear.
1 – Integrity is a concept of consistency of actions, values, methods, measures, principles, expectations, and outcomes. In ethics, integrity is regarded as the honesty and truthfulness or accuracy of one’s actions. Integrity can be regarded as the opposite of hypocrisy, in that it regards internal consistency as a virtue, and suggests that parties holding apparently conflicting values should account for the discrepancy or alter their beliefs.
I really like the part where it is the opposite of hypocrisy, so we are looking for an honest and ethical person. I would hope most people would have this virtue, but unfortunately this is most likely a rare trait. Some things to consider,
a) Do they claim to know things but don’t know them as well?
b) Do they take credit for everything or offer to give credit where it is due?
c) Listen to everything they say, usually there will be very straightforward times, especially when you have them tell you a story about a time they had a challenge, or learning something new, these are revealing to the persons true nature.
d) Watch their behavior for kindness, and politeness
Lets say you found a candidate, here are the other qualities in the order of importance.
2 – Motivation is similar to passion and only if the person has integrity will there motivations be in the best interest of the company. With the proper motivation everything else will fall into place, this is important to be sure the candidate has motivation as well!
3 – Capacity is in third that with the proper motivation if they have capacity they can then understand what is needed and why things are important, and how to make things improve.
4 – Understanding is impossible without capacity as you really limit your understanding if you have no capacity to understand!
5 – Knowledge is meaningless without understanding!
6 – Experience is blind without knowledge!
How strange this is, that usually hiring decisions are based on experience instead of the things that fall in place with the proper foundation!
Building a business is not straightforward or easy, things that seem like common sense surprisingly are not the right choices for success. Knowing that the goal of a startup is ultimately to make money, with this in mind it is a good thing to remind yourself about as you progress in making a startup successful.
With many startups based on technology and solutions it is a big trap that you can fall into easily, thinking it is about the technology. What really makes it work and successful is the core issue of solving a problem, making the pain go away, and possibly giving pleasure or all three. I call these the three P’s
1- Problem : This is ultimately what you are solving the niche where you fit in.
2- Pain: This is the pain you are making less, or removing, where people most likely are willing to pay you money to make it go away.
3- Pleasure: The converse is that pleasure, bringing pleasure and taking away pain are almost the same, you can think of games or other interactions matching in this category.
Technology is important, it is the means to an ends, however there are so many technological solutions, that they are interchangeable in many ways, there is no one secret sauce people are solving problems and if for some reason you technology works, that is great but don’t think that is what it is about.
I think the key ingredient to a successful startup is knowing the technology is not key, but the people are! People are what make technology work, and people are what it is all about, that and of course a solution and plan for making money! Many large companies buy out startups not just for the company as a technological asset, but for the data, business establishment, and most importantly the people who executed correctly.
How do we find the right people for hiring, this will be coming up!
RBAC is using permissions and roles to authorize people for access to a system, or parts of a system. It is very straightforward and is standard security used in many different technologies. The basic components for RBAC security is you have subjects, permissions, roles, and operations.
1 – Subjects. A Subject is the person or system that is requesting authorization to perform an operation. In some advanced scenarios the subject would have a context with some session information useful for authorization decisions.
2 – Permissions – A Permission is a granular activity that is well defined, an example would be access to a file-system, permissions would be read-access, or write-access, etc. A permission is made up of smaller components being an operation and a target/resource. This linkage between an operation and a resource with a name/context is the permission.
3- Operation – this is the activity being requested and is linked to a resource where the activity will be completed.
4 – Role – This is the collection of permissions with some description around the purpose and role of the system.
One of the hard requirements for RBAC to work is that you must only assign subjects to roles, and nothing else, as this would bypass the purpose of RBAC as being able to manage and secure things easier. Some of the common problems with RBAC are listed below.
1 – Role Explosion – This is basically that when you have more complicated security requirements you basically need to create a role for every user, or have an exponential role requirement when you are trying to enforce logical security needs having to centralize the roles. RBAC has a notion of a role-hierarchy, where you can nest roles within roles, for permissions, this works well but only considers one scenario.
2 – Role Management – This is where management of roles and subjects is really brittle and cannot easily be fixed, as having roles containing roles and permissions, the biggest problem is knowing the final result, which can be very confusing with role scopes and precedence, the kinds of problems RBAC should solve.
3 – Tightly Coupled – When you have a security system tightly coupled to the other systems, usually RBAC is baked inside the systems it is not designed in an open and modular fashion making expanding and extending impossible.
We will go into more detail on advanced RBAC scenarios, solutions and other systems that will solve your problems.