One common challenges for clients is content enabling existing data driven applications. As we have been posting since 2014 on how to add content capabilities to existing claim and policy systems, many clients have invested considerable time and effort into data management systems that need to link to documents. These systems need access to content or case management capabilities but clients struggle with defining a clear integration strategy. Typical goals are to have the data management system retain ownership of the “data” with the content management system owning the “documents or content”. This post will discuss the integration scenarios and capabilities connecting these systems to the OpenContent Management Suite.
Content Enabling Existing Data Management Applications
All companies have existing data management systems that have been enhanced over decades of successful and critical day-to-day processing of customer or company information. These include ERP systems like SAP or Workday, CRM systems like Salesforce, or specific systems like we have seen for insurance companies for the data management of claim and policy data. As these systems have evolved, many have often been extended with basic document processing capabilities via rudimentary image and document storage leveraging the same data infrastructure or tied to legacy document management applications. Enterprises would like the ability to keep evolving and enhancing their data processing capabilities while easily leveraging new and updated tools for document processing. By decoupling the data management system from the content management systems, companies have the ability to evolve and support both these systems independently to reduce risk while continuing to innovate each of the separate platforms.
This post will present how to the OpenContent Management Suite provides the capabilities to easily extend existing systems with robust document capabilities and a modern interface. Scenarios for connecting documents/content to the data management system include:
- Efficient access to content related to the current information being viewed in the data management interface
- Creation of content with metadata from an existing system’s values
- Triggering of events in an existing data system from content activities
Accessing related content from existing systems interfaces
A core component of content enabling existing system interfaces is the ability to allow users in the data management system to easily access content related to the data they are viewing in the data management system. Consider the following scenarios:
- A claims adjuster working in the Claims Management application would like to access the documents for the claim
- A Healthcare professional in the Health Management system wants to review patient documents
- A manufacturing employee in the learning management application needs to train on the currently approved but not yet released new SOP for a manufacturing
- An HR employee in the HR system wants to access the documents for a specific employee
In all of the above cases, the user would want an easy button for quickly accessing the related content. Rather than build tight integration that is specific for every Claims Management, HR, or Learning Management system, our “connect from anywhere” approach has been to allow easily integration from the systems as in most cases companies have developers capable of enhancing and extending their data management systems. Our integration relies on the developers constructing a URL that will launch into document or folder that includes the metadata about the document or folder. For example:
- In a Claim scenario, the developer would construct a URL where 8675309 is the claim number
- https://servername/ocms/claim?claimNumber=8675309&claimOwner=Joe%20Claimant&lossDate=2020-05-15&policyNumber=8675309
- In a Healthcare scenario, the developer would construct a URL where 773202 is the medical record number (MRN) and encounter number
- https://servername/ocms/medical?mrn=773202&encounterNumber=2622800
- In a Manufacturing scenario, the developer would construct a URL where SOP-MF-502 is the document number for the approved document
- https://servername/ocms/quality?docNumber=SOP-MF-502
- In an HR scenario, the developer would construct a URL where 800588 was the employee number
- https://servername/ocms/hr?employeeNumber=800588
The below scenario shows the types of data in the insurance claims data system vs the content management system:
In the manner above, the systems are connected but ownership of the data remains with the existing data management system. More details about the claims integration API are available here.
Populating metadata from existing systems
One of the challenges in content enabling existing systems is the metadata population as well as security. While some scenarios can be fairly simple (security for HR is typically limited to the HR system), other scenarios can be very complex (claim security is often tightly managed by the claim management system, particularly when personal information is in the documents and metadata). The OpenContent integration addresses several unique integration points including:
- Folder Creation with metadata real time creation – In a claim, HR, patient or other scenario where documents may not yet exist, the URL integration will create an empty folder with the correct metadata passed from the data management system and present the interface to add documents to the folder. For this scenario, the developer could include more than just the patient/claim/employee number in the call to allow the population of more folder metadata.
- Folder Creation with metadata triggered from the data management system – In this scenario, either the data management system or a process from the content management system would be looking or creating activities where new folders/documents need to be created. This back-end application would create the templated document or empty folder when the meta-data was found enabling the real time integration. This is similar to how Guidewire (insurance application) cloud drops XML files in an S3 connector that the content management application can create the folder. Often this approach is used for not only creating the folder but also querying for any folder information that may have changed (“Last Name” in example of marriage) to keep the metadata and data management system synchronized.
- Folder creation with metadata from indexing – Some scenarios occur when the documents arrive before any data management activities occur. In this scenario, we typically see the indexing screen of the content management system allowing the user to see the document, determine a new entry needs to be made in the data management system, and then create the folder with the values from the data management system.
Security Coordination
One of the more difficult integration points is often how to coordinate document security with data security. While the scenario for an HR system could say that everybody in the HR department has access to all employee files (with some obvious exceptions), how can an employee just access their own documents (Compensation, Benefit elections, etc) without having access to other employee data that they should not see?
Document security coordination with data management is a scenario where the document enabling of the data management system significantly reduces the need for maintaining/synchronizing complex security management in the content management system. Since users already only have access to the data in the data management system they are permitted to see, the need for specific per folder or per document level security in the document system can be reduced. Consider the scenarios from above:
- In the Claim scenario, the claim adjuster can only access claims from the claim management system, allowing the claim management system to decide which claims adjusters could see which claims folders (which it likely already does)
- In a Healthcare scenario, the employee would only have access to the folder and documents that were enabled from the health management interface. Specific documents could be excluded depending on the employee role (nurse, doctor, administrator).
- In the Manufacturing scenario, the employee would only have access to the document for view and no other access to draft documents or document search.
- In the HR scenario, while the HR department would have access to the full document management interface for search, view and edit, employees will only have access to their own file. As such, the integration would only allow the employee to access their own documents with no access to search or edit capabilities.
For all of the above scenarios, we typically recommend a robust audit trail to track specific document access regardless of the security scenario.
Triggering Events in the Data Management System
The other type of integration can be initiated when tasks originate from content centric activities in the content system, like the case of content being uploaded or updated in the content system and the data management system needs to set up a task or update a status. While the majority of the process centric activity occurs in the data management system, there are times that a content centric process in the content system needs to trigger data or processes in the data management system. Examples of this might include:
- An automated process (emailed document) uploads an estimate for an auto repair into the claim folder, which triggers a new task in the insurance data system to phone the client to present the estimate.
- A Nurse uploads a test result to the patient’s medical record that should trigger for the doctor to review the test results
- Manufacturing plant approves a new Standard Operating Procedure that triggers a new learning management system course to be sent out to users of the equipment
- HR employee uploads an employee’s passport photo as a part of their onboarding, which should trigger a task in the HR system to begin the next step of the interview process in the HR data system.
In these cases, our integration methodology exposes an event driven API in the content system for the data management system developers to run their code. Available event triggers include:
- onCreate (includes all content attributes as well as the content)
- onUpdate (includes if the document was versioned [major or minor], and/or if the content changed or just the metadata)
- onDelete (includes all content attributes as well as content being deleted)
Summary
Document enabling existing data management systems does not need to rely on specific vendor tight integrations but can be quickly enabled with an API that allows for “Integration with Anything”. By separating data management systems from content management systems, each system can innovate and focus on their core competencies of making users more efficient when using their system.