Building a Better Mousetrap: Creating Flexibility and Scalability in an STD Electronic Medical Record System Good morning. Rachel Paneth-Pollak, M.P.H. NYC Department of Health and Mental Hygiene Bureau of STD Control rpaneth@health.nyc.gov The findings and conclusions in this presentation are those of the author(s) and do not necessarily represent the views of the CDC/ATSDR

Background I- Bureau of STD Control 10 clinics across all NYC boroughs Free and confidential walk-in services for ages 12 and over >100,000 visits/yr Services include: STD testing/treatment and Hep C and HIV testing Hepatitis A & B vaccination PAP smears and Emergency Contraception Partner and Field Services

Background II- EMR An Electronic Medical Record (EMR) was built in-house and has been used in all 10 STD clinics since September 2005 220,964 visits captured in the first two years of full deployment. Intro to what is an electronic medical record say something here In our Bureau, our STD Electronic Medical Record, or E.M.R., is referred to as “EMR”, so for brevity that’s how I’ll refer to it for the remainder of the talk. First two years of full deployment were from September of 2005 to September of 2007.

Background III- Clinic Flow Triage Registration Reason for Visit MD Visit Physician Modules Laboratory Module HIV Modules Express Visit Laboratory Module HIV Modules In order to orient you to our EMR, I’ll briefly show you the components of a patient encounter, and which particular pages or “modules” our clinic staff might use. A patient’s Reason for Visit is established at Triage, and then entered into the computer system when they are Registered. Patients follow one of two main paths– either to see a physician or, if asymptomatic, are offered an Express Visit which includes urine-based Gonnorrhea and Chlamydia NAATs, blood-based syphilis testing and rapid HIV testing by oral swab. Physician modules include: Chief Complaint, Sexual History, Medical History, Physical Exam and Diagnosis/Treatment . I’ll show you an example of a Sexual History page later.

Patient Main Page This is a patient’s chart just after registration. I cannot show you actual navigation, since we don’t have access to a live system, but I want to point out the module menu to the left, and the main page of a patient’s chart.

Background IV- Need for Change By early 2007, system stability could not keep up with rate of growth: Numerous enhancements identified by users Electronic systems capacity advanced at referral labs EMR data used with greater frequency for QA and program evaluation The main complaint in the clinics was that the system was performing slowly and would frequently go down and need to be re-booted. Database structure was built for a system with a smaller scope, and so this expanded functionality necessitated a new version.

Objectives of this Presentation Describe re-design and expansion of EMR to accommodate new needs Highlight associated human and electronic resource needs Demonstrate how we accommodated evolving user needs and clinical changes To describe re-design and expansion of EMR, which was done in October of 2007. And by re-design I mean the re-building of the system, including the re-structuring of the data tables.

Advantages I Re-design of data tables … to enable quick addition of variables Enhancement of laboratory results interface … to reduce turnaround time and errors in posting of results Of course there are many advantages to our new system which I don’t have time to go through, but I will highlight four of the central advantages and then show you examples of each. The new version of EMR was re-designed to enable quick addition of variables– for instance our lab recently validated anorectal chlamydia NAAT testing in response to an outbreak of LGV, and we were able to add these variables quickly. We enhanced our laboratory results interface whereby we requisition tests and receive results electronically.

Advantages II Addition of clinical decision support tools … to ensure proper patient care Addition of alerts and confirmation messages … to avoid missed information or loss of data And we added Clinical Decision Support tools, as well as alerts and confirmation messages. And I will demonstrate these in a couple of slides.

Addition of Variables I mentioned that re-structure of data tables enabled rapid addition of variables. For example, it enabled rapid addition of an “Outbreak Related” checkbox to the Reason for Visit page. And here you also see an example of a confirmation message.

Electronic Lab Requisitioning I I will just take you through our Electronic Laboratory Interface. The first step is to order the appropriate test on a patient’s Laboratory module by checking off the order box to the left.

Electronic Lab Requisitioning II The last page was a patient’s individual chart– this page is a clinic-level page, which is used to scan all patient specimens each day into a list called a “Manifest”. All tests that have been ordered in a patient’s chart that day will appear here, under Available Specimens. Their barcode stickers can be scanned into this box here, and then they appear in lists organized by specimen type. You can see here that this clinic has had 1 cervical swab, 6 urethral swabs and 13 urine specimens so far today. If I were to click on the titles of these lists, it would display a line list with patient name, date, ordering clinician, etc.

Clinical Decision Support Tools I As shown in the Quality Assurance literature, Clinical Decision Support tools are a useful addendum in improving quality of care. This is an example of a patient’s Sexual History page. Any chart that is marked male with a history of Same Sex partner, and a history of performative Oral Sex will display this alert at the top “Oral GC Culture Indicated”. A similar alert appears for an Anal GC Culture if the patient reports receptive Anal Sex. These alerts also show on the patient’s Laboratory page to remind the clinician to order the appropriate tests.

Clinical Decision Support Tools II This is a patient’s HIV Assessment page, and at the top, you see the HIV Testing History displayed. This shows, in order of date, any HIV testing this patient has had at any of our 10 clinics in the EMR system. Don’t pay too much attention to this particular history, I created a fake history for a fake patient and it doesn’t make sense clinically.

Alert Messages On the patient’s main page that I first showed you, there is a space for staff to check “Do Not Send Mail” for patients that do not want mail to be sent. Here, on the reports module, which is where staff prints and mails letters to patients, you can see an alert message. With the exception of the electronic laboratory results interface, these enhancements came from staff suggestions.

Continuing Human Resource Needs IT Programmer- ¼ time IT Manager- ½ time STD Project Manager- ½ time STD Data Manager- full time On-site hardware and software support- full time During implementation, we had more staff than this, but currently we have the following. I should say that on the IT Programming end, resources are thin given the dynamic nature of our system and this is not ideal. Additionally will be data requests and analytic demands so may need to bolster analytic support. For example, we hired an Analyst who works almost exclusively with our EMR data.

Continuing Budget Needs Replacement hardware barcode label printers scanners signature pads Continuing supplies sticker labels toner There are three pieces of equipment that we need to set up EMR registration stations, so we need to have these in stock. Additionally, we need sticker labels and toner continually, for the barcode label printers.

Conclusions/ Lessons Learned Expect exponential growth in numbers and requests for enhancements Need for flexibility to make rapid and sometimes temporary system changes Variables ideal for data analysis may not be optimal for the users or the patient Some conclusions and lessons learned are to expect exponential growth in numbers and requests for enhancements. Additionally, as soon as folks realized the wealth of information that is now accessible, we found that requests for data grew rapidly. As I mentioned before, we needed the flexibility to make rapid and sometimes temporary system changes for local or national imperatives such as Acute HIV testing pilot, outbreak activities, changes to clinic flow, etc. And finally, that the variables ideal for analysis may not be optimal for the user. That is, variables with distinct levels or formatted data entry may hinder the physician’s ability to record information or may “force” an answer that isn’t quite accurate. There is also a trade-off between the strictness of data entry criteria and need for data management staff to “unlock” or “change” things from the back end.

Future Enhancements Electronic Requisitioning for all lab tests Additional alerts PAP testing Hepatitis Vaccination Testing & Treatment History Module Automated data reporting Hep vaccine data to Immunization Registry HIV Testing data to CDC And many more

Acknowledgements Bureau of Informatics and Information Technology Stephen Giannotti Maushumi Mavinkurve Kate Washburn Hadi Makki Bureau of STD Control Jessica Borrelli Susan Blank Julie Schillinger