‹ Home
Exported

Applied Informatics Team Training 2018

Amanda Masters, Director of Workforce Development at CSTESarah New, EpidemiologistCynthia Yen, EpidemiologistValerie Goodson, Workforce and Fellowship Coordinator at CSTEJessica Arrazola, Director of Educational Strategy at CSTENancy Barrett, Epi 4/PH Informatics SpecialistErin Holt, TDHRita Altamore, EpidemiologistNatalie Marzec, Zoonotic Disease Unit Manager, CO DPHEKathy Turner, Deputy State Epidemiologist at IDTracy MillerElandis Miller, CSTEPeter Krombach, Health Informatics EpidemiologistAlastair MathesonRosie Glenn-Finer, California Perinatal Hepatitis B Prevention Program Coordinator +75 others
Posted by Kelley Chester ·

Webinar 1 - Case Analysis #1

As part of yesterday's webinar I would like to pose a question for you all to consider and comment on.  Please review and comment.  Also, if a situation similar to this has happened in your agency, please tell us about your experience and what were your lessons learned.

Scenario: The leadership in your organization has allocated funding to purchase a new disease surveillance information system.  You are asked to lead the project for your program.  What are some of the activities and first steps that you would recommend to your leadership and your IT department?

** Remember to comment on this thread and avoid starting a new discussion post.  Thanks!

Comments & Events

Natalie Marzec, Zoonotic Disease Unit Manager, CO DPHE Natalie Marzec, Zoonotic Disease Unit Manager, CO DPHE
I would recommend that the first step be stakeholder interviews to determine what we need the system to be able to do. Stakeholders should include someone familiar with ELR, local health department epidemiologists who use the system, the state health department epidemiologists who use the system, someone in the state health department leadership who is familiar with grant deliverables that the surveillance system might help produce, IT staff who are familiar with what we are allowed to do tech-wise, and someone familiar with surveillance systems that are already in place that might give us ideas or that could be adopted fully.
Kelley Chester 👏
Notified 87 people
Mike Schardein, Health Policy Specialist II Mike Schardein, Health Policy Specialist II
Here are the steps that I feel are very important when approaching the Scenario listed above,  some of this from experience weren’t followed and others are common when producing an RFP for say a new application.  1.) A department wide surveillance application assessment needs to be done asking questions like, how is the application currently funded and supported, what is the lifespan of this application, and lastly how easy is to upgrade said applications.  For me I see such importance in pooling IT structure funds across department program areas for application maintenance, upgrades, etc.  I also see value in purchasing applications that would work across program areas so data can be housed and referenced from one central location.  This next point I also feel is important, who in your government will control say the hardware like servers, is there a COT type management structure, who has the authority to hire say DBAs or business analyst/application analyst positions.  If this structure is not well defined from experience at least in Kentucky, the Department for Public health has gotten the shaft.  

Kelley Chester 👏
Notified 87 people
Nancy Barrett, Epi 4/PH Informatics Specialist Nancy Barrett, Epi 4/PH Informatics Specialist
Been there! What we've done. Who is the management champion for this project? Who will be the manager you can go to with big issues? Identify your project team with both business and if needed IT representation and a project manager (PM). Who is the business lead? Who is the IT lead? Will the folks identified as part of the team be allowed to serve on this team as needed to complete this project? Use any one of an number of existing PM tools to help. Convene a small group (or use your project team) to assess what systems are out there already and which other states (in our case) are using them. Put together a working group of stakeholders (or use project team plus others) as mentioned to identify the business requirements (high level), including integration with other systems such as ELR, vital records, etc. and also the functional requirements (how fast system needs to respond, web enable, security, etc.). Find out from IT any limitations on what they can support (must run on certain server types, can be cloud-based, etc). Once you have a list of these requirements, you can reach out to other states using the systems and do a survey of their experiences. Depending on how your state/jurisdiction purchasing is conducted, then you would put out an RFP/ITB with the document that contains all of your business requirements and functional requirements. You should also set up your scoring against these requirements on how you will score responses. In our state, all of this must be passed through central purchasing for approval and other items they need to include. You can also find out about other purchase options, such as using GSA or piggy backing off another state's contract. These options may shorten your purchase time. If another state/similar jurisdiction has gone through this same process recently, you can use their RFP docs as a template for yours (we did). Of course, need to start defining your other project areas like communications, risk management, scope, timeline, budget restraints. The scope should be in your RFP documents, the timeline and budget should be defined as close as possible (high level) and the other items can be draft.
Notified 87 people
Sarah New, Epidemiologist Sarah New, Epidemiologist
TGIF!  Here is California's team input:

  • With IT department’s help, research specs for possible surveillance information systems (cost, length of support agreement, liaison/training staff needed, etc.).  
  • Interview other State health departments and external partners with different types of surveillance systems to identify pros and cons of non-homegrown systems and leverage different system vendors (e.g. Atlas, Maven, etc.).
  • Reach out to stakeholders e.g. local health departments, labs, especially staff who would be directly impacted to assess whether there would be support for new system.  
  • Create focus groups with the previously mentioned end-users and conduct a needs assessment to ensure that the expected outcomes of the new surveillance information system are valuable to each stakeholder.
  • Outline possible challenges to implementation (cost, stakeholder buy-in, converting from current system to new system, training, etc.) as well as benefits (e.g., better case management modules, etc.).
Notified 87 people
Kelley Chester Kelley Chester
These are all great insights and suggestions!  Engaging the stakeholders as well as engaging your leadership and/or champions in the organization are all important steps.  Does anyone have any further insight?

Thanks for the responses!
Notified 89 people
Andrew Smith Andrew Smith
Louisiana went through a transition to a new disease surveillance system several years ago, but the scenario was a bit different than the one presented here. Due to budgetary reductions and price increases, we were no longer able to sustain the cost of our surveillance system, and were basically forced to go with the cheapest available option; thankfully, the NEDSS Base System (NBS) contracted by CDC was available at no cost other than staff and bandwidth to implement and support the system. So there wasn't really any input to be gathered or steps to decide which surveillance system to choose, but rather how to make our only choice work for all of our stakeholders. Some of these steps included:
  • Identifying key staff members to participate in the implementation and subsequent maintenance of the new system, since it would no longer be run by a contractor.
  • Identifying IT infrastructure, such as servers, networking, and portal access, to house the new surveillance system and make it accessible to employees and external partners.
  • Customizing the system to make the transition minimally disruptive to epidemiologists, external data entry partners, and other users. We also consulted with epidemiologists and other users to optimize the configurations to our existing workflows and modify workflows as necessary.
  • Making NBS fit into existing program data flows, including datamarts, QA reports, and grant indicator measurement.
In an ideal world, with fewer financial and time restraints, we would have been able to have a more intentional process of requirements gathering, planning, and implementation; as it was, we were basically flying by the seat of our pants and making our only option work however possible.
Notified 89 people
Michelle Barber, Interoperability Director Michelle Barber, Interoperability Director
Oregon's thoughts: Funding allocation to purchase a new disease surveillance information system should have come after stakeholder involvement to determine that a new system (or system upgrade) was needed, not before. In addition to stakeholder involvement described by others, the current system’s strengths and limitations should be reviewed. As stewards of public funds, we should consider not only what it would take to stand up a new system, but also what it would take to migrate from and decommission the old system, and to make sure that current operations are not interrupted. 
Notified 89 people