Securing InfoPath forms data precludes use of Forms Services

I am a big proponent of InfoPath Forms Services, in both MOSS and SP 2010. This is because it is a server-side processor of InfoPath form templates and (in some cases) it will render and allow fill-in requiring only the browser and no client side components.

I also believe forms processing (generally) has a great potential to eliminate mistakes and protect the integrity and actual values of data from harm.

I started digging deeper into this for a demo I am preparing for a health care form. Of course, all PHI (i.e. personal health information) must be protected from deliberate or inadventent disclosure. I am still working to implement this in the Microsoft software stack. Unfortunately the following has become clear:

• Although digitally signing forms data works, this does not encrypt the data so forms containing sensitive data are open and subject to compromise.
  
• It is possible to extend the InfoPath client function in order to encrypt/decrypt some or all of the fields in the form data. This must be done using the InfoPath object model. Of course, doing this compromises the no code goal.
  
• Finally and most disappointingly, use of these code extensions is not compatible with Forms Services. This means that to use this facility, all form-fill-in users must have the InfoPath desktop client!
  

Bummer!!

Regards..

References:

Encrypting and Decrypting InfoPath Form Data

Extending the Save Functionality in InfoPath 2003

Protecting Sensitive Data

Password-Protecting Sensitive InfoPath Form Fields

data denormalization?? who cares?

This posting about getting data (your data, that is) into a place where it is more useful to your organization.

Let's say you have been keeping some data of yours (such as shipments) in an Excel spreadsheet. This is very common.

You have set up some very basic reporting using this data. You want other people in your organization to input their information into this "database".

You have a few options, for instance, you can:

• give them the spreadsheet on a USB stick
  
• can send them the spreadsheet thru email
  
• store the spreadsheet on a fileshare where they can access it
  
• upload the spreadsheet to the "cloud" such as Google Docs
  
• upload the spreadsheet to your internal web store (maybe a SharePoint document library)

The problem with all of these methods is that the other people will still be inputting and editing their data using Excel. Besides for all of the conflicts associated with the methods above, the likelihood of out-of-date and erroneous data is still very good. Let's look at an example:

First Name	Last Name	St
Joe	Smith	MD
Sally	Jones	NV
Sue	Kwon	Cal
Bill	Lyon	CA

If you saw this data in Excel, does it look clean? How about the St column for Sue Kwon. You might guess St means state, but by looking only at the first row, it might mean occupation.

Many "home brew" data sets are designed like this. A way to keep it cleaner is to have St be a lookup field, where St is the State and comes from another "location" where there is only one entry for California (not Cal or CA)!

This can be done with Excel using the =VLOOKUP() function (see Ref below).

When data is changed to behave like this, the data is said to be "normalized". There are a couple of other database-techie components to this definition, but we will only work on this one for now.

When the data is in the form above, it is said to be "denormalized" and is subject to all manner of data cleansing problems.

The next posting will go into how data like this can be stored in Sharepoint, in a normalized fashion using "no code".

Regards..

Ref: Learning VLOOKUP in Excel