Many of our customers within life sciences are concerned about how to perform their regulatory compliance assessment of the MOSS platform.  For those not familiar to the wonderful world of system validation, compliance assessments are typcially performed within life sicences to help determine whether or not a computer related system falls under any agency regulations (e.g. GxP, SEC, etc..).  The process of determing a system's applicability to things like GxP and SOX has traditionally been at the application-wide level.  For document management and lab information management systems, this process of identiying the intended use cases, assessing risk of those, and making an appropriate quality classification has been largely straight forward. 

Then comes along Microsoft Office SharePoint Server (MOSS)!  Most of our customers have a vision for MOSS that is larger than any one application and/or any 1-set of use cases, but rather provides capabilities and tools that could be applicable to almost any business unit/use case within the company.  With that in mind, service owners always find themselves scratching their heads on the various options they have when deciding how best to make their compliance assessment for such a broad solution.  The following provides some of the options we have seen traditionally employed and some newer ideas in this area by usage of our SharePoint Governance Kit.

1. Two Distinct Instances of MOSS (1 non-validated, 1 validated)
   This approach provides a clear distinction between the MOSS farms that intend to be used for supporting regulated use case, done typically by partitioning the validated instance of MOSS onto a seperate farm (often with its own hardware).  In this scenario, service owners have the benefit of a clear picture of which SharePoint sites may have information that are under a paritcular regulation, and which do not.  In some organizations, that may also provide the benefit of streamlined change control process for the non-validated instance.  However, there are several cons to this approach.  Multiple environments typically lead to an increase in support and maintance consts.  Additionally, the user experience for the knowledge worker then becomes scattered across multiple farms.
 


2. Qualify MOSS as a Platform and Implement Validated Solutions (if needed) on Top
   Probably the most common approach that we see today.  This scenario essentially views SharePoint as an underlying platform (not really a single application).  Almost as if you would handle the qualification of an operating system or SQL.  The compliance assessment in this approach basically states "All of the potential intended use cases for this platform can not be envisioned or identified up front, however to not preclude the usage of this platform for such scenarios, the environment with be 'Qualified' with sound software development processes such that when such a regulated use case would like to onbaord the service, it can leverage the foundational platform".  Often in this scenario, validated line-of-business solutions are built from the qualified platform and the deployment of that specfic set of use cases may need specific documentation/validation.
 


3. Combine either #1 or #2 with the SharePoint Governance Kit and Request Knowledge Workers to Perform a Small Compliance Assessment at the Time of Provisioning a Site
   Another new approach that we are beginning to see with the introduction of the SharePoint Governance Kit, is the process of asking knowledge workers/site owners some questions at that time they request a collaboration site.  Such questions that may be asked by our online provisioning wizard could be:
   
   "Do you envision the site that you are requesting to be a location where users will create, modify or maintain electronic records required by a predicate rule?"
   
   "Thinking about how you expect to use the site you are requesting, please specify the risk level that you perceive this collaboration site to be -
          (A) Low Risk - No content within this site would not be considered during a regualtory inspection
          (B) Medium Risk - The site may contain electronic records, however content is always verified before decisions are made that could affect patient safety
          (C) High Risk - Data managed in this site could directly affect patient life
   
   With the SharePoint Governance Kit, corporate policies could be enforced in different ways depending upon the knowledge workers response to such questions.  The action the solution would take would also be dependent upon a customers philosophy on corporate compliance and their underlying compliance assessment/architecture of the MOSS platform. 
   
   For example, if a customer had an architecture similar to the one described in #1 above, if a knowledge worker requested a "high risk" site, the governance kit could automatically route the request to a compliance representative and once approved, could automatically provision that site into the "Validated" SharePoint instance.  Similarly, if an end user was trying to request a "low risk" site, an organization may want to allow the Governance Kit to immediately provision the site (with no approvals required) directly within the non-validated instance.
   
   If a customer had an architecture similar to #2, the Governance Kit could perform the same types of approvals as required, but possibly create that site into a known Site Collection that has users trained on the appropriate SOPs for management of such content.

There are a dozen other ways (not described above) that we have seen clients use the site provisioning capabilities found in the SharePoint Governance Kit for helping them control compliance of the information in MOSS and if you have any questions, would invite you post here on this blog and/or reach out to us here at speakTECH.

In my next blog, I will expand upon the Site Provisioning capabilities available in the SharePoint Governance Kit and how it specifically can help Pharma's automate the creation of collaboration spaces for partners (like CROs) in extranet scenarios.