Tips for Customizing your EHR System

Good afternoon, everyone. Welcome to all of our participants. I'm Jason Goldwater and I work for the National Human Research Center. I'll be the moderator for today.

I would like to introduce Michael Banyas from the office of Health Information and Technology and Quality. Michael? Thank you for joining us today, for another OHIT-sponsored webcast. In response to your feedback from many of you, we have asked today's speakers, Mr. Roy La Croix  from PTSO of Washington State, Mr.

Joe Dawsey and Dr. Persharon M. Dixon from Coastal Family Health Care in Mississippi, and Ms. Susan Chauvie from our community health information network, OCHID, also known as OCHIN in Oregon, to present tips for customizing your EHR system for your health center.

The target audience for this presentation is those health center grantees who receive capital improvement program or CIP funds to purchase electronic health records. Today's session is one of many efforts our office is making to better provide assistance to HRSA supported programs on effective adoption and use of health information technology. Additional efforts include structuring and HIT technical assistance center to coordinate HITTA's resources from HRSA. And with outside partners in the development of web-based toolkits, customized to meet the needs of HRSA's many program grantees.

Teleconferences such as this one will be just one of many resources that will be made available to you through the CA Center. Our overarching goal is to provide the type of assistance that will empower you to address issues related to the planning, implementation, or evaluation of HIT applications, and become educated HIT consumers. I hope that you find the following presentation useful and interesting and will participate in the question and answer session immediately following the presentation, as well as an online poll, which you can give us feedback on the presentation. Your comments and suggestions will allow us to be responsive to your specific needs and facilitate a broad sharing of HIT knowledge among HRSA-supported communities.

In addition, later this afternoon, a discussion board will be open on this topic on the HRSA health IT community. A disclaimer: HRSA would like to add is that this webinar is intended to serve as health assistance resource based on the experience and expertise of independent consultants and HRSA grantees, and its contents are solely the responsibility of the authors and do not necessarily represent the official views of HRSA or FISIK. We would also like to note that an EHR system purchased with ERA funds, grant funds, must be certified by an organization and recognized by the secretary of [audio distortion] and the purchasing process must be executed consistent with federal grantee procurement roles. I am now pleased to further introduce you to our speakers.

First is Mr. Roy La Croix from PTSO of Washington, who is the executive director. Mr. La Croix offers 17 years of senior IT leadership for health care education, government, and research.

As executive director, Roy led and directed the growth of PTSO from a startup application support organization to a successful and sustainable community health center supported services company. Roy directed the development and implementation of new systems and critical support services for PTSO membership. He is also a member of HIMMS and the National Association of Community Health Centers, in which he serves as the co-vice-chair for the NACHC's network task force, which addresses issues related to the growth and development of health center control networks. Roy earned a masters in business administration degree from St.

Mary's College and a bachelor's of science and business administration from the University of Phoenix. Next is Mr. Joe Dawsey, the Chief Executive Officer of Coastal Family Health Center in Biloxi, Mississippi, and who has been in this position for the past 13 years. He is also the Chief Executive Officer of Green Area Medical Extenders in Leakesville, Mississippi, and has held this position for the past nine years.

Prior to becoming CEO of Coastal, he was the executive director of family oriented primary health care in Mobile, Alabama. He obtained his bachelor's degree in environmental health from Troy State University in Troy, Alabama, and a master's in public health from Tulane University in New Orleans. In addition, Mr. Dawsey is joined by Dr.

Persharon  Dixon, who is the medical director of Coastal Family Health Center, a conglomerate of seven clinics and two global medical programs. She is a board-certified [audio distortion] physician, executive experience, and is intimately involved in the technical change process occurring at Coastal Family Health Center. Dr. Dixon received her M.D.

Degree from Morehouse School of Medicine, and completed her pediatric residency through Emory University's health systems, both in Atlanta, Georgia. She also obtained an MBA focused on health care from the University of Tennessee at Knoxville. Lastly, we are joined by Susan Chauvie, from OCHIN, who is a nurse with over 25 years of clinical and administrative experience in a wide range of health care settings, from both private and public health environments, and has served as OCHIN's Chief Clinical Officer since 2004. She has a bachelor's of science degree in nursing from the University of Portland and a master's degree in public administration and health administration from Portland State University.

I would now like to turn the webinar back over to NORC. Thank you so much, Mike, for that introduction. What I would like to do is just go over some logistics in regards to the webinar itself, and first off I would like to thank all the attendees for joining this webinar. All the attendees would be just listening to the presentation through their audio speakers, and if attendees do have any questions to the presenters, you could certainly use the WebEx chat and the Q&A feature, and we would really appreciate it if you could select All Panelists in the drop-down, just so all the presenters do get to see your questions, and then we will address those questions during our Q&A session.

And also, we would have a feedback response form at the end of the webinar. We would really appreciate if you could take the time before you leave the webinar just to complete that, just so we can use your feedback, just to improve future webinars. With that, I would hand it over to our first presenter, who is Roy. Roy, go right head.

Thank you, and good morning to everybody. Thank you for allowing us to present today, and welcome to all the attendees. Quick background on PTSO of Washington is that we are a health center controlled network, as acknowledged by HRSA, and PTS Host supports five community health centers in Washington state. Overall, we support 350 providers, and 200,000 patients.

We are also members of the regional extension center for Washington and Idaho. We're a technical partner for that organization. We're also have -- work with the Beacon Community's grant, which was awarded to a participant in Washington State. Some of our health centers will participate in that, and we're also part of the leadership team for the health information exchange for Washington state.

We run the NextGen platform, and we implemented NextGen EHR in 2006. We started with the practice management platform in 2005 and then went on to the EHR platform in 2006. What we'll talk about today are the pros and cons of customizing your EHR. There's good points and bad points to it and we'll explain that today.

We'll talk about how we've implemented and use our process and governance and how it helps us, and then we'll talk just briefly on some of the customizations we've done that we found have brought us a good deal of benefits. So the key aspect that we're trying for when we do our customizations is -- the key question is, will it bring better care to the patient, and that's our goal, to always enable better care. Will it improve their outcomes, will it help the clinicians in what they encounter in their interaction with the patient, will it give them the information they need, at the right time, at the right place? We also focus along then of improving our functionality. So we have programs such as breast and cervical health programs, which is a Washington State program.

We also improved the functionality and look at how do we improve things such as disease management, and then chronic conditions such as diabetes and HIV. Another aspect of why we would take on customizations is to improve reporting, and specifically for a lot of our funders and for compliance. Like many of you, we support local, state, and federal programs. Each of them brings sometimes unique and varied reporting requirements, and compliance issues.

So we will typically modify our EHR to capture specific majors and metrics that may not have been readily captured by the product set, and then we'll build in around that typically easy reporting that will funnel out the information to the appropriate agencies. And then also, always to meet the provider needs. We'll talk a little bit more about this later, but sometimes the products we receive or some of us may be running might have opportunity for improvement, and typically that will take the form of providers sharing with us their perspective on how many clicks it takes to get to the information they need. So we always strive to improve their workflow, and some of our customizations will typically take the information they're seeking and move it from being one or two clicks away and actually put it in the encounter workflow that they're working on.

So it appears at the right time, at the right place. Some of the challenges that we've run into for customization, and things to consider when you look at whether you want to take on a large number of customizations -- one is maintenance. There's an ongoing expense and cost and time and effort as you make changes. In many cases you'll need to add a greater depth of expertise within your organization.

So you'll probably need what we found, to move beyond simple application support, and really bring to bear and engage and typically hire as FTE a development staff. And so we'll bring on expertise around how to develop in our case the NextGen template, and that also leads into database -- SQL database challenges for us. We found we needed in-depth database expertise to create the scripting that needs to take place, and to really merge the user interface -- in our case it's the template set -- to really merge that well into what was going on with the database, and that expertise is not entry level. So we at PTSO carry very senior template developers and senior DBAs.

There's also an issue around cost. Cost, we found, there's a rule of thumb out there in the development world and we found it basically holds true. For every dollar that you spend on developing a change or a customization, you can readily expect to spend a dollar over three years to maintain that change, and that comes in the case of developing good, solid test platforms, developing your infrastructure, developing tests, training, and development platforms so you can create and then migrate your customizations into production, and then we found also, again, the staff time to do that. Additional considerations that you would want to consider before embarking on expensive customization is typically greater testing required when you look at upgrades.

So when your vendor comes out with a new product or an upgrade to a template set or their base application, in our organization, we have a significant number of customizations to test and develop around. So we find that our testing criteria and our testing process and methodologies are much more extensive than if we simply implemented a base level product. And we also found that sometimes after our development, and we have a working customization, the vendor may make a subtle change in the background that now takes our nice customization, which was an asset, and it may turn into a bug at some point, and we've ran into that a couple times. So again, that really emphasizes the need for testing.

And then occasionally, but not very often, we'll find something that we've done may interfere or change -- have unintended consequences around a new vendor, an enhancement that they intentionally implemented. I'll also say, process and governance. One aspect when you take on large-scale customization, and a change that needs to occur within your technology organization, is you move from being a service provider and an organization that delivers services -- you really need to take the next step and become a software development shop, which is a big change for many organizations. It is a very different mindset and a very different approach to simply maintaining a product and delivering that service.

Our experience showed us that we had to develop very quickly a full software development life cycle. We did some background -- PTSO originally made well over 300 changes in customizations to the NextGen product set, and so that large scale change over a couple years, again showed some holes we had, and we need to develop a predictive and dependable way of creating development and creating change, and managing it for an entire life cycle, not simply making a change, calling it good, and moving on to the next one. So that's a real change control and software development life cycle. Another thing we've found, and we embrace, and we highly recommend, is that changes really need to be driven by your clinical environment, by your clinical users -- the providers, the physicians, the nurses, the MAs, front office and back office staff, all need to drive the change.

It absolutely cannot be driven by the IT staff. Just like the EHR project is not a technology project, same as software development around an EHR. It is really an end user project. At PTSO, we really embrace and frequently our mantra is always, we don't drive the bus.

Our users drive our bus and we support it, and we're the arms and legs of the organization. Another aspect that we really encourage, and part of our criteria when we look at how we adopt change, number one, will this change improve care, and will it improve provider workflow? If it doesn't meet at least one of those, or if it degrades those, then typically that's not a change we implement unless there's a driving compliance issue behind it. And always patient safety is the highest priority for us. Also, we found that again, in the mantra of PTS, our technology staff does not drive the bus.

We don't want to lead the requirements development aspect. Our user community, we take a lead user and we work very closely with this lead, and they help us work with the clinical community to identify what is it we're trying to accomplish, what are the requirements, and that lead user also takes charge of working with the provider community to make sure that what we develop meets their needs. It's really important for us as technology people at PTSO to have someone who has a good handle on what the user community -- how they use it, what they need, and how it affects their world. So we put a lead user in charge that helps us and really owns that change process for us.

We support all around it, but the key translator and communication takes place through a lead user, which represents our provider community. Another aspect was, again, we adopted a committee approach to change control. We have a clinical committee that reviews and recommends all changes, and one thing we learned early on was not to make the change on behalf of one user. All of our organizations have very good proactive technology adopters, who frequently lead us and give us really good insight on where we need to go with a product and what technology we implement.

And we really rely on them as lead users, but we also have a broader provider community to support and gain buy-in from, so we avoid making changes that's driven by one user. It has to be bought into by our clinical committee, which represents five community health centers. And it may seem like this is  a very bulky and cumbersome way to work, but we actually are very efficient and effective at identifying changes and deciding whether to act upon them or not, and then doing the development and implementing it, and it's working really well for us. So we really recommend that you put behind the lead user you have a clinical committee that helps with change control and makes a determination.

One thing we learned early on, and I urge this for your groups, is the IT group should not be the traffic cop that determines what changes are made and what changes are not implemented. One, the IT group typically does not have the well-rounded knowledge that's needed, and two, they'll always be under the gun for the decisions they make. So we find allowing the provider community to make those decisions really streamlines and engenders really good communications and relationships. And again, we really focus on things that benefit all of our health centers and all the medical community that we support.

That does not preclude making changes that are very specific to one organization, because we do that also, but generally we find that our organizations are not that unique, and that workflows are not that unique, so we can really focus on changes that bring the greatest amount of benefit for the overall group. And again, as I touched on, change control is really important not only to decide to adopt and implement a change, or not to adopt a change, but ongoing documentation about how you made that change and why, because guaranteed, you will revisit that conversation soon, at some point, whether it be a vendor upgrade, or just simply making a new change, having good documentation about where the change occurred and why is really, really important, and we can't stress that enough. Another aspect that we have is this process that we outline in the governance really gives this purview and the ability to create such practices, identify best practices, and promote them. We also are able to create very standardized approaches to workflow and also how we categorize and work with data in clinical information.

What that brings to us is that at PTSO we have a fairly small staff that we're able to support a large number of community health centers because we've been able to identify, promote, and adopt best practices and really good standards around how we treat data. The next aspect I'd like to talk about then is what have we done and why? As I noted, we've made well over 300 changes, perhaps 400, over the last few years. A couple of key areas that we addressed was the health maintenance module from our vendor. We weren't comfortable how it worked, and for our community health center workflows, so we put a lot of time and effort to change how data is presented and when it's presented to the provider.

Overall, for all of these changes that I'm going to talk about, primarily we seek to improve provider workflow and how the care was delivered to the patient. So on the case of health maintenance, was making sure that their history and key tests that were due, and actions that the provider needed to take, were presented in one summarized area, and presented to the provider early on in the encounter. Another aspect we took on was our disease management module. Again, we wanted to put better purview, better views around some of the chronic disease indicators that we're tracking, and we also brought on board a dedicated HIV template.

And this was not only to improve patient care, but we participate -- probably some of you know the Ryan White program, and so we wrote this HIV template to enable reporting around that. For all of these, we also built in a lot of reporting to meet compliance requirements. And then the last one, the lab interface, we did a lot of work around the lab interface to make sure, one, that the results and the ordering all took place in a timely manner, in the appropriate place, in the workflow for our providers. And I'd like to do just another aspect around the customizations.

We started, over the years, we've put in well over 300. We just recently did a migration to the NextGen KBM version 78 about three weeks ago, and we were on KBM 73, and what we found was that the product that NextGen released has matured greatly, and actually we were able to leave behind and not bring forward well over 300 of our customization and changes. So basically, our goal is to converge back on a standard NextGen platform as much as we can, and less on our software development dependency, and less on our ongoing maintenance that will occur, because we want the vendor to pick that up, and that was a result of being successful and collaborating with NextGen, collaborating among the health centers that we support, and also collaborating on other avenues such as the NextGen large client user group. So we've been successful to help them bring the product more in line with what our needs are, and what we'll realize are some really good cost savings over the next few years, and less changes to maintain.

The next aspect, just again to emphasize, again, some of the customizations we did really support the workflow for the clinical programs and the reporting requirements. And some examples of some programs that we're supporting are breast and cervical health, colon health, we have a homeless program, and we have maternity support services. We also did a lot of work in customization to really make the UDS product reporting tool utility from NextGen work really well for our users, so they could run it any time they want, at any point during the year, for any period they choose to. But that's been the bulk of our conversions, and our experience around it.

We found that we had -- again, we needed to move the services group to a software development group, and there were some significant changes around that, and at the end of this I'll answer questions, or my contact information will be available, and we'll be glad to talk to you about our experience around this. At the end of the day, we take care of over 200,000 people, and thank you for your time this morning. Thank you so much, Roy, for that great presentation, and with that I'll hand it over to Joe Dawsey and his team, who is going to be our next presenter. Joe, go right ahead.

Okay, thank you very much. This is Joe Dawsey. Persharon Dixon who's the Medical Director, and also Chuck Clark who we didn't introduce, but he's the Director of the Information Systems. We started -- Mississippi Health SafeNet is the network that we started at, building on the Coastal Family Health.

And a little history, Coastal was completely devastated by Katrina in '05, and we lost what little systems we had at that time, so we just had to start back from scratch, getting anything, so we were kind of forced, pushed, and shoved into modernizing ourselves. We lost about 65,000 patient records and we realized at that time, that it was time that we had to do something to improve, and we work with Morehouse Medical School and developed the electronic health records, and it's been kind of a build as we go thing, it was in '06, and we're still going on it. The vendors that we use Health Corr and that's because they work with us, and we just had to take what we could -- Hey Joe? Yes. Sorry to interrupt you.

If you could just speak a little louder. Sorry, over here, we have one phone, so that's -- we're still not completely recovered from Katrina, by the way. All right, now I got you. But we used the vendor, Health Corr, who worked with us, and we had many people that worked with us after Katrina, and we started building this system, and then we received a network grant in -- I think it was '08, and we added six other community health centers through the network, and then we received an additional one, and now we have 11 community health centers in Mississippi.

There's 21 total and we have 11 as part of the Mississippi Health SafeNet. And that is a little bit of a history, and now I'd like Dr. Dixon to tell you about the customization part of it. Okay, good afternoon, everyone.

You've gotten really a good layout of how this customization process should go, and our presentation gives you a little bit more of the interaction with the vendor that you join this in order to start an electronic health record service at your community center. So these are some questions that often are posed when thinking about an EHR system. The first being, who's responsible for evaluating software requests within the vendor organization. We have found that to be a significant part of making sure we get the kind of changes that we need, and that there is a good communication flow where those answers will come from.

Another question is, what is the vendor process for implementing change requests? We want to be very clear on how long it will take you to see a change in the process, and what the path is for getting that change to your system to be implemented. Very important as you look at different aspects of a change process or customization. The internal team that you develop has to be able to evaluate those changes, and so you have to be very selective about who will make up your team, and our previous speaker talked about having a development team which we have gone through a significant process of streamlining that team, and deciding who was the best person to help us in making those significant decisions for our provider. Currently, we have an EHR resource team that consists of one of our IT representatives, a trainer and coordinator, and a position champion, who I think was alluded to previously as the lead user.

So a lead user, a position champion, and those are probably the same person, and currently can tell the vendor what the needs are of the provider staff. And so having this kind of resource team that is constantly looking at the needs of the staff helps you to leverage your position as the customer to influence your vendor to give you what you need. For us, it's been important to have this HealthSafe network, because certainly having more community centers or other like organizations with you and using perhaps the same project, helps you to leverage your position as a network of customers, to influence your vendor. And then of course we want to work with other customers in your network, and independent customers as a user group to help leverage the vendor.

There is nothing like getting information from others who are doing the same or different things, to get towards better use of a system, to help you gather what information is really needed. We know we're all trying to move towards meaningful use, and for providers, that can mean one thing; for a vendor, that could mean another. Certainly for providers, they're very interested in this being user-friendly. So what is the provider's role in getting vendor customization? We have to make sure, again, previously mentioned that this is a clinically-driven project, very important that this is approached from a clinical and business standpoint as opposed to an IT project.

Secondly, in getting the clinic staff involved, there has to be direct clinical staff involvement, and in addition to these physician champion, we also have another level, which includes our quality team that has several other personnel who help us to make the decisions. Our EHR resource team is really the ground team that's gathering data, and then they move with data up to our policy team, which is multi-disciplinary. So important to have the input of everyone who is a user. Now they need a provider that the secretarial staff, the clinical staff, the nursing staff, in terms of what kind of customization changes are needed.

But definitely that clinical champion is enough, and must be an integral part of the information team. It's not so very important that that clinical person be most computer-savvy, but they must know about your practice. That is how we get the information that they help drive the customization of the product. And as was alluded to in the previous session, the community centers have certain medical issues that we have to deal with, such as diabetes and hypertension, that are reportable events for us.

So we certainly want to make sure that we're addressing the types of health care processes that [audio distortion] those in your center. And then again, the implementation process -- very helpful for this kind of process to occur in stages. You really want to avoid getting an all-in-one kind of approach where everything is laid out at once. One, it helps to ease the transition for providers, if they're getting this in pieces, and it allows them to master a certain set of skills before we move on to higher level functioning.

But it also helps to drive what kind of customization we will request, because the providers have had time to really look around the system and find out what works and what doesn't work. And lastly, it's important to realize that this is a continuous process, and that the relationship that can build with your vendor is not just for implementation, but it is a long-time relationship and that to expect it, and there has to be a willingness between the two of you to continue working on the improvements. So that gives you a little bit of what we have been challenged with, and what you will be challenged with as you move towards the use of electronic health records and happy to have had an opportunity to speak with you and hope to answer some questions shortly. Thank you so much for that great presentation.

And with that I'll hand it over to Susan, who's going to be our last presenter. Susan, go right ahead. Okay, I'm just trying to get to my -- here we go. So good afternoon.

Just before I jump in here, let me just tell you a little bit about OCHIN. OCHIN is a 501(c)(3) not-for-profit organization that's headquartered in Portland, Oregon. We too are a health center controlled network, and we have about 35 separate organizations on our system, over five states serving over 250 clinic sites, which is about 700,000 unique patients and over 5,000 end users. Right now we have about 35 separate organizations on our EHR.

We function like a technical and management services organization, very similar to a co-op, if you will. We provide information technology, information support, quality improvement, collaborative workgroups, consulting, workflow reengineering, all of that. And we were also selected as the state of Oregon's regional extension center. So that's the backdrop, and so we've had quite a bit of experience with implementing EHRs, and then the whole topic of customization.

So I'm just going to go ahead and jump right in. My task was to talk about some customizing EHRs as much as possible from a clinical perspective, and so what I'm also weaving in is not just the clinical perspective but the counterpoint of how do you know what is enough and what is too much, and actually I would say that I agree with everything that both Roy and Persharon laid out in their presentation, so they should just build on that. First of all, when you start talking about customizing, you need to know what it is that you want to accomplish, and we'll talk more about why that's so important. It's very important to be clear about who owns what.

If you're on an EHR then you know that there's a lot of information that's considered clinical content, and clinical content changes continuously, and new types of grants -- there's a lot of things that change in health care, and you need to have a system that can evolve with it. But it's interesting, clinicians think that they own certain pieces, IT wants to own certain pieces, operations says, but wait a second, everything you're doing effects operations, and so the question is, who owns what decisions? I think we need to look at customizing your EHR in the context -- not just workflow and what makes it easy, but what means we'll use. And then the backdrop of customizing your EHR should really, really have a mantra of how do we make it easy to do the right thing. People should not feel like the EHR as a test ground, it should help them, and then some lessons that we've learned over time.

So first of all, I mean, I don't need to tell anybody on this call. We have -- the United States has a culture of being highly individualized, and so there is a strong impulse to want to customize, and I guess I want to back up a little bit and again underscore what Roy talked about. You know, there are layers to customization, there's an essential layer for the community that I don't see as customization, I see it as essential functionality that must be built into the system, and that -- it's what you need to get through your visits, to see your patients, and to get your visits coded correctly and money in the door. That's not frills customization, that's the essential stuff, and we work just like Sharon and Roy do with our vendor, which is Epic Systems.

We work with them to build in standard functionality to meet the needs of the community health centers, so I actually don't think of that as customization anymore, I think most vendors increasingly have become very adept at saying we can help accommodate whatever your needs are, but that's a core layer that I don't really think of as customization anymore. When I think of customization, it means making things more efficient, how do we further tailor this to our unique clinic -- not unique grants and not to get money in the door but just to make it easier, and that's where you need to start balancing the impulse to do it because you can, against the true need to customize. How will you know what to customize, or if it's the right thing? I think again Roy talked about this. You need to use a system a certain amount.

Now, I'm not talking about the core essential pieces for a community health center, but the impulse is incredibly strong to sit down before you implement an EHR and say, let's just design everything. Let's design it all and get it all done, so that when we go live it's all done. But the reality is, just like a construction project, you can envision what it's like to be going to a construction project, and you can think that you know what the impact is going to be, but only when you're living it do you know how it's going to effect your workflows, and so you need to look at the system for a bit, before you know how you want to really customize it. You need to think about system standardization versus customization.

How is the customization that you're thinking about going to make it easier to use? How is it going to effect your training? It may help with efficiency. Maybe the efficiency that you gain is so small and the cost is so high that you need to think about, is that really what we want to do. Again, how is it going to help you improve quality, conduct research, get performance measures out, and help guide practice, particularly for new clinicians? I'm asking these in a rather rhetorical way, because I don't think there's a right or wrong answer. These are things that you just need to think through.

EHRs -- I mean, vendors have gotten very smart. OCHIN is not a vendor, we work with a vendor, but we work with them pretty closely, and I think all vendors at this point understand that they need to give lots of choice. How do you decide what customization really yields what it is you want? So here are some things to consider, and some of these things you just have to wrestle with over time. Again, there's no right answer.

I'm not going to read these all to you, but I think that it's important that you think these things through, and just like Roy talked about and Persharon, we also work with integrated teams to -- we have clinicians that own the clinical content, but there's always operations of people providing input into timing and implementations. I mean, this is a comprehensive clinic project. No one discipline owns it all, but these are the things that you need to consider if you're going to make well-informed decisions. So, going to meaningful use.

Everybody on this call, I'm sure, is very well-aware of our active 2009 and how it's going to be important that if people are going to get Medicare or Medicaid reimbursement money that providers have to meet the threshold of meaningful use. And so I don't know what happened to my slide here, my apologies. I didn't know I had added custom animation. So there's five domains of meaningful use, and I'm sure you guys are all aware of these, but I think when you think about customization, it's not just what do we want to do, who's the loudest provider that says I want it this way.

How in detail can we customize a system? Those things have to be considered, but you have to look at it in the broader context of how are the changes going to really help support all of this. And so what are the few requirements for meaningful use. Okay, first of all you have to successfully implement an EHR. You have to be really clear about what your goals are, and of course all of that includes choosing the right product and being successful, and then you get to meaningful use.

Well, that's measured how? Clinician order entry, e-prescribing, interaction checking, decision support -- now, if you think about it, those are high level pieces of functionality that if you think about it, you'll realize that there's less about customization for some of these activities, and it's more important to have as much standardization as possible so that you can measure apples to apples, and look at trending and patterns across your individual clinics and even across regions. That I think customization is very important, but you have to use it judiciously, because meaningful use is not about everybody doing individual things, it's about achieving the measurements, the metrics set out by ARA. And again, if you think about what this says, obviously the effective use of information to improve health outcomes and reduce cost growth. Well, again, standardization lends itself pretty well to some of this, but doesn't mean that you avoid customization, it means you really think it through.

So -- and I don't want to beat the drum of meaningful use, but this is something that we all are -- have on our horizons, and we need to think about this. Oh, the rest of my -- move on. I was going to show you the different phases of the five different domains and phases of meaningful use, but I'll show it to you -- oh here we go. So these are just the things I talked about a few seconds ago, and it's a progressive process, and basically over time, you have to accomplish this.

I'm not going to read all of these to you, either. I have multiple slides about each of the domains and how you want to accomplish that using your EHR, and I'm just suggesting that as you think about the domains of meaningful use, and you're thinking about what do I customize, you have to kind of keep in the forefront, you know, I want to customize my EHR to accomplish what I want to accomplish, and it needs to help with workflows and make it easy to do the right thing, but I also need to think about -- I need to be able to improve quality, and so here's just -- it's a sample that is certainly not even close to exhaustive, but here's some quality improvement activities that you definitely would expect with an electronic health record. And all of this slide, you'll have available to you, so you can use it if you choose, but again, if you're looking at, for example, annual fittings for provider care team reminders, or annual prevention tracking, typically those types of things would be standardized versus customized. So just think about customizing around how it's fit with meaningful use.

And improving safety -- same type of a deal. How do I think about customization and accomplishing an improved safety for my patients? Improving efficiency -- again, I don't think it serves you well for me -- I'm not going to read through these, but these are topics or opportunities that you have with your EHR, again, thinking about meaningful use and EHR. Reducing disparities -- how do I use my EHR to reduce disparities, and how does customizing my EHR lend itself to accomplishing these things? Again, this is just a smattering. And certainly we all know that with reports, anytime you're talking about reports and displaying lab data or trends, that is about standardization, knowing what your numerator and your denominator is.

That also lends itself to standardizing as much as possible in the EHR. And then engaging patients and families -- again, another way that you use your EHR, with the backdrop of meaningful use, and ask yourself, how does customizing my EMR help with this? And then reaching out to the public health arena through health information exchanges. And then lastly, care coordination. I'm not going to talk about the last component of meaningful use, but this is really around THI and HIPAA.

And security, that's really I think a different topic -- outside of today's conversation. And so, and then care coordination of public health. I mean, data aggregation, looking at financial data, population health tools, strategic outreach to high-risk patients that you haven't seen. Those types of activities again require a pretty standard approach, require fairly standardized fields in your EHR to be able to even pull the data in to analyze it.

So I just took this arrow of looking at meaningful use with the ARA money over time, and you look at the value against the time. I really think that the true goal is about clinical transformation. These steps, these five steps in and of themselves all incrementally are helpful towards getting the clinic more organized, getting the health care and particularly the community health arena, more in line with the 21st century, but looks at all four. It's really to help with clinical transformation for our patients who are the most vulnerable and disenfranchised.

And so I think it's important to think of meaningful use and clinical transformation to help balance the customization. Here's how we've looked at any type of customization we've done in the EHR: how does customizing the system beyond the core essential pieces, how does it help me take better care of my patients, and how will I know that I'm taking better care of my patients? So performance measurement and increased patient satisfaction, just basically improving care, delivering health outcomes. How does it help me be more efficient? How does it help the whole care team be more efficient, in terms of increasing accuracy of my visit, my patients are happier, there's decreased wait times, and their health outcomes are improved. So I threw in some general -- some EHR lessons that we've learned over the past five years, and you know, most of this is just restating I think what both Roy and Sharon actually profiled, just some of it is a little bit different.

But you know, leadership's required throughout. It's not an IT project. You certainly need IT people -- an active part of your planning process and implementation, but it's really fundamentally more of a clinical transformation and workflow transformation. You know, it's very easy to search for perfection, particularly when it comes to customization.

The search for perfection can really, really be the enemy of pretty good or great, and I'm on my way. And so be wary of that. People can only take so much change. You know, I don't know about you, but not many people I work with say I love change that's a stuttering change.

I mean, who likes a dripping faucet? You know, being thoughtful of what you want to implement in terms of your EHR and whatever you decide to customize, and pace it, so that people don't feel like it's a nonstop barrage. And I've already talked about until you go live, you can really only guess about what you need. Start simple. We really think it's important to focus on the 80/20.

Focus most of your efforts -- your top workflows, your highest volume of activities, and the other 20% you'll figure out over time. Define your goals for implementation. You have to be clear what your goals are for implementing an EHR before you even start thinking about customization. The impulse to customize is incredibly strong, so realize that, and try and balance it.

Often times simplicity is far more useful than any custom feature and I'll tell you just like Roy talked about, there have been several times where we have really developed a lot of customization because it was exactly what all of our organizations wanted, and then within a year, they were like, what were we thinking? What were we thinking? We actually made this harder, and we've gone back to simplifying it. And then it's incredibly easy, with the sophistication of vendors and EHR products right now, it is incredibly easy to over-engineer and really overly complicate the most simple of tasks, and customization is very useful. It is absolutely a tool that you should have in your back pocket, but it should not be the first thing that you think of when you are weilding this very powerful system. And that's it.

I tried to do it fast. Thank you so much for that great presentation. We are right on time. So with that, what we'll do is we'll go ahead and get started with our Q&A session.

And just like I mentioned earlier, Jason's going to be moderating our Q&A session, and Jason's probably going to ask one of the presenters to respond to a certain question. If any of the other presenters feel the need to add anything in here, most certainly can do that, at that point. So Jason, if you don't mind, if you could go ahead. YeS, sure, the first question is for the PTSO group.

Question is, has NextGen's latest version improved the UDS reporting, or do you still have to customize the program? Thank you. UDS utility -- excuse me -- is a separate utility product that they release every year, so we found that it kind of meanders around a center point of working well and not working well. So one year it works better than the others, depending on how much changes that's dictated within the UDS requirements themselves. One of the things we've done with the vendor is now we're integrated into their development process for UDS.

And we'll be a data site. So we'll know more in July/August about how it looks. And this means Aaron Faladay, our application development manager, and he also has some insight he'd like to share. One of the challenges that we've had around UDS reporting with our product with NextGen, and I imagine that it's true for the other systems as well, is that there's a lot of different ways you can note something in the system.

Sometimes, depending on the workflow or the type of visit, you can put information that essentially means the same thing, in different places. And it can be represented differently in the database. What NextGen did with the UDS tool is, so far, they've been reporting out of one discrete field for each reporting area. So if you happen to use that in your workflow, it works perfectly.

If you don't, then you have problems or challenges. So that's where the majority of our work has been focused, is either in mapping the areas that we track data to the areas that NextGen thought we would track the data, or in reshaping and aggregating that data so that it's consumable by the UDS tool. Thank you. Okay, the next question is for all of the presenters.

It was mentioned in one of the presentations that most of the customizations had been standardized in their most recent upgrade. Have any of the rest of you experienced this as well? This is Roy, and we're finding that a lot of our customizations in our working with this vendor have led, as we know it, to a stronger product, so we've been able to orphan our changes and move forward with the standard product in many areas. This is Susan, and I would say exactly the same thing. Many, many of our requested customizations that pushed Epic in the beginning are now standard functionality and they continue to -- they actually have a special technical services team that stay abreast of what else is needed from the system, and instead of having it be -- it starts out being weekly customization, but they built it in standard.

And this is Sharon. We are actually waiting to see how that's going to work out for us. We are in the process of waiting for it from different versions, and hopefully a really promising version of our system, and hopefully those customizations that you've requested will become standard. Okay, the next question, again, for all of the presenters,  it seems that there is a spectrum of customization from actually manipulating source data to influencing your vendor.

One approach muddies tech support waters, and the other seems to imply an active users group to impact the vendor. Can you describe which solution you think works best? Well this is Roy, we'll just touch on -- in the -- at some point, you're depending on the criticality of the change you need. Some vendors -- I don't know if all vendors can respond as quickly as the criticality of the need that we've found in our organizations. So some of these were absolutely crucial and critical to implement, and our vendor -- at that point in time, community health centers weren't as strong a focus.

I think that's changed today. We've also been able to sort through and work with the vendor to determine, look, here's a change that affects all your customers and brings great value to all of your base, or a large base, if not just the community health center vertical. And then we also look at which ones really serve our organization best. So we've done a little bit better -- we've gotten better at triaging what needs to go to the vendor, and we have a better sense of timeline on how long it will take them to develop and implement it, so that gives us some decision-making points.

I would say it's both. I mean, I would agree with exactly what Roy just said. I mean, yes, I don't think I need to say much more, I mean, we go about it both ways. This is Chuck Clark at Mississippi Health State Network, and we use the approach of a users group manipulating the vendor to address the code and the system, because we don't have the staff, the database administrator, and the people that do software development.

This is the avenue that works best for us as a group. Next question, again, is for all of the presenters. Has anyone implemented a patient portal to your electronic health record and customized that? This is Sharon at Costal Family Health, we have not yet. And this is Susan and we're in the process of doing it right now, or planning for it, getting agreements for it, and working on it.

This is Ray at PTSO. That's a planning session for us, and looking at it is really scheduled for 2011 unless we get the HRSA grant that should be announced in the next few weeks, where we actually would move it up a year. And the next question I believe is for all of the presenters, does your customization include templates for things such as PCHP, HIV, colorectal cancer screening, et cetera? PTSO again -- right, that's one of the reasons we modified those templates that you call out, was for that reason. Yes, again Susan, and yes, we focus on specialized templates and flow sheets and those things.

I don't -- those things really, I don't really view so much as customization; it's basically creating tools to help make it easy to use the system, versus customizing -- because everybody uses them. Everybody from all of our organizations uses all of them, versus customizing each organization while they do well child visits, or they do colorectal cancer screening that everybody does completely differently. Basically, we create tools and everybody -- most everybody just uses them. Pam, this is Sharon.

I agree there, that we are encouraged to make patterns that are really our own customized version of how we take care of patients, however we are looking at better standardizing even our own customized patterns for ourselves that allow us to make sure we can pull the data that are needed for those special reports. So it is an option to individualize some of what you do within the system, but we do have to take into consideration the kinds of data that we need, and where it needs to be put in the system, to allow us to make sure we can show the meaningful use. Okay, another question for all of the presenters, following the customization of the template question, can you all expand on any customization to do for your breasts template? At Coastal Family Health, I'd have to say no, we don't have that in place just yet. This is Aaron with PTSO.

We have for the breast and cervical health program that our clinics participate in, and there are certain reporting needs for that program. We developed and customized templates to support those reporting needs. We've basically copied a paper form and process that was traded for the program and duplicated that electronically. That's around the breast template.

Around the health issues associated with women's health, we addressed that with our health maintenance and disease management modules, which actually link information throughout different templates, through the entire workflow, so that it's fitting where you need it, at the right time in the encounter. We do exactly the same thing. What Roy just described is essentially -- I would just be restating it. That's essentially what we do as well at OCHIN.

Next question is for PTSO. Will you be using the patient portal that NextGen offers? Probably, but we will do a planning process and see how it works. What we like about it is it works pretty well, it integrates nicely. So we'll see how that works out, but I think the answer's probably.

Next question for all presenters, I work with Title V planning programs. Are there user-friendly EHR packages designed to help meet compliance issues for clinicians? This is Aaron at PTSO. I'm keying in on the term user-friendly, no EHR is user-friendly. Nothing's as friendly as pencil and paper, but there is family planning programs in the NextGen application that's worked well for us, as well as some of our associate clinics that focus on family planning.

The same thing at OCHIN. The hard part is making sure that we know proactively when some reporting requirement changes. Often times we find out after something has kind of changed or tweaked a little bit, and we like to try and stay ahead of the curve. But I will say that the Title V templates and reporting material have been -- we've done it, but it took quite a bit of logic, and when it changes, it's quite a bit to overhaul.

Next question for the PTSO team, how successful have you been with Health Force in implementing the changes you need? Can you expand on that a little bit? So we work with One Health Port, and I may be thinking of the wrong vendor, as part of our health information exchange for Washington State. Is there a definition I'm missing? No, not that I'm aware of. It does seem to be we're referring to Health Port as a general term, or a general product. Health Port is an EMR vendor here.

This is Sharon. Health Port is the EMR vendor that we use here at Coastal Family Health Center. I don't know if that was supposed to be directed to us? It came in after the second presentation. Okay, okay, so that was our report.

Well, it has been an ongoing process of trying to get the information back and getting those outbreaks done in a fashion that we would be most satisfied with. I think we face the same issues as any other group that's using a vendor out there. The quicker we have that communication link that gives us the data back in a timely fashion. So as it relates to getting back information that we need, well we're probably not where we would like to be, but we're working on that and have come up with some other ways to interact with our vendor to hopefully assure that we get those upgrades and get the information back that we want.

And those are all of the questions that I have. So I don't know if we're done, but this is Sharon with Coastal Family Health Center. You know, I just want to say that we were in a position where we had an opportunity to go ahead and get on board with electronic health records, and like Mr. Dawsey alluded to, we were in a position to take on a product at a time when we may not have been in the preparations for this like some of you are now.

So this kind of interfaces that HRSA is allowing helps you to be on the front end of preparing for your EHR project, whereas we're kind of doing things as we go. Although we're getting there, we probably could have been a little bit closer on the front end, had we been in a different position or the position you're in now of preparing to enter into an EHR project. Thank you so much for that, and I would just like to add, if Christie Brown had had anything else to add to the Q&A, as well as all the materials for the webinar, which include the PowerPoint presentations and the recordings would be made available on the HRSA health IT portal, and do include the presentation today, and for folks who do not have a login for that HRSA health IT portal, you can send an e-mail to healthit@hrsa.Gov. That slide deck is actually being showed, so you can certainly send an e-mail to that e-mail address if you do not already have a login for the HRSA health IT portal, and we'll go ahead and get you set up so you can access all the materials for this webinar as well as all the materials that we have conducted previously to this, because all webinar materials is archived within the HRSA health IT portal.

So that's pretty much it from my end, unless Christie or Mike at HRSA had anything else to add at this point. Hi, Sarab, it's Christie. I just want to remind everybody that there is the HIT toolkit, which is at www.Hrsahit.Ahrq. Okay, and the toolkit has about 11 or 12 different modules in there now for you to be able to use tools that have been developed by folks who have gone before you and have implemented EHR such as our presenters today.

A lot of the networks that are out there and a lot of the health centers that are out there who have already implemented, provided tools so you don't have to reinvent the wheel. So I encourage you to be able to go to that toolkit which is at healthit.Ahrq.Gov, and you can find the health IT toolkit there, that toolkit I'm being told. And then I just thank our presenters for presenting today, and answering the Q&A. Thank our  presenters for doing a wonderful job on this [audio distortion].

We'll be having another webinar in June which will be focusing on Office of the National Coordinator Programs pertaining to grantees. So watch out for that HRSA. Thanks so much, Mike, and just to add to that, just in regards to the toolbox that Christie was mentioning, it's actually healthit.Ahrq.Gov/toolbox. So that's the HRSA health IT toolbox.

It has 13 modules that we have incorporated into that toolbox which is, like Christie mentioned, a great resource for everyone to access and utilize. And that's pretty much it from my end as well, and I would like to thank everyone for participating in this webinar..