eCases IV – Interoperability

This is the last of a four-part series on eCases.

We introduced in eCases I the concept of Case.  Part II highlighted the contribution of eCase histories to decision making.  Part III explained how eCase environments provide a framework for workflow management.

In all of this, the presumption has been that decisions regarding what to do, how, where and when are based on historical data at eCase histories plus current information keyed-in by logged-in users.

The facts are that much of the information at eCases is likely to come from data imports from the outside world i.e. supplier/customer/data keyed-in at web portals.

The term “interoperability” picks up remote system data export, data formatting, data transport, parsing of incoming data and import of data to eCase database records, then, in reverse, eCase data export, formatting, transport, remote parsing and import to remote systems.

In the absence of standardized data formats, each set of trading partners must agree on a custom data transport format and make use of a custom format for outbound data and a custom parser for inbound data.

We very quickly see an increase in complexity when there are multiple subscribers to data at eCases. First of all, publishers and need to define the subset of all data at an eCase that they are prepared to share with subscribers.  The publisher may want to trim outgoing and data streams on need- to-know basis which means each subscriber could get a different subset.

In the absence of a standard data transport format, different subscribers will want to read data using data element names that are specific to each.  If ‘A’ publishes ‘abc’, subscriber ‘B’ may want to receive/view ‘abc’ as ‘def’, whereas subscriber ‘C’ may want to refer to ‘abc’ as ‘ghi’. Some subscribers augment received data and will re-post such data with enhancements using their data element naming conventions such that ‘abc’ ships as ‘ghi’, then an enriched version is posted as ‘ghi’, and mapped to ‘abc’ and ‘def’.

For some data elements, there may be a need to transform data i.e. yyyymmdd to to mmddyyyy.  The easy way to avoid the need for transformation of data at a subscriber location is for each publisher to export multiple data values for the same core data i.e. 20131211 and 12112013.

A final consideration relative to interoperability is whether data should be ‘pushed’ or ‘pulled’.  Publishers understandably prefer to have subscribers pull their data.  This eliminates extra steps and allows subscribers to pick up data when they want it.

Bottom line, make sure the eCase environment you select to manage your operations includes comprehensive data exchange facilities.

Related Posts:

eCases, the final frontier for workflow management?

eCases II  Look before you leap!

eCases III  the UI makes or breaks it

eCases IV – Interoperability


Management consultant and process control engineer (MSc EE) with a focus on bridging the gap between operations and strategy in the areas of critical infrastructure protection, major crimes case management, healthcare services delivery, and b2b/b2c/b2d transactions. (C) 2010-2019 Karl Walter Keirstead, P. Eng. All rights reserved. The opinions expressed here are those of the author, and are not connected with Jay-Kell Technologies Inc, Civerex Systems Inc. (Canada), Civerex Systems Inc. (USA) or CvX Productions.
This entry was posted in Adaptive Case Management, Business Process Management, Case Management, Data Interoperability, Decision Making, Process Management. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s