Medical Dictionary for Regulatory Activities

Mousley Consulting is pleased to see that after many years of numerous “do-it-yourself” medical terminology coding dictionaries in use by Biopharmas, the FDA has committed to a standard dictionary, and that this dictionary has become the standard for adverse event reporting in the USA. This fairly recent commitment is to the Medical Dictionary for Regulatory Activities, commonly known as MedDRA.

For many years Biopharmas performed medical terminology coding using their own private dictionaries developed totally “in-house” or modified in some way from one or more dictionary sources such as Coding Symbols for Thesaurus of Adverse Reaction Terms (COSTART), World Health Organization - Adverse Reactions Terminology (WHO-ART), International Classification of Diseases (ICD9), and World Health Organization – Drug (WHO-DRUG) resulting in a hodgepodge of dictionaries and coding schemas.

In order to bring consistency and uniformity to the coded data being submitted to it, the FDA has recently committed to a standard coding dictionary, namely MedDRA. In addition to the FDA’s selection of MedDRA, the International Conference on Harmonization (ICH) backs MedDRA and the European Union and Japanese regulatory bodies mandate the use of MedDRA for safety reporting.

In this article, we explore the fundamentals of MedDRA, hoping to provide a primer in medical terminology coding for the uninitiated, non-dictionary group, persons otherwise involved in clinical trials. We begin by discussing the need for coding, and then delve into MedDRA, its structure, its use, and why we are pleased to see it after all these years.

Readers are encouraged to share feedback and suggestions regarding this article, and welcome suggestions of topics.

Please click on the icon to see the complete article (PDF).

Document Management - What it is and why?

It has been my experience that oftentimes, many companies do a better job managing and securing their office supplies than they do their business-critical documents.

The electronic documents that are essential and critical for today's business are all too often taken totally for granted. Very few businesses take the time to consider the expenses that they might incur because of:

* Time and effort wasted in locating documents. Recent research indicates that nearly 10% of an average office worker’s day is spent trying to locate existing information and documents.
* Redundant effort expended because it’s often easier to recreate something than it is to try to find it.
* Time and effort involved in figuring out who has the latest version of a document, and recovering it when various revisions overwrite each other.
* Unnecessary and inefficient usage of network storage devices and network bandwidth, because the documents are dispersed everywhere across the businesses' storage devices, rather than in a centralized, indexed, location.

Likewise, few businesses take the time to consider the considerable risks that they expose themselves to on a daily basis because:

* Security is applied haphazardly at best, which potentially exposes important information to inspection by inappropriate people, like your competitors.
* Critical documents are stored -- often exclusively -- on laptop computers that could be lost, stolen, or damaged at any time.
* Documents that are stored centrally on Windows network drives, once deleted, do not go into a recycle bin as commonly believed. They simply disappear, and must be restored from backup (if you’re smart enough to have one).
* No record exists of precisely who has viewed and/or edited a document. It’s therefore impossible to audit a business process to uncover mistakes or inefficiencies.

In rather stuffy terms, a Document Management System (DMS) can control the life cycle of documents in your organization — how they are created, reviewed, and published, and how they are ultimately disposed of or retained.

We at Mousley Consulting, Inc. believe that properly designed and used Document Management System can rapidly pay for itself. Furthermore, we do not believe that there is a one-size, fits (or suits) all software application. The range of solutions goes from inexpensive, open-source systems based on Unix-based servers to robust, hosted Microsoft SharePoint applications customized to seamlessly support proprietary workflows - what are your business requirements?

Dr. Kirk Mousley

What is this Unix stuff?

Unix is a computer operating system originally developed in 1969 by a group of AT&T employees at Bell Labs.

Unix and Unix-like operating systems are widely used in both servers and workstations today. The Unix environment and the client-server program model were essential elements in the development of the Internet and the reshaping of computing as centered in networks rather than in individual computers.

Under a 1956 consent decree in settlement of an antitrust case, AT&T (the parent organization of Bell Labs) was forbidden from entering the computer business. Unix could not, therefore, be turned into a commercial product under the terms of the consent decree, Bell Labs was required to license its nontelephone technology to anyone who asked for it.

In 1983, the U.S. Department of Justice settled its second antitrust case against AT&T and broke up the Bell System. This relieved AT&T from the 1956 consent decree that had prevented them from turning Unix into a product. AT&T promptly rushed to commercialize the Unix System V, a move that ironically very nearly killed Unix.

In 1991 Linus Torvalds released a version of Unix named "Linux" as free software. Linux distributions, comprising Linux and large collections of compatible software have become popular both with individual users and in business. Popular distributions, some with rather esoteric names, include Red Hat Enterprise Linux, Fedora, SUSE Linux Enterprise, openSUSE, Debian GNU/Linux, Ubuntu, Mandriva Linux, Slackware Linux and Gentoo.

Mac OS X is also a Unix system developed by Apple Inc.

Linux and BSD are now rapidly occupying much of the market traditionally occupied by proprietary Unix operating systems, as well as expanding into new markets such as the consumer desktop and mobile and embedded devices.

We at Mousley Consulting, Inc. are not only closely watching the "Open Source" software initiative, but are dabbling in it as well, having set up a server running the Ubuntu operating system with OpenDocMan and OpenClinica web applications. Furthermore, we have set up a laptop running Ubuntu to serve as our test bed client.

The allure? The software is free, the source is readily available and customizable, and it is supported by hundreds (if not thousands) of developers/experts.

Stay tuned! We will continue to explore "alternates" to the perceived high cost of Microsoft software and discuss our findings in this space.

Have you used Unix and/or Open Source software? If so, what do you think?

Working Together

I think the word "collaboration" is too fancy and is poorly understood by many in any event. I prefer to say "working together."

The best way to for people to work together is for them to be physically together.

When you are in the same room as your co-workers, you can easily interact, share ideas, asks questions, and accomplish things. Many people work better in a social environment where conversations fosters understanding, spark ideas and provide enthusiasm.

Of course, one can get carried away with talking to another and end up shooting the breeze all day and not accomplish anything. However, being alone in a quiet workplace, one can daydream all day and not accomplish anything just as easily as one can do significant, uninterrupted work.

One of the downsides to being together is the need to travel to a common gathering place, such as the office. Many companies have geographically dispersed workforces and more and more companies allow telecommuting so workers don’t have to spend as much time on the road.

For telecommuters, perhaps the next best thing to being physically together is to be virtually together. Software tools such as IBM LotusLive Engage, DRE Business Collaboration Network and Microsoft SharePoint can put everyone in the same “room” electronically.

Microsoft SharePoint uses a web server that provides Team Sites which allow sharing of information, calendars, tasks, ideas (wiki), and documents. The only missing component to virtual "working together" is the verbal/visual communication aspect. Perhaps SharePoint combined with video conferencing is the way to be productive, social, and working physically apart? What do you think?

Dr. Kirk Mousley

Why Software Projects Fail

According to a study done by the Standish Group, the U.S. government and businesses spent over $81 billion on canceled software projects, and another $59 billion for budget overruns annually.

Their survey claims that only about one-sixth of all projects were completed on time and within budget, nearly one third of all projects were canceled outright, and well over half were considered "challenged."

Of the challenged or canceled projects, the average project was 189 percent over budget, 222 percent behind schedule, and contained only 61 percent of the originally specified features.

What are the primary causes of this failure rate?

We define a failed software project as one that is over budget, behind schedule, or fails to deliver value for the users of the software. Most people talk about the first two, over budget and behind schedule. One wonders how many companies actual evaluate the "value" they get from their software projects.

Here are our reasons why software projects fail. In a future post, we will address how to mitigate these issues.

Unrealistic Schedules

(Poor Cost and Schedule Estimation, Failure to Plan, Never Reviewing Project Progress, Ignoring Late Failure Warning Signals)

Pushing for an aggressive schedule does not accelerate the work, it actually delays it. When faced with an unrealistic schedule, development teams often behave irrationally. They race through the requirements, produce a superficial design and rush into coding. The mad scramble to build something - anything - results in a poor-quality product that has the wrong functions, is seriously defective and ends up being late anyway.

Setting correct schedules can be difficult. If management has software development experience, that is a help. However, our general observation is that most projects are not allowed sufficient time, and with many projects, the time from the testing and quality assurance phases of the project is often severely trimmed.

Inappropriate Staffing

(Lack of Resources, Lack of Executive Support, Skills that Do Not Match the Job)

The only way to complete an software development project rapidly and efficiently is to assign an adequate number of people with the proper skills and then protect them from interruptions and distractions. This helps build the motivation and effective teamwork needed for quality results. When managers fail to provide timely, adequate and properly trained resources, their projects will generally fail.

Software development continues to be a rapidly changing field. Programmers need continual training to stay current. It also takes a continual desire to learn on the part of programmers.

Changing Requirements During Development

(Incomplete and Vague Requirements, Poor User Input and Lack of User Involvement, Stakeholder Conflicts, Communication Breakdowns)

To start designing and building products, software developers must know what product to build. Unfortunately, management, marketing and even the customers often don't know what they want. Or worse, they think they do know and then change their minds partway through the job. While the requirements normally change in the early phases of a job, there's a point beyond which changes will waste time and money and disrupt the work.

This area also leads to the lack of value of the software project for the company. If the project's requirements are not thought out to a reason degree of completeness, the resulting software often provides little value.

Poor-Quality Work

(Poor System Architecture, Inadequate Testing, Testing in the Production Environment, Lack of Quality Assurance, Not Conforming to Industry Standards)

A common scenario is one where a manager of a software project that has to meet an accelerated delivery date set by their boss. They may unmercifully push their software developers, who rush through the design and coding and skip all of the quality reviews and inspections. Testing finds many defects, but management argues for delivering the software and fixing defects later. Management meets the deadline, but the system is a disaster. It is so unreliable that the software has to be fixed every time a change is made in the product or product mix.

When executives push for unrealistic schedules, the project either will be late in delivering a working product or will produce a product that doesn't work. There's a saying about software quality: "If it doesn't have to work, we can build it really fast."


Believing in Magic

(The Big Red Do-it Button, Unrealistic Expectations)

Commercial off-the-shelf software, or COTS, is an attractive way to save development time and money. But COTS isn't a silver bullet. If not properly managed, it can be a disaster. A COTS product that works perfectly in demonstrations, for example, may crash when subjected to different hardware configurations, higher data rates or even data-entry errors. You must test the product thoroughly enough to expose previously untested conditions. If the program is troublesome when stress-tested, it will almost certainly be troublesome when used in production.

In addition, the use of COTS may force users to adopt inefficient processes in order to use the software. This inefficiency will reduce the value of the software. A full explanation of the "buy versus build" evaluation process is beyond the scope of this entry. However, there are costs associated with configuring COTS, adjusting processes, and process inefficiencies that must be compared with the cost of writing software from scratch.

Conclusions

It is important to allocate sufficient time and resources to complete your software projects successfully. It is equally important to take time in the planning and requirements phase to make sure the project is able to deliver real "value" to the users. Finally, it is important that software be sufficiently tested to minimize the cost to the business of software errors.

Source: Why Projects Fail - Watts S. Humphrey
Source: Cost of Software Failures

From e-Survey to EDC

Recently, Karl and I attended a seminar presented by IBM SPSS titled "Predictive Perspectives" where they demonstrated their Data Collection Author product as well as several others.

Data Collection Author can help you create surveys. You can create one survey and deploy in many different modes (online, telephone, offline) and in any language.

While the presentation was underway, it brought up the question, "At what point does e-survey software become Electronic Data Capture (EDC) software?"

We are aware of a mushrooming number of e-survey products on the market today. A incomplete list of them might include:

SurveyMonkey, eSurveyspro, surveygizmo, QuestionPro, and SurveyMethods

Now, while we don't necessarily endorse any of these, we thought these vendors might consider further developing their offerings into EDC products. What would doing so entail? Might it be possible to create a low-cost EDC system using a well-designed e-survey application as a starting point?

Obviously, a lot of surveys are single-pass collection of unedited data from anonymous sources.

One would need to allow data editing. One might need more enhanced data cleaning power than that provided by form-level edit-checking and input masking (e.g., capture dates in consistent date format). One would need to identify the person entering data. With the ability to change data, comes the need for an audit trail.

In between e-surveys and full-fledged EDC systems, lies a range of applications that allow someone to select user preferences from a specific set of options. Examples of those would be a user profile or health benefit enrollment. These applications are often custom tailored and one-time use. Can e-survey software, with its user friendly authoring capability be extended into these areas in areas to offer a much more "generic" development/update environment?

Finally, EDC would require compliance to 21 CFR Part 11 software requirements - more specifically, the software requirements detailed in Section 11.10:

• Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records


• The ability to generate accurate and complete copies of records in both human readable and electronic form


• Protection of records to enable their accurate and ready retrieval throughout the records retention period


• Limiting system access to authorized individuals


• Use of secure, computer-generated, time-stamped audit trails


• Use of operational system checks to enforce permitted sequencing of steps and events


• Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand


• Use of device checks to determine the validity of the source of data input or operational instruction


• Determination that persons who develop, maintain, or use electronic record/electronic signature systems has the education, training, and experience to perform their assigned task


• The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures


• Use of appropriate controls over systems documentation

Adding all of this to an e-survey application would not be a trivial endeavor. Nor will it be complete since we haven’t mentioned the addition of other longtime Clinical Data Management System functions like autoencoding and site monitoring.

While we remain hopeful that advances in software will eventually allow the creation of a low-end EDC system, we remain skeptical that it will be "inexpensive".