The Drupal API turns a CMS into a True Health Care Enterprise Application

Drupal is well known as a Content Management System (CMS) — famously used by the White House and elsewhere. At the company where I work, Achieve Internet, we view Drupal as more than just a CMS — we see it as a powerful web application platform with capabilities to integrate multiple sources of information. Sporting a far-reaching and flexible API, Drupal can link together other platforms that provide APIs, such as enterprise productivity systems or electronic health records (EHRs), and essentially provide Drupal’s web pages as an interface to these systems on both a read and write basis. The growth of the platform and the community has put Drupal in a position to revolutionize the concept of a traditional CMS in one market sector after another, from the media and entertainment industries to education, travel, and government.

Case study: health care

One industry in dire need of a technology makeover is the health care sector. Given the regulatory environment and complex requirements faced by hospitals, private practices, medical device companies, and health care service providers, they have been slow to adopt new technology trends. Furthermore, the needs of the industry require something much more powerful than your average CMS. Drupal has already made headway in the health care sector, but as IT departments begin to open their Pandora’s box of problems, the need for high-powered web applications becomes a necessity.

Increasing the urgency of the technology makeover and the need to transition to open source solutions, budgets for health IT applications are decreasing while their requirements are increasing. Another market factor that continues to push the urgency of this technology transition is the consumerization of health care and the need for user-friendly, human-centric applications for both the patient and the clinical team. These factors are putting pressure on the market to offer sophisticated web applications, robust user sites, and portals. This is allowing engineers to exploit Drupal’s flexibility to experiment with and create new applications, platforms, and health care solutions using the Drupal architecture as the backbone.

One of the key drivers in health care web applications is the need to exploit APIs to create fully integrated platforms that improve the flow of data between multiple disparate legacy IT systems. When proprietary systems expose useful APIs, Drupal can be configured to integrate those third-party applications into its framework.

For instance, when patients are discharged from one care setting and enter another, doctors exchange key information about them through continuity of care documents, and many EHRs export this data through an XML-based document standard called the Consolidated Clinical Document Architecture (C-CDA). Communicating through the EHR’s API, Drupal can ingest information from the C-CDA and present it in a much more user-friendly interface than current EHR systems offer. The nature and structure of the Drupal framework make it relatively easy for a skilled engineer to create custom integration points and write APIs for external platforms. Additionally, Drupal can handle multiple integration points from multiple proprietary systems such as other electronic medical records systems, practice management tools, patient portals, or billing software with just as much ease.

The scalability of the Drupal architecture allows it to integrate with an Enterprise Service Bus (ESB) just as easily as any other API. This allows engineers to build central data hubs where a user can interact with a number of data sets from a number of systems through a single access point in a two-way, near real-time fashion, which is critical in the clinical context.

By taking advantage of the robust API integrations of which Drupal is capable, the health care industry can greatly benefit by extending current Health IT platforms without the need to rip and replace the pre-existing legacy systems. This approach can vastly improve the experience of end users, whether they be patients or the clinical team, while saving money and reducing IT disruption for enterprise health care systems. This will not be an easy task, but our health care technology division, Achieve Health, is excited to see how well the use of Drupal will further improve the health care technology landscape and, ultimately, improve the care experience for the end user.

Beyond health care: widespread possibilities for system integration

The Drupal community has developed a significant number of API frameworks to facilitate communications with CRM systems (e.g., Salesforce), marketing automation systems (e.g., HubSpot), and email management systems (e.g., MailChimp). In addition, Drupal provides modules that facilitate the building of custom integrations based on SOAP or REST, while other modules can simply expose endpoints within Drupal that can both send and receive data. Drupal provides a variety of potential methods for integration, depending on the use case.

For example, in larger organizations, an ESB allows the organization to minimize the dependency on any one (non-ESB) platform. This provides the organization with greater flexibility in deprecating or integrating another platform with minimal effort. ESBs can be a great solution when there are a significant number of integrations to be built, and one of the advantages of Drupal is that integrating with an ESB does not require much more effort — this is the beauty of Drupal: it provides a standardization and structure when integrating with other platforms, whether that be one or many 3rd-party applications.

One of the key drivers in health care web apps is the need to exploit APIs.Drupal can be leveraged simply for its framework and modular capabilities. The rapidity with which the Drupal community responds to new functionality provides value, while the Drupal framework provides a standardized structure that allows for this rapid iteration and enhancement from the community — it is a symbiotic relationship.

That being said, on occasion it makes sense, from an engineering or business perspective, to offload other components of the Drupal system to another system for performance, scalability, or simply to isolate a particular functional component. An example might be the front-end templating of a particular environment. Drupal 7 outputs information as HTML by default, but the upcoming Drupal 8 release will provide a significantly richer and more flexible output layer. For example, when developing a SASS application, Drupal can still be leveraged as the foundation, but by modifying the output to return JSON responses, a Javascript templating engine can be deployed on the client side, which provides the ability to override all aspects of the look and feel.

While Drupal has been the CMS of choice for the enterprise in media and entertainment, publishing, and government sectors due to its content editing, workflows, and security features, it will be its robust API capabilities and extensibility that help the platform make serious headway in the health care sector. Additionally, the flexibility provided by Drupal has given our engineering team, both on the health care side and the commercial side, the freedom to look at any number of complex challenges and come up with the most effective solutions, secure in the expectation that the underlying technology will support them.