CBMi’s Translational Informatics Unit (TiU) uses various software technologies to “get the job done.” This approach leaves us at liberty to find the right tool for a research project and not be limited by the weaknesses of any one technology. Many tools and frameworks are developed in house and we also make wide use of open source programs.
Use of the Electronic Medical Record (EMR)
The EMR (Electronic Medical Record ) used in the clinical services of the hospital however, is not thought of as an “open” piece of software. It instead is highly proprietary. Its code base is locked down and its new versions are installed less than annually. It is the protector and keeper of patient health records. Tools developed in the TiU to work with it must “play nice”, with nice meaning, “don’t mess anything up.” So in a sense, in a quarrel between TiU software and the EMR, which is Epic in our case, Epic must win.
Figure 1. shows a scatter plot of response times recorded on January 11, 2013. The response time is the time it took for one of our patient portals to receive a response from Epic/Interconnect. The tests were triggered every five minutes but only response times greater than 1000 milliseconds were captured. The average response time was 2328 milliseconds, the standard deviation was 834 milliseconds, and the maximum response time was 5310 milliseconds. The Interconnect is a network bound service of Epic and thus our waiting could be a factor Epic itself or the network traffic during the time of the request. In either case we must “wait” to receive a response from Epic.
Prior to January 17, 2013, there were clusters of response times above 1000 milliseconds as show in Figure 1. Figure 2. shows how the number of response times greater than 1000 milliseconds drops off dramatically after January 17th. Average response times are dramatically lower for that week and the clusters would be less dense. CHOP is a major hospital and research institute.
Dealing with the variations in load and processing time.
Variations in network load and processing times by our EMR must be expected. We at the TiU have at least two choices; (1) We can design our software such that its usefulness will be minimally affected by these variations or (2) we can design our software such that it is not at all dependent on processes will make us “wait.” In reality, a useful and impactful translational software tool will be a blending of the two options.