An agency – small or large – or any multi-user environment, may face apparently conflicting requirements. On one hand, it makes sense to have standard glossaries because it would be wasteful to have everyone spend time creating the same entries again and again. Also, standard glossaries are a good way to ensure that spelling and capitalization conventions are the same in all reports produced by the agency.
On the other hand, as different people work differently, there is some efficiency to be gained in allowing users to adopt different styles of abbreviation.
With Includes, the two requirements can be satisfied without any conflict. A given glossary – say for Toni – Toni.glo, may appear as follows:
[Glossary Toni]
[include \\Common\Glossary\Standard.glo]The first part of the glossary contains what is specific to Toni: what Toni can modify with the Glossary Viewer. The Include line makes standard definitions available. Here we assume that Standard is on some network drive and the policy may be such that Standard is read by everyone but only one person is responsible for updating it.
A Standard glossary could be a Headers glossary with all headers in capital letters:
hopi HISTORY OF PRESENT ILLNESS:This allows the person in charge to to add new headers or change their style, and all glossaries that include Standard automatically inherit the new or edited entries.
If transcriptionists work on different machines at different times, other variations of this scenario are possible. For example, the specific glossaries such as Toni.glo may be kept on a network drive to allow access from different machines:
...
[include \\Common\Glossary\Toni.glo]
[include \\Common\Glossary\Standard.glo]And many other variations are possible...