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.
eCases, the final frontier for workflow management?
eCases II Look before you leap!
eCases III the UI makes or breaks it
eCases IV – Interoperability