If you have a medical registry, research or business project for which you need to collect and secure data you will be considering the software you need to store it. Define the key questions you want your project or research to deliver and decide how you want to analyse, export or display your data. Make sure that your software will maximise the information you get from it thus repaying the time and effort you and your team spend putting data into it.

Your requirements list should be more like a recipe than a shopping list. Include all the ingredients and processing you need to make the outcome a success. Consider and document all your criteria from: your validation checks; to security and user access needs; to the displays required for your suppliers, customers, managers, patients, researchers or students.

Your data can be displayed in a host of different ways. It can be browsed, sorted and searched on the criteria that are useful and meaningful to you. Consider asking for data to be exported in the tables you need for a research paper or in the charts required by your shareholders at your AGM? If you need a statistical analysis to be performed on your data, ask for this to be automated too.

Once you've compiled your initial requirements list, talk to a software consultant who understands your field. Ask for a free consultation to discuss your needs and assess whether or not they have helped you move forward. Are they likeable and easy to talk to and are they able tease out all your obvious but unspoken requirements raising issues from their own experience? Look for signs that they are weighing up all the options for you and are even considering the suitability of another supplier's existing product. Remember that you have many choices for your software just as you do for your savings so identify the criteria that are most important to you and shop around for the best product.

So will a nudge help people lead healthier lifestyles? Health professionals and local government workers amongst you will be trying to answer that question. Well surely, the most important thing is knowing whether the nudge is making a difference. As with any new initiative, it's essential to decide how to collect and analyse the data needed to measure its success before embarking on it. Doing this will ensure the most effective delivery of lifestyle promotion and provide important data for studying healthcare economics.

We know it makes sense to protect lives by wearing seat belts, taking exercise, not smoking and by drinking and eating responsibly. We're all wary of government initiatives, but this one, designed to help us whilst reducing NHS costs, is a no brainer.

Similarly when commissioning new software it is essential to include a backup strategy at the design stage.  This is equally necessary  whether you need a small in-house stock control system or a large online medical registry. Improving efficiency is often a key reason for commissioning new software and the benefits could be compromised if your data is not backed up.

Devise a backup policy that is tailored to the way that you work, by working out how long it would take you to re-input  your lost data for the last hour, day or month. You’ll need to make sure that your backup regime will meet the standards of  your organisation. 

Where will you store your backups? It’s a question you need to address as the benefit of backups could be lost if they are stored in the same place as your computers. This would leave your backup media open to the same risks of fire, flood or theft as your data. Copies of your backups should be routinely stored off site either by using internet backups, cloud hosting or by physically transferring the media. Make sure they're not taken via the pub!

Have you ever had an umbrella that jammed when you tried to open it? Just having an umbrella doesn't mean that you won't get soaked and backed-up data is only any good if it can be restored.  So in addition to your backup regime you will need a restoration schedule. This will enable you to perform regular test restores to reassure yourself that  your backups will save your data even in the event of a serious hardware failure.  

Lastly consider what would happen if your backups were stolen? Look out for my upcoming article on data security and encryption.

So when a customer calls to report a problem we need to take it seriously and focus on putting it right. Additionally, we need to understand that they may be anxious or tense about making the call. They often feel that the problem is their fault or are calling because they are under pressure from pushy colleagues to 'just fix it'.

Very few customers give a logical list of symptoms for the problem they are experiencing. Those that do, you might well consider employing or at least signing them up to test your new products. The real support skill is to actively listen and filter out those elements and diagnostics that will enable you to hone in on both the problem and the possible causes.

Most customers will feel hugely better after they have imparted their problem to you and you have listened thoughtfully. We add more value by listening than talking and as the ousted Shibby, on BBC's ‘The Apprentice’, remarked: ‘We have two ears and one mouth; we should use them in that ratio’.

An electronic message is displayed on the dashboard of my car when the tyres are below their optimum pressure. This is really helpful because it’s an early warning that I need to take some action. Having monitoring on your customer’s software will warn you when problems occur before they report them to you. A proactive phone call advising a customer of an imminent problem or providing a fix to a technical failure, will really impress them. It both removes their fear that it may be their fault and provides you with the opportunity to find out how well the customer is getting on with their software. Getting feedback is always constructive and you may be able to further please your customer by providing some instant, over the phone, training.

Providing good customer service means that you have the opportunity to get things right and, even better, to delight.

We have implemented a flexible querying tool for a client to help them search and retrieve their business data. This solution integrates the Microsoft SQL Server Reporting Services Web Service with a .NET Windows desktop application to provide a flexible and intuitive search, sort and export system for their data.

We are able to describe this business search wizard generically although we are unable to release specific details of our client’s customized product.

Requirements

To provide an application to allow staff to query their company’s data with the following specification:

Selection specification

• A simple and intuitive selection screen
• Several parameters to select from (15)
• Easy selection (and de-selection) of criteria with drop down choice boxes where possible and a text translation for all coded fields
• Ability to select more than one value from a parameter where appropriate
• Date picker settings for date ranges
• Changeable default settings for all criteria
• Easy resetting of criteria to defaults
• Ability to choose which field set to be displayed
• Buttons to run or abort a selection

Display specification

• Data displayed in a data sheet manner on a new screen (Microsoft Excel style) after the selection is run
• A pre-determined list of fields returned and displayed in a pre-determined order
• Ability to sort on all or most fields after they are displayed
• Navigation to return to selection screen in order to refine selection
• A count of the records displayed

Export specification

• Button to export displayed fields to Microsoft Excel or other specified package
• Ability to choose the file name and location of the exported file
• Navigation to return to another screen

Solution

We integrated the SQL Server Reporting Services web service with a Windows Forms .NET application to produce a fast, easy to use, interface for our client to perform ad hoc data searches. Two screens were provided:

• Search Criteria interface screen with a wide range of named fields to select: some with drop-down lists; some with data range options and some facilitating multi-choice selection.
• Results Display Screen showing the returned records in datasheet format with options to automatically export to Microsoft Excel.

Benefits

• Users will be able to perform queries themselves without waiting for the availability of a SQL programmer.
• Users will be able to refine and fine tune their searches enabling them to directly answer management questions.
• Users will be able to sort the data file on any field of their choice.
• Users will be able to export the data to a file of their choice.
• Users will be able to spot and report data inconsistencies before data is released.

Overview

A search wizard is a valuable tool for any organization that has a database at the core of its business. It enables staff to answer the majority of questions that occur from day-to-day without needing to understand the database structure or language.

At the heart of all businesses, whether they are scientific, medical, educational, research-based or commercial, are data. Companies acquire data from their clients, patients, subscribers, customers and suppliers and from their own products and services. Businesses often require data from other sources as reference data for their own products or services. This reference data includes information such as: population and demographic data; stocks and share prices; consumer profiles; medical code lists; telephone and email directories. The key to a company’s success is how they organise their data.

When business data is kept in several disparate formats, manual intervention is needed in order to cross reference data or link one or more datasets to each other. When a company has lots of separate datasets it is challenging for any one individual to fully understand the company’s business. By analysing the company’s business with a view to bringing datasets together it is possible to document and display all the facets of a company’s data. Design methods are then used to arrange the different datasets in a manner that any grouping, search or calculation can be made across all a company’s datasets and the power of the data can be harnessed and fully exploited. This designed arrangement of data is called a database design. Once the design is agreed a database can be developed to provide an integral business solution.

The benefits of databases

Implementing a database solution for a business will enhance productivity and accuracy. Duplicated processes can be eradicated; data can be entered by several people simultaneously, data can be validated on data-entry; data-entry can be reduced by providing pre-typed lookup lists and duplicate records can be exposed and removed. Data can be displayed dynamically to anyone who has permitted access in a wealth of different formats and reports. When web based solutions are used, data can be securely, entered and viewed anywhere in the world. A company’s web site can be kept up-to-date from their database facilitating marketing and sales.

Interrogating databases empowers organizations to achieve their targets. Knowing which customers are also suppliers; calculating the effect of international exchange rates on product or component prices; deriving population based incidence rates or calculating the potential size of a company’s client base can be keys to marketing success; better sales margins; achieving research goals or business plan acceptance.

Who needs databases?

In short all businesses need to store their data in fully relational databases which will enable them to utilise and exploit their data. For some business models there is excellent ‘off the shelf’ software which will be perfect for their purposes, while for specialist and research businesses it will be necessary to request customised software developed by specialists such as Advent IT.

Please read the case study on the Microsoft site for more information.

There are 4 possible ways in which these tables can be joined; Inner Join, Left Join, Right Join and Full Join (all of which may give different outcomes). Left, Right and Full Joins are all outer Joins. The mystery of outer joins often puts people off them but this article seeks to explain left and right joins with a set of simple examples.

The following examples use two tables in a hospital database. The patient table tblPatient (11 records) contains a code (PatientDisease) for their disease and the codelist or lookup table tlkpDisease (12 records) contains a list of disease codes (DiseaseID) and their meaning in words (DiseaseText).

1. Inner Join

This is where only those records from the table on the Left of the Join that match those from the table on the Right of the Join are returned.

SQL statement

Note: The word Inner may be omitted as Inner joins are assumed by default.

This returns the following results set:

Note: Only those 9 patients who have a patientdisease which is in the disease codelist table are returned in this results set.

2. Left Join

This is where all records from the table on the Left of the Join are returned and only those that match from the table on the Right of the Join.

SQL statement

This returns the following results set:

Note: All 11 patients from the patients table and all 12 diseases from the disease codelist table are returned in the results set.

3. Right Join

This is where all records from the table on the Right of the Join are returned and only those that match from the table on the Left of the Join are returned.

SQL statement

This returns the following results set:

Note: All 12 diseases from the disease codelist table are returned in the results set whether or not there is a patient with that disease in the patient table.

4. Full Join

This is where all records from the table on the Left of the Join are returned and all those from the table on the Right of the Join are returned.

SQL statement

This returns the following results set:

Note: All 11 patients from the patients table and all 12 diseases from the disease codelist table are returned in the results set.

Summary

The above SQL statement returned four different results sets using the same join criteria on the same tables with different join types.

A self-join is an internal table (or view) join. The self-join is between fields in a table and fields within a virtual copy of the table. For instance in a hospital database the patients’ address and postcode details are kept in the table tblAddress with the identifier of the patient in the field PatientID.

The following SQL statement can be run in Query Analyzer in order for the hospital administrators to list the patients who share an address and patients who have been erroneously registered twice under different PatientID’s:

SQL statement

Note: aliases are used to distinctly name fields or tables with the same name to clarify ambiguities.

This returns the following results set:

The Patients corresponding to these ID pairs can then be investigated to test whether they are duplicates registrations or different patients, possibly relatives, with the same address.

Self-joins can also be written as outer joins.

Although you can, if you wish, employ the full capabilities of the security mechanism which Microsoft supply (groups of users with allocated rights, and/or specific rights for individuals), we feel that this is not only a high-maintenance approach (you need to keep editing the settings as people join, move around and leave), but it also fails to encompass some of the features which we regularly need, such as reporting structure and telephone extension, so we prefer to include a users table in the database (we normally call this USysUsers, by the way, so that it is normally hidden in the database window. If you haven’t discovered the “USys” prefix, it is a very useful trick for all sorts of cases!).

Some observations about the non-secured Access installation are as follows:

• The default creator, and hence owner, of ALL databases and contained objects in the environment initially will be “Admin”.
• There is an Admin user on all installations of Access, and security is in place, but because there is no password for admin, no login screen appears.
• You can change the ownership of any object except the database itself – this is a common cause of frustration!
• The workgroup file includes by default two “Groups”: Admins and Users. The Admin user is a member of both; there must be at least one user in Admins (otherwise it would be impossible to administer databases…).
• Permissions (rights) are allocated for both of these groups in the default file. The permissions which apply are the least restrictive set available to a user. So, although they may be restricted as an individual, they may gain extra privileges through membership of groups. The Admin user has full rights to all non-Microsoft objects.
• Members of the Admins group, plus the owner of an object, can change the permissions on an object.

Our approach uses a new Workgroup (MDW) file in which the Admin user is joined by one other “Super-user” to whom all the powers are given. Poor old Admin is demoted to have only the permissions which this upstart decrees. The new workgroup file is used when you are creating and administering databases; but (and this is the cunning part) you can give your MDB files to anyone else in the world to use, and, because they don’t have a “Super-user” in the System.mdw which was created when Access installed on their machine, they are stuck with the settings you have dictated.

Step-by-step

Use the Workgroup Administrator tool to create a brand new Workgroup file. Ensure that you enter a unique and non-guessable “WorkgroupID” (like an extended PIN number) and give the file a recognisable name. A good tip is to take a screen dump of the confirmation screen which appears towards the end of the process; paste the picture into Word and print it out for retention in a safe place: you’ll need the information should you ever need to re-build the workgroup file.

• “Join” the new workgroup file (ultimately it is a good idea to have two desktop icons to launch Access; one has the standard command line, and the other includes the “/Wrkgrp xxx.MDW” flag to join your new group for the session of using Access: you naturally employ this icon when you are going to do some development).
• Start Access and, via Tools/Security/User and Group Accounts, set a password for Admin.
• Also create a new user: we’ll call it SuperUser here, but please choose something for yourself! Again, ensure that you note the PIN Number which you chose for this user. SuperUser may have a password, but does not actually need to.
• Add the new user to the Admins Group, then close Access.
• Start the program again, this time logging-in as SuperUser.
• Remove the Admin user from the Admins group – vital!

You are now ready to begin creating secure databases! Just remember to log-in as SuperUser when you start a new project or whenever you are working on the database structure (rather than the data).

• Under Tools/Security/user and Group Permissions, we recommend that you remove ALL permissions from both Groups (i.e. no-one gets any spurious permissions just because they happen to belong to a specific group).

It is easiest to set the default permissions for users before you create any objects within the database; for each type of object, simply select the “” entry in the list and reduce the permissions as you feel appropriate. Then you can forget the whole issue!

Retro-fitting security to a database

If you need to apply restrictions to an existing database, the first thing to remember is that you cannot change the ownership of the database. So, you need to create a new database and import into it all of the objects from the original file. Change their owner to be SuperUser, and then adjust the permissions of all of the objects as above (it is easy to select all of the members of the lists, but don’t try to change the ownership or permissions on Microsoft’s MSys objects!).

The User-level Security Wizard will do all of this for you, but in Access 97 do remember that you must be logged-in as your SuperUser, otherwise you’ll see no effect! Access 2000 automatically prevents this possibility.

One other tip is that, if you use the common “two-database approach” with a data file and a “front-end” file, you’ll need to grant Admin permissions on the tables in the front-end file if there will be the need to change the connection string (i.e. if the back-end file may move or be mapped to a different drive on users’ machines).

The other, vital tip is to remember to take with you a copy of your developer’s MDW file when you go on-site – otherwise you won’t be able to make any changes to the database structure!