We solve our customers’ mission-critical problems with innovative applications of technology and expertise.

News & Happenings


Project Manager’s Code of Conduct

Thursday, July 18, 2013 | By Kimberly Spada, PMP, MSHA, Senior Project Manager PMO Practice

ProjectManagers (PMs) who are PMP certified adhere to a code of conduct that promotes decency,good moral and ethical behavior, and honor. As defined by the ProjectManagement Institute (PMI®), a PM lives by this code and manages the projectwith the following key components:


Responsibility is our duty to take ownership for the decisions we make or fail to make, the actions we take or fail to take, and the consequences that result; in short, it is moral, legal, or ethical accountability.


An environment of respect engenders trust, confidence, and performance excellence by fostering mutual cooperation — an environment where diverse perspectives and views are encouraged and valued. For example, I have seen PMs and members of their team clash over different views on how to effectively solve a problem. Through respect to the team and client, the PM weighed the contrasting views, and ultimately decided to pursue a team member’s point of view, not their own. The end result was positive, and was successful for all sides involved.


Fairness is our duty to make decisions and act impartially and objectively. Our conduct must be free from competing self interest, prejudice, and favoritism. To piggyback on the example from the previous section, the acting PM in that situation not only acted with respect; they also acted with fairness. Although the individual had less experience in the industry, it’s important to consider anyone’s view – it could be a turning point or shortcut to achieve your end goal.


Honesty is our duty to understand and comprehend the truth while acting in a truthful manner both in our communications and in our conduct. We do not engage in or condone behavior that is designed to deceive others, including but not limited to, making misleading or false statements, stating half-truths, providing information out of context, or withholding information that, if known, would render our statements asmisleading or incomplete.

There may be situations or influences that attempt to force a PM to be unethical. Ethical problems may arise when decisions impacting an IT project/system are made without structured planning, reacting to one stakeholder without considering the needs of all stakeholders, or making uniformed decisions without discussion with the project team, end-users and/or the executive/project sponsor(s).

PMs are obligated to be honest and discuss any issue or risk that has an impact to the project, including the scope, timeline, key deliverables, etc. Changes to a system’s design and build are frequent occurrences in IT projects and a PM must adhere to a change management process to objectively evaluate all changes, the relevance, priority, and most importantly, the impact to the system. All changes to the design and build should also include an evaluation of the system testing, user training, cost-benefit analysis and overall approach to approving the change. Appropriate approval from the executive/project sponsor(s) is also critical to ensure they are involved with the process. Decisions must be collaborative and fully communicated to the stakeholders as well as documented thoroughly.

An experienced PM understands what it takes to manage a successful project and the obstacles that may impact the intended outcomes. Following the project methodology to manage all phases of the project ensures that any ethical issues that may arise can be mitigated and allow the project to move forward to meet the intended goals and objectives.

PMP-certified PMs are obligated to follow the code of conduct. It may not always be a comfortable position to be in and the PM may need to disagree with the majority at times. However, it is always about doing what is right, honorable, and fair. This approach will lead to a successful project implementation and serve as another reminder that we must all have core values that distinguish us from being mediocre.

See comments »

Texting, Emailing, and PHI… Not Really a Good Mix

Friday, June 21, 2013 | By Gaylen Heacock, Consultant, MEDITECH Practice

As many consultants, system analysts, and IT staff would agree, there is a significant amount of community grumbling about healthcare IT. Lately, these grumbles seem to be related to the inability of “doctors to communicate with staff via cell phone and/or email.” Most of us have witnessed this, and the conversation quickly goes to a general statement, such as “I can get the football stats and watch parts of the game on my phone. I can get my bank statements on my phone. Now, why can’t I get a simple lab test result sent via SMS messaging?” These conversations come from physicians, from other healthcare workers, and from the general public.

If only those grumblers knew about texting and HIPAA. Articles such as “Texting is Not HIPAA Secure” (Posted: 17 Apr 2012 10:20 AM PDT [EMR & HIPAA]) and other related articles describe actual HIPAA lawsuits resulting from compromised emails sent containing patient PHI. Websites and blogs dedicated to answering commonly asked questions about encrypted email systems and patient portals are available online and are easily accessible, even via smart phones.

Yes, the technology is there and very easy to use with a quick text sent from one healthcare processional to another – it saves time; the phone and application are readily available. This basically seems innocent and with no ill intent on behalf of the person sending the information.

Certain questions then surface – did the recipient get the email/ text? Did the recipient keep the email/ text or delete it? Even deleted, the data is stored on servers for unspecified lengths of time. If an email or text is sent, who has access to it? Did the email get forwarded at a later date to others? Did anyone print the email to hard copy and is it now lying around on a desk? All these questions need to be considered and some thought process applied on the part of the “sender.”

We are all ambassadors of our profession and we need to be equipped to discuss the high demand for these technology uses in patient care and communication. These are some of the enhancements that can come with the EHR, and many hospitals and clinics are hard at work to get there, as well as to meet the Meaningful Use Stage I initiatives (one core objective - provide patients with an electronic copy of their health information upon request).

Some hospitals have arranged patient portals that work through their healthcare vendor to provide safe and compliant access to many patient requests, such as lab and radiology results, discharge summary, medication lists, and other communications related to their care. The patients are asking for this “simple” communication and the physicians want the ability to communicate with other health care professionals as well as meet their patient’s needs.

Most people know that they are protected with HIPAA laws and standards that protect the privacy of personal health information. They receive printed information on this when they interact with a healthcare facility. There is an expectation that everyone’s personal health information is protected and private; that expectation is not necessarily “why can’t my physician email me the lab results” – yet. The majority of the general public does not understand the complex work that providing this service will entail for their providers, while simultaneously keeping the data protected in compliance with HIPAA.

As technology continues to move forward quickly, it is important to consider that not all facets surrounding technology in healthcare are moving just as fast – i.e., healthcare itself is moving slower and should be carefully calculated into the equation to ensure all compliance is in place.

See comments »

Building Test Plans 101 - Part 5 - The Finale

Monday, June 03, 2013 | By Patti Trail, maxIT-VCS Allscripts Consultant

​With all the data collected and arranged, the next thing to consider is how you will store the information. There are many formats that can be used, including Microsoft Word and Excel. I typically use these more for unit testing. For functional and integrated system testing, I use an ACCESS database with three main tables. I do this because of the flexibility of the database, which also makes the test plans highly reusable for multiple initiatives.

The three main tables for ACCESS are the patient table, step table, and step detail tables.

The patient table stores all the information on the patient that might be needed to register that individual, as well as additional data that identify what type test plan this is being used for. In this table, patient name, MRN, visit number, patient type, sex, birthdate, insurance information, and guarantor is stored. A label and notes fields are also utilized. The script label could be “Inpatient ICU” or “Outpatient to Inpatient” and notes could contain other factors such as “Test patient will have multiple visits to validate that visits combine if within 3 days.” This data could be included in the header you create when building reports. Flags can be included for reporting so that you know that this patient is for RIS/PACS testing. A query could be built for the report that pulls all of these patients by the flag. A patient could have multiple flags that are set and be included in many test plans.

The step table includes the items from the outline. This would be a one-to-many relationship to the patient. Admit Patient, Radiology, Discharge, Code, and Bill might be the steps to include. Additionally, include cycle and step numbers so you can arrange the steps within cycles as necessary. Flags to include steps are also helpful. As you build your tables and patients for multiple systems, you will be adding various options. For example: If you are working with a CPOE system, you could have laboratory, nursing orders, pharmacy, and many others. The flag would allow you to exclude these when only doing the radiology upgrade.

The step detail table is the workflow to execute during your current step. This would also be a one-to-many relationship. Data included in this table could be who is responsible for this step, initiating system, receiving system, whether a charge will be produced, and expected results. A flag to include or exclude this step can be added as you might not need all steps for every initiative.

Additionally, there are other tables that can be added, such as which systems are best for initiating and receiving data to help users choose correctly. Queries to use your selection criteria for reports and the reports themselves will need to be built, but can be recycled for many different test plans.

You have the tools, now it’s time to build your test plans.

See comments »

Building Test Plans 101 - Part 4

Monday, May 20, 2013 | By Patti Trail, maxIT-VCS Allscripts Consultant

With an outline in place, the details needed to make the test plan complete can now be filled in. This can lead to a question one might have thought should come earlier … “How do we do the task?” This question can sometimes arise earlier in the process. However, people can get overly caught up in other processes, which can lead to them not considering future problems. It is now time to ask that question.

One thing to consider, again, is what kind of test plan this is being developed for. For example, if the script is for RIS/PACS, how you register the patient might not be as important to you as their specific location. The details may be less precise; because how you track the radiology portion is what is critical. However, if you were building this to install a new registration system the content would be a lot more important. You might need to schedule the patient first, and then collect the pertinent demographic data along with insurance information, guarantors, next of kin, etc. There can

be multiple ways to admit; for example, they may go to an outpatient location beforehand and then be admitted as an inpatient, or they could go directly to an inpatient bed. These details are the final piece in building the test plan, and should have been identified as critical business functions of the system. Now we are getting the precise steps we have to perform to successfully complete the process and what measurements we would use to assess this.

An additional benefit of this methodology is that at this point, if the “how” cannot be truly defined, a red flag should go up that a workflow needs to be developed to fix the problem. For example, after ordering and getting the results of a radiology exam, how will the user reconcile that all of the exams were billed? If the question of “how” cannot be answered for testing, then the end user will not know how to do this important production step which could potentially be costly if missed.

See comments »

Building Test Plans 101 - Part 3

Wednesday, May 15, 2013 | By Patti Trail, maxIT-VCS Allscripts Consultant

Now that we have a thorough assessment about the scope of what needs to be tested and the critical business functions that need to be performed, we can write the basis of the scripts. We employed the “who, what, when, where, and why” tools a reporter uses to collect the information. Now we utilize outlines to help guide the building process. An outline is a great tool to help organize all the information we have accumulated and put it in order.

For the purpose of discussion, let’s use the RIS/PACS upgrade as an example. We have learned that it needs to include inpatient and outpatients registered at various locations. Orders will be initiated in the physician order entry system, except in a few outpatient locations. Testing should be done in various modalities with the results and image links verified as a successful result, as well as charging for the exam and supplies.



 Admit the patient in registration system

 Perform radiology test

• Order in CPOE

• Result in RIS/PACS

• Verify result and image link in CPOE

• Send charge

 Discharge patient in registration system

 Code in coding system so bill can drop

 Bill from accounting system

• Verify the charge posted correctly

o Acute Care

 Admit the patient in registration system

 Perform radiology test

• Order in CPOE

• Result in RIS/PACS

• Verify result and image link in CPOE

• Send charge

 Discharge patient in registration system

 Code in coding system

 Bill from accounting system

• Verify the charge posted correctly


o Clinic 1

 Register the patient in registration system

 Perform radiology test

• Order in RIS/PACS

• Result in RIS/PACS

• Verify result and image link in CPOE

• Send charge

 Discharge patient in registration system

 Code in coding system

 Bill from accounting system

• Verify the charge posted correctly

o Clinic 2

 Register the patient in registration system

 Perform radiology test

Order in CPOE

Result in RIS/PACS

Verify result and image link in CPOE

Send charge

Discharge patient in registration system

Code in coding system

Bill from accounting system

• Verify the charge posted correctly

Once the outline is in place, the details can be filled in to construct the complete test plan.

See comments »

Building Test Plans – Part 1

Wednesday, January 30, 2013 | By maxIT-VCS Editor

With the help of a roadmap, creating test plans is no longer a daunting undertaking.

The creation process starts with the basics: who, what, when, where, and why. This process will be applied over and over until you get down to the detailed description.

The first iteration applies to the overall project.

  • Why is this testing being done? Is it a new system build or an upgrade? Is it for validating new functionality?
    • This information will help determine the scope of testing. A new system build needs more detailed larger-scale testing, while an upgrade will require regression testing to ensure nothing is broken during the upgrade­ (as well as testing new functionality). Details are important. The greater the details about what the test plan is intended for, then the better prepared you will be to ask key questions on building a good script.
  • What is in the test plan? Is it a day in the life of a patient? Is it only a piece of the day? Registration to charge validation?
    • No matter how many people are involved, there needs to be one vision of the end product that is agreed upon by everyone.
  • · When will this test plan be used in the lifecycle of the product?
    • If it will be used during the build, it might be a unit test plan. If it is acceptance testing, it could be an integrated system test plan.
  • · Who will be involved?
    • This question can be interpreted many ways, such as: Who will be performing the testing? Who will be building the test plans?
  • · Where? In what environment will testing occur?
    • Ensure the correct environment is used – This is important in making sure the system is properly prepared for the specific environment.

All these questions help set the expectations of the test plan and this in turn will make the building of scripts more successful.

See comments »

Building Test Plans – Part 2

Thursday, January 10, 2013 | By maxIT-VCS Editor

By thoroughly assessing the scope of what needs to be tested, you should have a list of systems to include. This list is now the basis of our next series of who, what, when, where and why.

For each individual system that is included in the test plan, the user needs to identify the critical business functions that the software provides. Applying the five important “W’s” while you outline these functions will allow you to think of all the important criteria to include, especially when you create the scripts to ensure you adequately test each aspect.

For the sake of discussion, let’s dissect some of the critical business functions of a RIS/PACS system.

Receiving ADT:

· Who will be the patients for which the data is sent? Inpatients versus outpatients.

· Where are they being seen? This would be the locations that patients need to be registered to.

· What kind of messages do we receive (admits, discharges, cancels, transfers)?

· When these messages are received, how do they affect the status of the patients and their orders, and why?

Order Exams:

· Where will the orders come from? Does another system send the orders to RIS and/or can they order them from the RIS system itself?

· Why would we have to be able to do both?

· Who does the ordering?

· What kind of orders will there be? The different modalities of radiology may have different worklists that need testing.

· When does the order need to be received, performed, and resulted/completed? These will need to be tested to see if the order becomes active at the specific time it should become active.

Result Exams:

· Where will the results be sent?

· What will be sent? Will it be the report and/or the images themselves?

· Who needs to sign off on the results?

· When can we modify the results?

· Why would we allow modifications?

Apply this to all of the critical business functions, and the picture of what needs to be included in the test plan becomes clearer. Then comes the next part; building the actual script.

See comments »

Changes in Medical Transcription: Help or Hinder “Health Analytics”

Monday, October 08, 2012 | By Doug LaVerdiere, VCS Epic Consultant

In healthcare, transcription services have been in use for decades. Physician’s notes, letters, and reports were dictated, transcribed, and then finally added to the patient’s chart or sent to a referring physician. Today, technology is evolving and the process of medical transcription is changing. Considering the rapid progression of technology in healthcare, what is the new role of medical transcription and what are the challenges and benefits it has created?

In years past, a physician would dictate their notes, letters, and findings into a recording device usually the size of a deck of cards. Some devices would store the information on tape, while others housed internal memory. From there, the voice files were transferred to a dictation server where a medical transcriptionist would write out the recording onto a document or appropriate clinical system. The dictation server has the capability of creating a work list for the transcriptionist. This allows them to sort the files by priority, date and time of dictation, physician, or department. Once the transcribed dictation is complete, it is sent back to the physician for final review. This antiquated process was long and arduous, now there are more effective methods including voice recognition systems (VRS).

VRS’ have made great strides in recent years, making them a valid option for many healthcare systems. VRS’ require the user to read sample documents to configure the program and recognize the user’s voice pattern. One benefit of using a VRS is that dictated text is viewable during the process making it easier to notice mistakes up front instead of post review.

Point and click (PAC) transcription is also a viable method for medical transcription. Many specialty specific applications in cardiology, mammography, obstetrics, vascular, and some EHRs, have the ability for PAC transcription. PAC transcriptions work by creating a document from clicking on relevant phrases to the study or patient encounter. Predefined templates are used to reduce the number of phrases used by the physician and phrases are categorized to make the selection process easier. A benefit to using PAC transcription is the option of performing data mining. A physician could gather data on how many times a certain phrase was used on a particular patient record. Creating health analytic reports would be a much simpler process, and the consistency among the reports, make it easier for the referring physician to understand. PAC’s may create clunky documentation, though. For example, in documenting a routine mammography screening, a radiologist would not typically make diction on left and right breasts independently if they both were normal, but in a PAC they would be separated into individual phrases.

A user doesn’t always have to choose between VRS and PAC programs; some EHR’s have integrated VRS and PAC transcription into their product. For the EHR’s with integrated VRS, special attention may need to be given to the configuration. When a system has multiple users, it may need to be tailored for each one, or there can be problems with voice recognition. An EHR with PAC transcription is often more flexible and successful with physicians than a VRS system because PAC transcriptions are more customizable. They can be adjusted by specialty, office, or even by the individual physician.

As healthcare systems adopt different technologies medical transcription will adapt. Instead of dictation it may function as the editor or reviewer of the VRS transcription. This is not a new function. Programs have always reviewed dictation and made physicians aware of inconsistencies in reports. Recently, one Midwest healthcare provider boasted 53% of radiology dictations were being self-edited by the radiologist. While this appears to be a success, good practice is to have someone besides the dictating physician review the reports. Does it make financial sense to have a physician editing their work when their time could be better utilized elsewhere? Healthcare systems will need to carefully review the role and uses of medical transcription as technologies evolve, weighing the benefits against the burdens.

See comments »

So Many EHR Report Writer Questions…We’ve Got Some Answers

Friday, August 24, 2012 | By Rob Sanders, VCS Allscripts™ Consultant

The simple job of “Report Writer” can be labeled as a variety of other job titles, creating additional confusion, but all the titles essentially have the same responsibilities: to gather pertinent data and present it in an easy to read report.

I’ve been a Report Writer for a number of years and I’ve worked in several different industries. Regardless of the type of company, the task is always the same: to write queries and produce results. A variety of tools are used to finish projects but the outcome of the project may depend on the availability of the tools accessible at the local /corporate level. Data is collected and formatted to be presented in a way that allows managers, supervisors, doctors, and nurses to make timely decisions with ease.

What Do Report Writers Do? Report Writers will interface with end users to determine the report’s specifications and needs. Sometimes the specifications are gathered by an analyst who supports a variety of departments (usually the subject matter expert), but on occasion the Report Writer will gather specifications directly from the report requester. This initial gathering of specifications is often very important since it outlines what question or questions the report will be answering. Each report process follows a path of collecting data, database searches, grouping, sorting, formatting, and ensuring the specifications are correct. The hope is that the end result is useful to the requester and users. The more detailed and accurate the specification, the faster and more precise the report development results will be.

What Don’t Report Writers Do? A Report Writer doesn’t decide what pieces of information are important enough to collect in a report. They won’t be able to tell you what type of data to collect or questions to pose in a query. Direction is usually given from a Project Manager or other corporate leadership figures. The Report Writer does not decide the reports format or presentation of data. These are important decisions made by clinicians, nursing supervisors, and management. Electronic Health Records (EHR) systems will have most of the basic format setup preloaded. However, every project has additional modifications or requisitions to suit a particular company’s workflows and policies.

Writing a query, or multiple queries, is the most detailed and tedious job that we do. It is done to gather answers and data for an EHR. Some queries run smoothly on first try, while others take much tweaking and rewriting. Once a query is written, a testing process takes place. In an ideal world, all sites would have access to a replicated database to use for testing the results of our newly written queries. Accuracy and speed, along with compatibility within the system, is noted. Periodically, a query will run beautifully and produce an answer within seconds in a “test” database. However, when run in the replicated Production database, it might take hours to complete. Troubleshooting is often a necessary evil and can take undetermined amounts of time, but it is almost always part of a project. Our dream of loading the new result into any “Production” environment is achieved only after thorough testing, applicable security, and “buy-off” by the user.

One might think that a Report Writer’s job is done once the reports are written and implemented into your program. In an ever changing world, corporations always have new needs, databases expand and change, and periodically programs will “break” an old query or report. New reporting will always be needed, and the latest features of your system may need unique customizing, which is why you need a Report Writer on your side.

See comments »

Have You Ever Accessed Your Personal Health Record?

Monday, July 16, 2012 | By Kevin Patton

Just about every person born in the United States has been seen by a doctor, which means they have a health record. If they have a health record, then they have an electronic health record (EHR) of some sort as well. Under the HIPAA privacy rule, each person has the legal right to view and obtain a copy of their health record from their physician and/or hospital, but just because someone has the right to do something, it doesn’t mean they will do it. In fact, most people have not accessed their personal EHR. But, why? Do we just not care enough to look at our health record, or are we too afraid to see what might be on it?

To combat this, the ONC for Health IT has launched a challenge to the public. They are asking those willing to create and submit a “short and compelling” video about how obtaining access to their health records and checking the information can help make sure patients or loved ones get the best care. They also want you to reveal how you got access to it, and maybe what you found when you took a look inside.

Participants can register here. A standard video recorder or smart phone with a video function is all that you need. Videos should be less than 2 minutes long and the top 5 videos will be awarded; the 1st place video prize will be a sharp $3,000 and your story could appear on ONC’s website.

So, what are you waiting for? Go out there and learn a bit about your past and discover some things you may have never known before. What do you think you’ll find?

See comments »

Page 1 of 2 pages  1 2 >