1. 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
The findings and conclusions in this presentation are those of the author(s) and do not necessarily represent the views of the CDC/ATSDR

2. 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

3. 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.

4. 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.

5. 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.

6. 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.

7. 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 And by re-design
I mean the re-building of the system, including the re-structuring of the data tables.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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

20. 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