Tuesday, September 1, 2009

Improving Communications

In today’s business world the daily onslaught of data and information seems to be rapidly escalating – just ads from radio, TV, magazines, billboards, and junk mail along with e-mail spam and telemarketing telephone calls bombard each of us in ever-increasing amounts. This “unwanted noise” makes it even more imperative than ever before for people to communicate with each other the best they can and for them to strive for effective, concise, and clear messaging not only on the job but elsewhere.

Communication occurs in a variety of forms: gestures, spoken word, written prose, visual imagery, as well as sounds, music, color, lighting, odor, tactile feel, temperature and even taste. Business communications can be in any combination of the above forms (and perhaps other forms as well) but for now, let us just consider more typical forms of day-to-day discourse shown in Table 1.

Table 1.
Each of these forms of communication has its own unique pros and cons. Unfortunately for those that think they have little time to spare, it takes time to maximize the chance the communication will be fully understood and even more time to ensure it is acted upon in the manner in which was intend.

Face to face communication, perhaps assisted with visual materials, is probably one of the most effective means of communicating, and doing so on a one-on-one basis is the most effective means. The time and other costs it takes to do so, prohibits this form of communication from being used extensively, but it should be used when the situation calls for it, such as in an emergency or other crisis, business or otherwise.

At the other extreme, a quickly composed postcard, such as one bearing a change of address, mailed to many can be a sufficient way to communicate relatively brief, commonly expressed information that is important, but not especially urgent in nature. Obviously, one wouldn’t expect the company CEO to telephone each and every vendor and customer with such news (however, they might wish to personally talk to very important and special customers).

So when you are deciding which form of communication should be used, consider the nature of the communication. Is it routine, such as a holiday schedule announcement? Or is it informational, such as directions on how to get to the company’s auditorium for a meeting? Or is it an emergency or crisis requiring that immediate instructions be given to key personnel?

Clear communications are necessary for maximizing efficiency and productivity as well as reducing inefficiencies, unneeded costs, and even workplace stress. The more complex the task, the more communications that will be required, and the greater the likelihood of one or more miscommunications will happen.

For more details on what you can do to improve your communications - Please click on the icon below to see the complete article (PDF).

Monday, July 6, 2009

OmniComm's Purchase of eRT Data Capture Unit

OmniComm Systems Inc. recently acquired eResearchTechnology Inc.’s Electronic Data Capture (EDC) business. Click here to see the Philadelphia Business Journal article.

This acquisition represents a change in the EDC landscape that directly affects Mousley Consulting and some of it's clients; eRT's software customers; and biotech and pharmaceutical companies in general.

There are three points that we would like to briefly discuss about this transaction. We will not comment on the financial arrangements of the transaction, however, since that is not our direct concern. What is of interest are the following questions:

1. What will be the impact on eRT's customers?
2. What will be the impact on OmniComm and its current customers?
3. What will be the short and long term impact on the EDC industry?

First, what will be the impact on eRT's customers?

We believe this acquisition will probably be a good thing. We feel that the software might be better served being owned by a software company and not as an "orphaned" product owned by a services company. eRT has traditionally made most of its revenue from its ECG business. Software was a component of their business, but it was not the main focus. OmniComm will certainly pay more attention to the product.

However, it remains to be seen how much of the eRT software OmniComm will actually keep. Since OmniComm already has its own EDC software, it will be interesting to see how much of their own software and how much of eRT's software continues in OmniComm's future product.

When DataTrak purchased ClickFind, DataTrak's own EDC product was discontinued, and the ClickFind product enhanced to be the eventual future offering. While we feel what will happen with OmniComm probably won't be that drastic, we do believe there will be an eventual integration of the two products into one.

in any case, eRT customers may end up getting a more complete software offering, albeit not what they have been using, as well as better focused service.

Secondly, what will be the impact on OmniComm and its current customers?

Clearly OmniComm picks up a large customer base which should help the company in terms of its financial stability. In the short term, we believe there will be disruptions in service as OmniComm folds in the eRT business, but just how disruptive it will be depends on how well the merger is managed. In the longer term, the OmniComm product may be enhanced with the data management features from the eRT product, which overall should be a good thing.

Hopefully OmniComm will strive very hard to keep all of its current customers in the loop and be very responsive to them during this time of transition. Mergers are never easy, and two very different software packages will need to be maintained along with their own customer support in the short term to keep everyone happy.

Finally, what will be the impact on the EDC industry?

We have long felt there should be consolidation in the industry. At the DIA Annual show in San Diego, held in June 2009, there were still a lot of vendors. It seems, however, that the new entries are focusing on different niches, like pen on paper in the case of Kayentis, or on CDISC SDTM integration in the case of Octagon Research.

So we feel that there is still not a lot of consolidation going on yet. Maybe OmniComm's acquistion of eResearch's data capture unit is the start of more consolidation?

Looking forward, we believe that the EDC market will continue to mature and evolve. Where it ends up and what it will look like as it does so, is still anyone's guess.

Wednesday, June 17, 2009

Integrated Clinical Trial Management Systems

Several years ago Mousley Consulting wrote an article describing some of the key functions of a Clinical Trial Management System (CTMS). Our premise was that many of the people involved with Clinical Trials knew that Electronic Data Capture (EDC) and Clinical Data Management Systems (CDMSs) are computer systems designed to capture, store, and manage clinical trials data.

However, much less familiar to many people, is the integrated CTMS. In the past, the business requirements expressed as functionalities, found in a CTMS were typically “home-grown”, stand-alone or at best loosely-coupled systems. Systems that hopefully helped clinical project managers and others create, manage and conduct their trials.

With EDC being used in more and more clinical studies, and with the increasing emphasis on the use of portals and dashboards, we are seeing some of the functions of the CTMS tightly integrated with the EDC application. Obviously the conduct and management aspects of trial management lend themselves nicely to being part of a portal or a dashboard.

The planning and resourcing aspects of a CTMS, however, do not lend themselves so readily to the portal environment. Consequently, we feel that much of what we wrote earlier is still very much relevant to trial management of today.

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



Wednesday, June 3, 2009

CDMS and EDC Design Highlights

Over the years Mousley Consulting has published a number of articles with EDC-related topics. This was done as a founding partner of EDC Management. We believe that it makes sense to periodically revisit some of these topics and update our thinking when necessary. One of the topics we wrote about was CDMS Design Highlights. A CDMS is a Clinical Data Management System which is used by data management departments in Biopharma to collect, clean and store clinical trial data.

CDMS and Electronic Data Capture (EDC) applications suffer when the underlying repository (i.e., database) doesn’t offer data types that support the convenient storage of clinical trials-specific data. Clearly Data Capture Form Developers and Programmers spend much time developing code (and much of it redundant nature) to support the different clinical data types such as "Partial Dates". If this support were built into the repository, form developers and programmers would have a much easier time providing necessary clinical trial-specific functionality, and could more quickly make data entry forms available for users saving both time and money.

We believe that future versions of CDMS and EDC software should include the "clinical data types" that are discussed in our article. However, we understand that the design and implementation of these data types will be a challenging exercise for vendors. Certainly, there will be different ways the support for these data types can be developed and introduced. The best implementations will balance ease of programming with the required functionality.

Readers are encouraged to share recommendations that they may have for how vendors can improve their products. We would also like to encourage feedback and suggestions regarding this article, and welcome suggestions of topics.

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



Thursday, May 28, 2009

What are we really trying to accomplish?

As a certified Project Management Professional (PMP) and a Ph.D. in Computer Science, I realize the importance of clearly stating the purpose of a project or an application.

For many, it is difficult to take the time to work through the process of defining what is really needed.

While there are tools such as rapid prototyping and Rapid Application Development (RAD) available (see http://en.wikipedia.org/wiki/Rapid_application_development for more info), they do not remove the need for the eventual end users or the sponsor of the project to articulate in his or her mind what is really wanted.

To a large extent, my experience has shown that the more specific and constrained the requirements, the greater likelihood the project or application will succeed. The real world, however, does not always allow us to keep things as straightforward as we would like them to be.

So how do projects and applications get started? Someone identifies a need. Perhaps it is a need to do automate a repetitive function so that it can save the company money. Perhaps it is collecting information in a clinical trial for making a submission to the FDA. Needs can be small, and they can be very large.

Once the need is identified, the questions begin. I like to think of the 5 Ws and 1 H (see http://en.wikipedia.org/wiki/5_Ws). This is the hard (some may say annoying) part of starting a project. All the questions need to be asked, and some many times over until as many "clearly stated" answers as possible are obtained. The biggest question, and the one in my experience that leads to all the others, is why? Why are we trying to do this? This question is then followed by, "What are we really trying to accomplish?"

The "why" should be asked repeatedly to ferret out as many reasons as possible. Some of the first reasons we come up with might not be the most important. Some of the non-obvious reason(s) why might cause user acceptance problems if they involve issues with human performance or personal productivity. Knowing these reasons in advance will help a project or application be successful.

Once we know why we think we need to do something, we then need to define what we intend to do. To some extent, this is a question of scope in that it might involve how much of the problem we will attempt to bite off. Again, the question of what we intend to do should be asked repeatedly so that we can compare options and decide if we are addressing the most important parts first.

If we do the "why" and "what exactly" well, the rest will follow in a much easier fashion.

So, why did I write this???? :-) Certainly I did it to share my experience, but I also did it in hopes that I can help you answer these questions in your next project.

Wednesday, May 20, 2009

Planning Ahead

Preparing to attempt to avoid "emergencies."


One of the discussions I have been having with one of my clients is that we cannot always justify taking as much time to do something as we want. One just needs to think about an ambulance on their way to an auto accident. Time is of essence, it is life or death in some cases.


The key is that the ambulance is ready before hand. The ambulance is stocked with supplies. The ambulance personnel are trained and ready to go. They minimize what might go wrong while they are not in an emergency.


I have been giving this a lot of thought. Certainly backups are part of the preparation for a business to be ready for a potential emergency, as in the case of a computer crash which the client just experienced.


Having a good backup strategy is a good start. However, we may want to go even further. In space, many systems are redundant since there is no way to get things fixed quickly. When I used to work at GE Space Division, the saying was "It is hard to find a ladder to reach a satellite if something breaks down."


Of course NASA has much more of a budget than most of us will ever have, so we cannot justify going that far. But the question is how far do we want to go?


It might make sense for a critical employee to have two computers, both validated, and both loaded with the software needed, and both able to access the "data" on a file server. Both of these computers are ready to go. If one goes down, the employee uses the other until the first one is fixed or if necessary replaced.


A key point is that this planning takes place ahead of time. The proper analysis is made when we have the time to think about it. When we implement the redundant systems (and the necessary backups), we make sure everything is working (including file recovery).

Then, when we are in the middle of a critical project, and we have a crash, we implement our "switch over" plan, and continue working.

The hard question is how much insurance is enough. No real easy answer for that one!


Friday, May 15, 2009

Welcome to Mousley Consulting's blog

Hi all,


This is our first posting. I appreciate your time to read this.


Over the years (16 to be exact) we have been providing contract programming services for the biotechnology and pharmaceutical industry. We have programmed in a number of different languages ranging from Oracle PL/SQL to Microsoft .NET. We have covered a complete range of applications for data management departments including setting up Clinicial Data Management Ssystems (CDMS) and Electronic Data Capture (EDC) applications, programming Edit Checks, programming lab normal range applications, programming safety systems (eSafety Net and Clintrace), and many others.


We also have been involved in the metal industry for many years as my father owns Atlas Bronze Corporation.


Lately we have expanded into the financial arena. We have been involved with several companies attempting to raise money. One of my favorites at the moment is a Brew Pub in Hanover, PA.


We look forward to serving you an a number of different ways. Please email me at kirk@mousleyconsulting.com if you are interested in learning more.


Kirk