The importance of Project Management in an HL7 Interface Development project

Intended audience:  HL7 Interface Developers/Engineers/Analysts and IT management

This is part one of a two-part series, in which I’ll extol the virtues and considerations of project management in the world of interface development.  These are simply practical and day-to-day observations I’ve made after 6+ years in the trade. Part two to come in August 2013 and will be called: Tools of a Project Manager

Whether it is a large project, or just one ADT thread, the most efficient and successful projects usually involve someone who takes on the role of Project Manager (aka PM).

The players in an interface project will usually consist of:

• an interface developer for each of the vendor systems
• an interface developer for the interface engine
• someone who will be participating in the Testing on each end (that person is usually a user in the applicable department, such as a Registration Clerk who will enter ADTs, a Lab Tech who will enter Lab Orders and/or Results)

A diagram of this scenario would be:

Someone needs to manage the project, but who is the right person?  I find that the project is best served if the PM is the interface developer who handles the interface engine, if that person has the temperament and project management mindset.  Any person on the team can manage the project, but the interface developer for the engine is typically most knowledgeable about all points in the process.

Sometimes one of the Vendors assigns a dedicated PM to the project, but that is a rarity.

Interface development is such a niche that it is not common to find a PM within the hospital who is familiar with all of the steps involved in an interface project and who also has the time to dive into the project.

Fluid project management

I find that a good description for this type of project management is fluid project management as compared to rigid project management. In these types of projects the team must be very flexible because it's a small team and most team members have multiple responsibilities within their workplace. Because Patient Care comes first and issues often arise, the projects can be sidelined due to people on the project being called away.  Even scheduled go-live dates can change at the last minute, although that is not common.

The person in the PM role must be able to:

• Keep track of all of the tasks involved
• Track issues which come up
• Start the project momentum if it is stalled periodically due to conflicting projects or limited resources. Tip:  When this happens, it is very helpful to refresh everyone on the team by sending an informative email with the current status of the project including what has been accomplished so far and the next steps in order to get it back on track.

Managing a Project:

How does this take place?

• Gain an understanding of the project Scope – this usually takes place in phone calls or emails with the person who is initiating the project.  Use a checklist to make sure you cover all important questions.
• Make a project Task List – (a checklist of all of the basic steps)  I recommend using software to accomplish this task, such as MindJet MindManager, Excel or Microsoft Project.  I use MindManager because I respond best to the visual “mind mapping” aspect of the program. You may want to build a template with your generic tasks that you can use at the start of each project. Because Cloverleaf projects are slightly different than HL7Connect projects I use two templates.
• Have a kick off conference call with everyone on the team.
• Set a target go-live date (this is great, and it keeps the project moving. I always try to get a go-live date if it is at all possible. Sometimes it is not, due to many factors.)
• Schedule status calls (if needed)  but beware the “wait till the status call” syndrome. It is easy for everyone to wait till just before the call to look at their “to-do” list.   So it is helpful to check-in mid-week with people on the team who you know need to perform certain tasks before the next call, or the next step in the project.  Tip: The more calls, the more the project costs the client (the one paying the bills), so try to avoid setting up recurring Status Calls unless really needed to keep the project moving. Recurring status calls are best when there is a large team and it gets unwieldy to try to do all communication by email.  If you have a small team and a small project, emails and individual calls can be sufficient.
• I always try to send out a Call Summary after a Status Call which summarizes the call, but also contains a list of Action Items which need to be completed by each team member.  The Action Items section of the summary is invaluable to “get things done.”
• A thousand little issues will come up – keep track of them in your checklist.  I try to update that list as often as possible with little notes to remind myself of where the issue is, for example:
  • VPN won’t connect --> emailed Bob in Network Support --> Bob is setting up a call with the vendor because he says everything looks good in the firewall.
• It is beneficial that the PM be the one to gently remind everyone of the tasks they are responsible for.
• Make sure to thank everyone (say Goodbye) at the end of the project.  This is easy to remember, because based on the length of the project, you will probably have developed relationships with everyone on the team!  Healthcare IT people are usually very pleasant, professional and fun to work with. (I worked on a year-long project once, during which various members of our team experienced:  a new baby, the loss of a beloved elderly parent, a heart-attack, a home renovation and a hurricane.)

An experienced Project Manager is able to:

• Help resolve VPN or other Connectivity issues which can potentially derail an interface project for long periods of time – While not technically resolving the issue, the PM can push this to resolution much faster than just letting it resolve without intervention.
• Determine where the best place for modifications to the HL7 message should take place (at the Vendor side, or in the Engine).
• Identify end users who need extra explanation because they aren’t usually involved in this type of project.
• During the Testing phase, provide step-by-step checklists for various members of the team.
• Schedule Testing calls and guide the Testing where necessary.
• Share tips and tricks from previous projects with the Team.
• Move the project forward and to fruition.

There are times when a project is abandoned due to lack of project management.  All members of the team and the client are always grateful when the project moves and a successful outcome is achieved, despite roadblocks and technical issues which may arise.  Those roadblocks and technical issues can be project-killers without someone moving things along.

Healthcare management and teams truly appreciate not having to worry about how their interface projects are progressing, and Project Management can make that happen.

Different types of projects you may encounter:

• A hospital or healthcare facility with an existing interface engine. You are tasked with adding a new interface or modifying an existing interface.
• A hospital which is converting from one interface engine to another.
• A hospital which is converting from one main HIS system to another, which requires updating all of the existing interfaces to the new HL7 message format for the new HIS.
• A hospital or a healthcare facility which has never had an interface engine, and is now getting one... because they are very wise.

All of these projects greatly benefit from effective Project Management.  They can all be done without it, but... wow, the difference is profound.

Connie Zimmermann’s primary ‘hats’ are as an HL7 interface developer for HL7Connect and Cloverleaf and a trainer for HL7Connect.  She has been a happy member of the Dynamic Health IT team since 2004.

Dynamic Health IT, Inc.
504-309-9103

or visit our Contact Us page.

Dynamic Health IT offers Interface Development and Consulting for many popular interface engines, as well as Bolt-On tools for HITECH/ONC 2011 Edition and 2014 Edition Certification for hospitals and vendors. DHIT's ConnectEHR software was the first 2014 Edition product certified through ICSA Labs.

New Cloverleaf Functionality – Alerts

The Infor (formerly Lawson, formerly Healthvision, formerly…) folks have given us some nice enhancements to the alert functionality starting with version 5.8 of Cloverleaf (what I’m describing here is based on Windows version 5.8.5).

In recent memory, Cloverleaf has been able to automatically generate alerts under a variety of scenarios. Unfortunately, the built-in alert actions that displayed a message on the console or placed a message in the log/error files were not terribly useful. Sending automatic emails on Windows was challenging. The latest Cloverleaf makes the emailing much easier and adds some useful functionality.

Here is a list of my favorite alerts:

Alert Type	Send an alert when:
Thread status	A thread is up or down (or opening) for specified period of time
Error count	A thread has more than X errors
Outbound queue depth	More than X messages are queued up waiting to be sent
Last send	The last message we sent was more than X seconds ago
Disk % full	Just like it sounds
Last receive	The last message we received was more than X seconds ago
System CPU %	Just like it sounds
File change	A file is updated
Transactions/sec	A thread is processing > or < X transactions/second
Idle CPU %	CPU has less than X % idle for Y minutes

To assist with automatic email alerts, there’s a tool under Options, Site Options, Alert Configuration. It enables you to test connectivity with your mail server. The only gotcha with this is that when we ran the test, it told us the test had completed successfully but when we tried the alerts, the email didn’t go through. We had to change the settings on our Exchange connector to allow for unauthenticated or anonymous connections from the Cloverleaf server.

Fittingly enough, the default file for the alert configuration is called “default.alrt”. You can change this under the “Site Daemons” by using the “Alert Cfg” button but I’ve never bothered with that. I have a feeling that if you did change it, you’d have to restart the Monitor Daemon for it to take effect. Unlike other configuration settings in Cloverleaf, the alerts take effect as soon as you save the alert file. Not like the NetConfig, where you have to bounce a thread or process for it to become active.

There is a file called “alerts.log” that is useful for troubleshooting. Cloverleaf adds an entry to this file each time an alert fires. This file is in your site directory under exec\hcimonitord.

Here is an example of an outbound queue depth alert that will notify us when two or more messages have been queued up for at least a minute:

Note the %N references

Here are guidelines for setting up some of the common alerts:

Alert Type	Source	Source Count	Comparing	Comparing Blank	Duration
Thread status		any	!=	up	N min (usually use 1 for 1 minute)
Protocol status		any	!=	up	N min (usually use 1 for 1 minute)
Error count
Outbound queue depth		any	>=	# of messages	N min (usually use 1 for 1 minute)
Last send		Any	>=	# of seconds	N min (usually use 1 for 1 minute)
Disk % full	Drive to monitor	all	>=	% e.g. 80	Once
Last receive		Any	>=	# of seconds	N min (usually use 1 for 1 minute)
System CPU %
File change
Transactions/sec
Idle CPU %		All	<=	% (e.g. 5)	N min (e.g. 5)

 

The Alert Time Window used to have some “gotchas but now they’ve reworked it, so you don’t have to remember that 0 means Sunday.

Automatically Bouncing a Thread

The screen shot above shows an example of stopping and restarting a thread automatically. Thread_Restart.bat is a generic .bat file I created that allows us to pass the site, process and thread names so it can be reused. Contact me if you’d like a copy of the file by calling:

Jeff Robbins
Dynamic Health IT, Inc.
504-309-9103

or visit our Contact Us page.

Dynamic Health IT offers Cloverleaf Interface Development and Consulting.

2014 MU Attestation Requires 2014 Edition Certified System

While there is no requirement for vendors to certify their systems to 2014 Edition HITECH Certification in 2014, any Meaningful Use Attestation that is done for 2014 must be done on 2014 Edition certified software.  This applies to both Stage 1 and Stage 2 Meaningful Use Attestation. 

Table 5 in the HITECH Final Rule states the following for MU Stage 1 or MU Stage 2 in 2014:  

 All EPs, EHs, and CAHs must have EHR technology certified to the 2014 Edition EHR certification criteria that meets the Base EHR definition and would support the objectives, measures, and their ability to successfully report the CQMs, for the MU stage that they seek to achieve.

The 2014 Meaningful Use Attestation has been shortened to a 90-day attestation period in order to give vendors time to certify and implement their 2014 Edition certified system for their clients.  Hospitals will need to be on 2014 certified software and begin attesting by July 3, 2014 in order to have 90 consecutive days in the fiscal year.  Ambulatory providers would need to be on 2014 certified software and begin attesting by October 3, 2014 in order to have 90 consecutive days in the calendar year.  

All EPs, EHs and CAHs must also report on 2014 Clinical Quality Measures beginning in 2014.