Case Management – Tips & Tricks III – Data Exchange


In Tips & Tricks I and II we looked at Work Scheduling, Decision Support and Work Performance.

This blog post deals with the reality that no Case Management software suite is an island.
Most corporations have legacy systems that source important data for Case Management and some of these same systems need data from Case Management environments to carry out processing.

Our starting position from within a Case Management system is that there are likely to be many subscribers to Case data and each of these may, worst case, want to receive different sub-sets of available data using their own native data element naming conventions.
Subscribers may need data at different frequencies (real-time, semi-real-time, batch, on demand).

Publishers will, in the normal course of events, only be willing to share data on a strict need-to-know basis. And, some of the time, a subscriber to a publisher’s data may enrich the data it receives and make this data available back to the original publisher.

Aside from data element naming conventions we need agreement between each pair of trading partners regarding a data transport format.

And, agreement on whether data should be pushed to subscribers or pulled by subscribers.

Let’s take an example from the healthcare sector where a managed care company elects to provide consolidated data to its member clinics. The MCC has three reasons for doing this 1) to save participating hospitals from having to make available hospital visit/test data to individual clinics 2) to improve patient care and 3) to reduce unnecessary duplicative testing.

A basic rule here would be that no clinic receives any data for patients it is not seeing. A second rule would be to avoid shipping data that is not needed (i.e. clinics submit daily lists of patients they expect to see and gain access to consolidated data a day prior to a visit). Or, clinics request data on demand for walk-in patients.

Clearly the MCC will have a master ID per patient and the clinics will typically have their own individual patient IDs. There is guarantee there will be no duplication of IDs across all of the stakeholders. The MCC must accordingly be able to process requests for data using clinic\id and for security reasons, a request should be rejected or challenged if a clinic\id message header does not crosswalk to the MCC master ID.

Each time a Case receives input (via keyboards, portals or imports from local/remote 3rd party systems and applications) the data either needs to be tagged for review prior to publication, or, immediately exported for sharing.

Here is where an at-arms-length Data Exchanger is needed and because of the need for dynamic mapping the Data Exchanger must be bounded on each side by a parser and a formatter. Data that flows to subscribers must be formatted out of publisher application systems for posting to the Data Exchanger, it must be formatted on the way out of the Data Exchanger for data transport and,  upon receipt, parsed by the subscriber for import to the subscriber’s EHR.

Publisher -> format -> DATA EXCHANGER  . .

-> format SUBSCRIBER 1 –> {transport} -> parse -> {import}
-> format SUBSCRIBER 2 –> {transport} -> parse -> {import}
. . . . .

If you are in need of a generic Data Exchanger, you can obtain a license by calling Civerex Systems Inc. at 1 450 458 5601.

List of Posts in this set:
Tips & Tricks I – Work Scheduling
Tips & Tricks II – Decision Support/Work Performance at Cases
Tips & Tricks III – Data Exchange
Tips & Tricks IV- Consolidation of Summary Case Data to Executive Dashboards and Corporate Dashboards.

 

About kwkeirstead@civerex.com

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, connect-the-dots law enforcement investigations, healthcare services delivery, job shop manufacturing and b2b/b2c/b2d transactions. (C) 2010-2017 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 Case Management, Data Interoperability, Interoperability. Bookmark the permalink.

One Response to Case Management – Tips & Tricks III – Data Exchange

  1. kwkeirstead says:

    Why format into the Data Exchanger and then format again coming out?

    Answer: the publisher exports all data it is willing to share, each subscriber in theory needs a different need-to-know subset of that data and possibly a different data transport format.

    Like

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s