TEMIS up close pt. I: customization

Daniel AmstutzKnowledge, News, Promo

A few months ago, we’ve released an overall look at TEMIS and were only able to scrap the surface of all its features (go to the TEMIS main page). In the coming weeks we will have a more in-depth look into it, starting with the customer customization features, which make TEMIS accessible and useful for all sorts of customers in biotech, and eventually all throughout the pharmaceutical industry.

TEMIS is a document attribution and management database in its core. Thus, it is crucial for TEMIS documents to be filed away in an orderly fashion, which means efficiently and intuitively. They cannot end up being lost and forgotten, that would defy TEMIS’ purpose. TEMIS must conform with the organization’s existing documentation system, or -if none exists- a new one must be created. This can be achieved through the TEMIS Attributes Matrix, which will now be shown from up close.

Attributes Matrix

When the main database is seen as the surface of TEMIS, then the Attributes Matrix is the foundation that holds it all together.

Attributes, document types and keywords are the key components for the organization of TEMIS documents, and they vary from user to user. A market-approved drug manufacturer may have different documentation requirements than a pre-clinical start-up. Or an organization may decide to only use TEMIS in a single department, so the documentation system remains simple, whereas another organization decides to use it company-wide, then it makes sense not only to include production-related documents, but also extend it to finances, marketing, HR, which will make the system more complex.

Here’s an example: The fictional 50 employees company Alpha is a manufacturer for a cell medium with clients all over Europe. They develop one cell medium that only marginally changes per customer. Hence, company Alpha will have numerous documents that are almost identical, such as analytical specifications, CoAs, logistics documents etc. These require clear attribution, so there is no mix-up between the various customers. E.g. an attribute “Product” does not make much sense, because there is only one sold product, but instead it is very important to have attributes that allow to safely distinguish the corresponding customers in documents, such as attributes for customer company, the document recipient at the customer, an attribute that contains a company-specific identification number, a send date etc.

In short, whereas the programming code and the features of TEMIS remain the same, each organization will have their own very specific documentation system, and the Attributes Matrix is capable to account for this.

Attributes, doctypes and keywords

The matrix is structured into two dimensions, document types (columns) and attributes (rows). The organization defines the content of columns and rows, to structure their documentation and filing system within the organization, and hence, within TEMIS.

Where doctypes and attributes intersect, TEMIS “learns” the significance and relevance of the attribute, which means, not all attributes must be filled for each document, some are more or less important, some do not apply at all.

Figure 1: overview of exemplary Attributes Matrix. Highlighted green is the intersection of the Document Type “SOPs/Policies” and the attribute “Doc. Subtype SOPs/Policies”

To provide an example: an SOP is to be filed in TEMIS. The user selects Doctype “SOPs/Policies”, which triggers TEMIS to forces the attribute “Doc. Subtype SOPs/Policies” (amongst others) to become “mL” (cf. figure 01, highlighted bright green), which means “mandatory, single List”, which in turn means: A document of the type SOPs/Policies must have exactly one keyword set that is to be selected from a predefined list.

As seen in figure 02, the user then selects one of the possible document subtypes, such as “Policy”, “SOP”, “Form Sheet”, “Qualification Master Plan” etc., in this case, it is “SOP”.

Figure 2: Document Subtypes (here of the of Document Type “SOPs / Policies”) allow for further distinguishing Document Types.

Again, the content of this list, and all others in the attributes matrix, is modifiable and may be customized.

Attributing keywords to documents will later on allow users to find respective documents more easily through auto filters or the TEMIS search mask.

What can a customer change?

We highly recommend for new TEMIS users to think about the best way to file and sort documents, or – if there already is a documentation system is in place – to adapt TEMIS accordingly.

To make the building of a documentation system easier, QBDC offers an Attributes Matrix template, which may be used for this purpose. Using this template will make it easier for both parties to translate the customer needs into TEMIS requirements.

The template may be downloaded free of charge.

Figure 3: Exemplary Attributes Matrix. Same as fig. 1, but with customizable sections highlighted in turquois.

When we look at figure 3, you see the sections that can be changed in the Attributes Matrix.

a) Document Types: Doc. Types are the primary means of document distinction, or in other words, they are the pillars of the TEMIS documentation system. You should ask yourself the question: Which is the first characteristic that comes to mind, when I’m looking at or looking for a certain document, like an SOP, a certificate, a datasheet. These are your primary characteristics and should be used as Doc. Types.

In our experience, it is best to bring documents together, which are handled similarly and have common denominators, like “SOPs/Policies”, “Records”, “Training Documents” etc. It is also possible to distinguish the columns by departments, like “QA”, “QC”, “Warehouse”, “IT”, “HR” etc. However, it is not advised to mix systems, like having a column “QC documents” and “Records”, as there is a high risk of documents not being filed where intended.

b) Attributes and attribute types: Attributes are secondary characteristics of documents, and are to be understood as identifiers which help at administrating and retrieving documents. You should ask yourself the question: When I look at a document, which are its most relevant pieces of information and how can they be labelled. A document may have various dates e.g. approval, effective, expiry, send, rejection, target etc. dates, a document may be associated with a project, a service order, a product, a batch number, a department or with another document. A document may require an attribute for remarks or specific keywords etc. These are your attributes, and their number should initially be as expansive as possible. It is easier to remove unused Attributes than to add new ones, which bears the risk to update all previously entered documents.

Attributes come at three types: “text”, “list” and “date”, which must be defined for each attribute. A text attribute may be filled with any text, regardless whether it is a number, letters, punctation marks/symbols or a combination of all; e.g. “batch number”, “item code”, “number of pages”, “remarks”. A list attribute is comprised by a finite number of predefined options; e.g. “company code” contains the list of client aliases, “product” contains the list of all produced products, “department” contains the list of all involved departments. A date attribute can only contain dates in a predefined format, all other entries are rejected.

c) Attribute conditions: Attribute conditions are the intersection between Doc. Types and Attributes, which means, once a Doc. Type is selected, TEMIS “understands” what attributes are to be considered relevant for the respective Doc. Type and forces the user to fill in that information. Document release is only possible, once all mandatory attributes are filled in.

The possible conditions are mandatory versus optional (m/M vs. o/O), list versus no list (with or without “L”), single entry versus multiple entry (capitalization). See figure 4, for a definition of all possible conditions.

Figure 4: Glossary of Attribute Conditions.

To provide an example, let’s look at the Doc. Type “Record” and the Attributes “Company” and “Project”. For Records, the condition for “Company” is “M” and for “Project” it is “OL”.

When a Record is filed, TEMIS reads that “Company” 1) is a mandatory attribute and cannot be left blank, 2) is not a list attribute, the user may therefore enter any text that suits the attribute and 3) is multiple entry (because the “M” is capitalized), i.e. one or more companies involved/affected may be entered. For the attribute “Project” TEMIS reads that the attribute is 1) an optional one, which may be left blank, 2) a list one, which means only options from a predefined list are possible (but the list selection may be left blank), and 3) is multiple entry as well, the document may be associated with one or multiple projects.

With a) through c), the basis of the Attributes Matrix is defined and ready to be put into practice.

Coming next

  1. Customization
  2. Easy implementation
  3. GMP & Validation
  4. Manager operations: releasing documents
  5. Key user operations: prepare documents
  6. All users: Search and retrieve
  7. Administrator: modify DBs and keywords

Share this Post