November 11, 2004 Minutes

Paul says Duke Health Technology Solutions (DHTS) sets strategic directions and sets operational direction and support for PDA's within the Duke Medical Center system. The overall strategy has been to support both type of operating systems on PDA's.

John Board asks do they issue PDA's?

Paul says that people generally obtain their own.

Rafael says they have worked with HP to get some devices, but mostly people purchase their own.

Chris Gelpi asks what is the proportion of PPC palm devices used to Palm OS?

Paul says maybe 30 to 70, though it's hard to compare demand because so many were granted by HP.

The process of implementing PatientKeeper was approached with a focus on looking at patient info and application management. PatientKeeper is made up of various applications, so we took a quick look to see which applications were the most desired and will deploy them about 45 days apart. The Afaria application provides a suite of applications, so instead of having to upgrade each one, we only have to upgrade the one Afaria application once a week. PatientKeeper also allows a variation of channels, so if a user needs a device for a specialized field, it can be customized. The intent of the entire wireframe was to bring in other applications while in PatientKeeper. Pylon/Pm was also added, which allows wireless conductivity to email servers without an intermediary application.

Mike Picket asked if any of these were developed at Duke?

Paul says there is a combination of commercially available applications, those that can be acquired free, and those developed at Duke. Dr. Chang put a few of the applications, like the Heart Center Dosing Guide, together.

Paul says that PatientKeeper is a company, a wireframe for information delivery to the handheld device, and also many of clinical applications. The system consists of several parts: the Clinical Data Repository primarily stores patient records (i.e. electronic medical records); the Mobilizer knows what to do with the information and gives it to PDA's, which can also talk to department servers; and the Clinical Application Server allows the Clinical Data Repository and the Mobilizer to talk.

PET was built within PatientKeeper. There is a requirement to log procedures the learners see within grad studies. This was mainly done before with pencil and paper, and when we implemented PatientKeeper we decided to make it electronic. PET prepopulates a lot of the information needed, and is being rolled out not just for med students but also for nursing; we hope to eventually expand it to residents and physical therapists.

John Board asks if in these applications, the information stays on the server, not on the device?

Paul says yes, but the information stays on the device for a period of time. We wanted to make sure we weren't entirely dependent on a stable wireless system, because it's just not mature yet.

Paul is asked if there are issues/complications of patient confidentiality if the device is lost.

Paul says there are security measures associated with the devices: we purchased a product that is a device security manager, and also have time out periods for applications, etc.

The critical success factors for PatientKeeper are physician stakeholders, the PDA advisory committee, measurements (surveys, statistics), early and continued resident feedback, and patience.

Lessons learned include a lack of physician/resident training time, not enough patient information on the PDA for the first release (didn't choose enough modules), a cumbersome device security application (would time out without warning, now have selectable grace period so don't have to log in as frequently), wireless network connectivity and presence, battery life of the PDA's, the need for localized support (kiosk/help desk sitting outside food court in Duke North and South, setting up website for residents).

Paul is asked, What were the standards that you thought about in terms of why an hour for an application to be open is ok?

Paul says the patient data has its own login procedure, so security is twofold on a device.

Rafael says the application times-out after an hour. We looked at HIPAA regulations (appropriate practices to protect patient information), which aren't very specific on this issue. Desktops in public areas are supposed to time out in fifteen minutes; in private areas we took that to be an hour. Since PDA's are private devices, we consider it in line with the hour limit. It's an issue of managing risk.

Dave Menzies asks if they would speak to surveys, etc. used to get feedback.

Rafael says the survey was sent out and users were given 10 days to respond; the survey dealt with applications, network connectivity, etc.

Dave asks if sending out surveys is limited to specific problems?

afael says they ran into major problems when they distributed devices, which caused a large amount of dissatisfaction. So, they sent surveys around to figure out what the problems were so they could fix them.

Peter Lange says he believes the administration's willingness to support IT continues to be strong. We are still a substantial distance away from exhausting funds for strategic planning of IT; over next several months, IT needs will be an important aspect of planning new facilities.

John Board asks, are you are happy with ongoing tension between local and global support at the university level?

Peter says yes, generally the “fire-alarm” system is a good indication of how the system is working (i.e., wait until a fire alarm goes off to identify a problem). There are very few alarms going off now at Duke.

John asks if there is a problem with entrenchment at the college level?

Peter says he doesn't believe we are entrenching, though there is some flattening at Arts and Sciences. But flattening of faculty growth is OK, and doesn't imply entrenchment. We want to be able to support faculty adequately. We cannot expect faculties to grow infinitely – there is a limit to faculty size based on resources. I don't think any of our deans aren't committed to supporting the IT needs of faculty. At the fringes, there are some questions of if we're doing enough. I don't foresee entrenchment being a big problem in the future, either.

John asks, do you have a vision for classroom technology?

Peter says no, he doesn't have a personal vision for classroom technology. We will want more fixed technology than mobile – we cannot outfit our facilities to meet peak load. It's an incredibly expensive approach. My guess is we'll continue to evolve a basic package, with some classrooms with mobile equipment. In Arts and Sciences, we have gotten far with basic packaging, as well as Fuqua and Divinity.

John asks if some sort of personal communication storage/device will be important pedagogically soon? How can we avoid having iPods become an entitlement?

Peter says that in the future, he doesn't think we'll have everyone go get whatever they want to use as a personal communication device. This won't work with classroom experiences. On the other hand, we don't think there'll be one true Duke device. We're trying out iPods now, and in six months we'll know how it's turned out. This is a pilot study; the new iPods will probably be better than the ones used last year. We are also hearing that simply the introduction of a new technology into the system as a generalized thing can shaken-up the works: people are thinking of other things they can do with technology.

eter says with planning overall, most of this academic year won't be about programmatic planning. We will be doing 4 things: assessing all programs, looking at what competitors are doing, looking at our facilities needs, and planning resources that will underwrite the plan. We aren't anticipating a plan as expensive as the last, but it won't be small. We have to plan how to generate a startup pool, and we have to plan what the resources are. Once we've got that, we can start the programmatic planning.

Mike says in the summer they started exploring the possibility of replacing two voicemail systems in order to get fully integrated methodology. One reason is to replace platforms before they reach end of their life. We also wanted a true integrated messaging platform, to look at other communication media like email and fax, and to link with ID management. Most importantly, we wanted to improve the experience for the end user. We get lots of questions about why things don't work on one system that work on another.

We started looking internally, at the specs of the system have in place now. We also got advice from peer institutions, and then started brainstorming to develop a skeleton for subsequent investigations. We developed a survey, sent it to OIT managers, and enhanced and tweaked the survey based on their feedback. We then sent the survey to 318 individuals across the Duke community, Medical Center , undergrads, etc. We wanted to hit as many different areas. We got 63 surveys back, compiled the information, did a review, categorized the information, and then tweaked the survey a little more. We did another focus group, because we didn't want to miss anything and wanted to make sure everyone who wants to give input is able to. If they don't, the new system won't serve the needs of the community.

We are now looking at the focus group, and then we will send an RFI to as many vendors as appropriate. We plan to spend quite a bit of time evaluating proposals, and then go to a senior management team to make decisions. We hope to have the RFI out before Christmas, and the first evaluations done by early February.

John Board asks what an optimistic time scale is for changing the hardware?

Mike says a lot of it depends on where they get funding: we need to see if what we can get will satisfy user needs (may need to wait another year until technology available improves). Also, can we implement this in a modular system, or will it be a big bang approach?

Tracy asks, how long would it take in a best-case scenario?

Mike says about 6 months.

John asks how long can the current platforms go?

Mike says we're basically limited by the number of lines we have.

Mike is asked, Where do you see this going?

Mike says we have the technology today to move between email and voicemail. The problem is determining if we can integrate it into the existing environment.

Mike is asked if building infrastructure so 5 yrs down the road we'll have what people are expecting.

Mike says yes, we have to think about where we're going to be when it comes to infrastructure and planning.

Mike Alexander is asked if all requirements are created equal?

Mike says they have not weighted them yet. We are going to look at how many people surveyed found what more important. There are several things we've identified that have to be there.

Rafael says the problem is there's nothing to gauge it against. How can we determine the value versus cost?

Tracy says maybe the focus groups can be used to clarify top priorities.

Mike is asked if we'll be comparing and contrasting what people ask for versus what they actually use.

Mike says yes.

John asks if this system would include people in Durham Regional and Duke Health Raleigh?

Mike says they aren't currently in the plan.

Tracy says there is a possibility down the road that they will be included.

Kyle Johnson asks why aren't the students using voicemail system? We should look at that.

aron Gunn says students find the voicemail system cumbersome to use; if they have a cell phone with voicemail that is easy to use, they will use it instead. He estimates that of 100 students, maybe 10 use Duke voicemail.

None.