Mercy Health Sets Up Drupal and Alfresco for Their Main Portal

Mercy Health supports several hospitals and clinics across many different geographical locations in the US. Each geographical location has historically had its own dedicated intranet site, and these sites were on different technologies and each had a separate support structure. It was determined that a single unified co-worker portal was needed to support the vision of One Mercy, a patient and provider portal.

The portal was launched for over 40,000 employees of the Mercy Health system; the next step was to migrate the documents and structure from the old intranet sites into the new portal. One of the main features Mercy Health wanted to have was the ability to upload and share three types of files used by their network of hospitals.

These included:

  • Policies—enforced policies for a department, hospital, region, and more.
  • Forms—filled out by both staff and customers.
  • User content—personal folders for users to upload anything they want.

Furthermore, for policies and forms file-types, Mercy wanted to have an approval workflow implemented. However this workflow would be different than a typical workflow because it would be started by a rule, use information about the department, and content to know who to assign the workflow to, and then it would allow the user to choose all the people it needed to approve the workflow, with the department head always getting final approval in the chain.

Mercy also wanted to have the portal become the one place for all hospital staff to be able to find people, places, and things across all of Mercy’s various data stores: their wiki, knowledge base, document repository, Sharepoint, and more.

First, Mercy needed a web content system. They chose Drupal because it has a high-end framework with extensible functionalities. Then, Mercy needed to migrate documents into the portal. Drupal, out of the box, did not provide a document management solution flexible enough to meet Mercy’s business logic. Contributed mod­ules such as: workflow, maestro, revisioning, actions, and other modules related to workflow and document management were considered but didn’t prove to have the power necessary to sup­port the best solution. Thus, in need of a document repository, Mercy chose Alfresco to provide the solution. However, this created another problem: how to marry Drupal and Alfresco?

To make that happen Mercy leveraged Canopy by Appnovation. Brian Boyer, Director of Application Development at Mercy Health Systems, describes what the process was like when they began looking for and assessing software options:

"At Mercy Health, we determined that we had a need that couldn't be solved by an existing solution, so we engaged several different areas of IT to help us find a new one. They defined the requirements of the solution, determined potential solutions that could meet the requirements, compared the solutions, prepared a proof of concept for the finalist, and chose the appropriate solution that best fits the requirements and the strengths of Mercy Health."

The Canopy framework is a set of services and APIs used to accelerate the integration of Drupal and Alfresco in an enterprise environment. Canopy combines the flexibility of Drupal as a front end web development platform with the power of Alfresco as an Enterprise content management and workflow system.

Once the decision was made to use Canopy, project objectives were outlined and the final deliverable of an intranet foundation setup on the Mercy Health Development Server (tested for 2 content types, data syncing, workflows and LDAP authentication features) was agreed to, development started.

The project was broken down in to four phases:

  • Phase 1: Functional Requirements Discovery
  • Phase 2: Technical Requirements Discovery and Architecture Design
  • Phase 3: Development (Alfresco Intranet set-up)
  • Phase 4: Training

This was delivered using a combination of waterfall and agile project methodologies by a team of ten Appnovation members and nine Mercy Health employees. The two teams worked closely and collaboratively together over six months, maintaining constant and open lines of communication on a daily basis. The major development aspects can be described as follows:

The Appnovation team developed the Alfres­co Intranet foundation for mercy.net and the portal (called Baggot Street) which required setting up an inventory of Canopy modules and CMIS integration points. The existing Drupal intranet and website were rep­licated in a Mercy Health Development Environ­ment while the Canopy modules and integration points were added to the system. On the Alfresco end, Appnovation set up the Java Server and Da­tabase environments based on the infrastructure identified during the discovery phase. Basic work­flows were built as according to the parameters defined in the goals and requirements section of this case study and user sign-ins were set up us­ing LDAP authentication.

Appnovation also developed several custom REST based webscripts for mercy in order to batch certain operations into one call instead of several. These custom REST based webscripts/APIs served as a bridge for synchronizing group nodes, group members, taxonomy terms, and department/sub-department nodes between Drupal and Alfresco. Content is then able to synchronize in "real-time," meaning that at the time content is created on Drupal, it will also simultaneously be sent to Alfresco as well. If for any reason the content was not successfully delivered to Alfresco, the con­tent will not be saved in Drupal and the user will be notified.

Additionally, custom webscripts were created in Alfresco to handle the manipulation of custom metadata so as to allow users to set the values in a docu­ment such as reviewer and department head. Thus allowing Drupal to trigger another custom script and initiate a workflow. Appnovation set terms to be synchronized by using Alfresco’s category system and creating a series of scripts to link up to Drupal’s taxonomy through the ScriptAPI in Alfresco. Mercy needed to create folders for each department called by a Drupal function. The Ap­pnovation team used the ScriptNode API to cre­ate the folder hierarchy based on the parent node of the company to create these folders.

Also included in development was a Drupal-Alfresco-CMIS-Apachesolr document search integration. The idea behind this functionality was that Mercy Health wanted to be able to have faceted search­ing on the documents available in Alfresco. The Apachesolr module handles this out of the box. In order for Apachesolr to index documents form Al­fresco, CMIS API was used to retrieve documents from Alfresco. Once the documents are available in Drupal, they are then saved as an Alfresco Document node and will be indexed by Apach­elsolr the next time a cron job is executed.

Mercy Health wanted the ability for users to upload their documents from Drupal to Alfresco. For regular documents, CMIS API was used to upload content while for form documents cus­tom webscripts were developed on top of CMIS API to trigger a workflow in Alfresco. Using CMIS to upload either document type (regular or form) would then trigger custom scripts built by Appno­vation to set the metadata of the reviewer and department head. This custom work was done outside of the CMIS cus­tom model.

Lastly, Mercy Health had a cus­tom requirement that when a document was uploaded, the "uploader" would then be prompted to choose to the person to set as the reviewer and the department head. Any reviewer would then be allowed to specify multiple users to review and approve the document. Once every reviewer had approved the document, it would then move on to finally be reviewed by the department head. Once the document is re­viewed by all parties, (finishing with department head), it is then assigned back to the initial re­viewer so they could then publish the document manually. At any point the document is rejected the whole process would be returned to the ini­tial reviewer.

This article was written by Isabel da Costa and first published in opensource.com. It is being republished by Open Health News under the terms of the Creative Commons Attribution-ShareAlike 4.0 International License. The original copy of the article can be found here.