Sector(s)
Team Members
Project Team
The site was developed by (@amandahart and @jayroberts), theming by @Frank Yonnetti, and project management by @stephenpashby.
Duke University Health System is a world-class hospital and health care network including three hospitals in central North Carolina (Duke University Hospital, Durham Regional Hospital, and Duke Raleigh Hospital), as well as outpatient, wellness, and hospice care.
Duke Health’s existing patient-facing site was not meeting the needs of their physician audience, both internal and external of the Duke Health network. Although the site contained a functional physician directory, market research suggested physicians desired their own web portal with advanced search functionality, better suited to the way physicians conducted searches.
In addition, Duke Health had previously worked with external vendors to deliver their Clinical Practice Today website—a physician resource for continuing medical education (CME); and a complimentary newsletter to physicians.
Duke Health sought to address the concerns of the physician audience by centralizing and streamlining their business offerings (Clinical Practice Today website, newsletter campaigns, and physician portal) into one single Duke Health subsite, all while leveraging the technology used for dukehealth.org, including both common software (e.g. Drupal) as well as a single data source.
About the project
Goals
Duke Health’s primary objective was to increase physician engagement. By facilitating referrals to Duke specialists, a new subsite would not only increase engagement, but it would also increase Duke’s perceived prestige within the healthcare industry. Market research revealed that physicians wanted more control over search functionality and that they needed a way to search by different criteria, such as physician name, or by specialty rather than condition/procedure. These search options were not currently supported by the patient-oriented “Find a Doctor” search tool on dukehealth.org. Aside from updating search functionality, another goal for the project was to employ the existing codebase export mechanism utilized by dukehealth.org to display a separate, specialist-filtered data set of providers on the new referring physicians website. The filtered data set would contained only duke-affiliated specialists (roughly 2,250 of the 3,000 physicians presented on the patient-facing site) and excluded primary care physicians.
Requirements
In order to provide a tailored solution for referring physicians, one that was simple, fit their clinical workflow and encouraged repeat visits, DesignHammer and Duke Health began the project with a robust discovery and planning process. A competitive analysis was conducted to understand how physician search and CME content was presented by other premier health systems, and to identify any other functionalities that physicians might find engaging. To determine best practices in content organization, navigation structure, and to identify appropriate homepage content; a card sort needed to be executed. In addition to this, tree testing needed to be completed to validate the proposed navigation.
Duke’s IT team had not yet migrated their websites to Drupal 8, and therefore the new website was to be built in Drupal 7. Multiple search interfaces needed to be built using Apache SOLR, including a Mini Specialist Finder for the homepage, a full Specialist Finder, and a Search by Doctor’s Name option to better connect referring physicians to Duke specialists. To minimize staff overhead related to data maintenance and specialist data, including Specialist Profiles; new auto-complete suggestions were pulled from the existing data used by the patient-facing, “Find a Doctor” system.
For continuity and SEO authority enhancement, the previously standalone content on the Clinical Practice Today WordPress website (including appropriate redirection), had to be migrated to the new Drupal website; along with landing pages for targeted specialties and CME (Continuing Medical Education) content. Although Clinical Practice Today’s focus is on delivering timely articles regarding Duke Health research, innovation, and other continuing medical education, the website was not directly managed by Duke Health until the migration.
To ease the site transition for Duke’s employees, it was important for content editors to be able to manage the Clinical Practice Today content though a familiar administrative interface, one that provided similar functionality to the patient-facing dukehealth.org website. To keep Duke’s physician site from competing with the public site in search results, specialist profiles on the physician site were also configured to point canonically to their corresponding profile on the patient-facing sites.
Ensuring access for all meant that new website was to be developed in accordance to Duke’s latest accessibility standards for users with disabilities. However, issues with accessible error handling on webform submissions (in Drupal 7) prevented the site from meeting the target compliance standard. However, DesignHammer and Duke Health did focus their efforts on delivering accessible navigation for all major site content.
Outcome
DesignHammer created a new platform for physician engagement that fit seamlessly into Duke Health’s internal workflow and facilitated physician referrals to Duke Health. The new Specialist Finder provides referring physicians with instant access to the latest specialist listings by leveraging the same data source as the “Find a Doctor” search, with the added benefit of reducing Duke Health’s staff time from not maintaining two data sets.
Additionally, the project delivered new ownership to Duke Health of the dissemination of Clinical Practice Today CME content, in parallel with Duke bringing the ownership of email marketing of CME in-house. This consolidation provided the Duke Health marketing team with full control of previously outsourced content.
Finally, the complex javascript UI met ARIA 1.0 guidelines, therefore meeting Duke’s accessibility targets as allowed by Drupal 7 Webform.
Why Drupal was chosen
Drupal was a project requirement, based upon Duke University’s adoption of Drupal as the University’s preferred content management system (CMS). Duke has reported this decision was based on Drupal's many advantages, such as offering a robust and flexible development framework, a user-friendly editing interface for content updates, a dynamic and worldwide community of active, engaged and welcoming developers, designers and content strategists.
Describe the project (goals, requirements and outcome):
Discuss the project's goals and requirements, timeline and major milestones. What makes your project special? What project management approach you used? What was the outcome of the project? What business problems were solved? What results were achieved (e.g., increased traffic, better performance, etc.) as a result of using Drupal for this project?
Technical Specifications
Drupal version:
Key modules/theme/distribution used:
Drupal 7 Core: was a client requirement for this project.
Feeds: was chosen because it matched an existing implementation of that functionality by the client.
Search API and Search API Solr: We tried implementations of the search functionality using these modules as well as apachesolr (https://www.drupal.org/project/apachesolr). The Search API approach gave us the most control for building queries based on our custom form’s input and also had excellent support for geo-queries which allowed us to include distance-based sorting for physicians.
WordPress Migrate: The original Clinical Practice Today website needed all blog posts to be fully imported into the new Drupal 7 site, without data loss (both text and media). This was approximately 1100 posts. WordPress Migrate works alongside Drupal’s Migrate module to take a correctly formatted WordPress XML export and import it into an existing Drupal content type. Regular expressions were used during this migrate process in order to filter and edit data in the existing posts and reformat it for the new Drupal nodes. Doing this manually would have been prohibitive due to the large number of edits required.
