5. Inner Workings of the CP Split Technology

Up to this point, I described how the nodes' asynchronous publish-subscribe process works, and discussed the use of spreadsheet templates for producing and consuming content files. This describes the inner workings of the CP Split technology.

Start by clicking this link for a PowerPoint presentation of the CP Split inner workings. Additional information follows.

The Publisher Template

If a node has publisher functionality, its Publisher Template must be pre-configured to execute the operations required for Content File creation and transmission. During this process, a reference tuple is created. Once CP Split is configured, the reference tuple is used in the process to ensure continuous referential integrity and entity integrity. Hence, this reference tuple promotes versioning.

One type of pre-configuration involves database queries. That is, if a Content File will contain data from one or more databases, the proper SQL/ODBC query code (macro/script) must be written in its template’s grid code layer. In an MS Windows operating system using Excel as the node’s underlying application, for example, the query for each database must be configured with the correct login ID & password, and it must use the correct ODBC drivers. In addition, the proper fields and records must be identified, as well as the particular spreadsheet cells into which the queried data are to be sent.

Using a Publisher Template’s macros to execute the queries enables them to be initiated automatically via remote request by having the Publisher node execute the correct queries for each of its Subscriber nodes based on ad hoc and pre-scheduled requests from its Subscriber(s). The following key processes occur automatically:

• Prior to creating a Content File for a Subscribing node, a subscription manager in the Publisher Template must store the IP addresses and authorization information for all Subscriber nodes authorized to communicate with it. This can be done, for example, by distributing to each node a list of authorized nodes, by using a centralized directory, or by having information requests and responses go to intermediate nodes that do the authorization before allowing them to be sent.


• The Publisher node must also be pre-configured to establish communication standards with each Subscriber, i.e., a “hand-shake” that ensures the nodes communicating with one another (a) are allowed to connect (i.e., their connections are authenticated) and (b) agree on how the transmission will proceed by defining how information requests from each Subscribing node must be structured and how the Content File is to be organized by the Publisher node to enable the Subscriber node’s template to read and present it as a report. For example, during the establishment of the node network, each node’s Template File would be set up with the forms, code, and metadata needed to send information requests and Content Files to each other in a way that enables each node to understand the specific data in specific cells by virtue of their cell locations in a spreadsheet.


• For ad hoc requests – such as a doctor (Subscriber) requesting the data of one or more patients from other healthcare providers (Publishers) with a different EHR systems who treat the same patients – each Publisher node’s Template File bases its queries on the requested information sent by an authorized Subscriber’s node, including patient identifiers and requested data sets. It’s macros use this information to define the correct table, records and fields to query via metadata in the models (e.g., database schema maps) and subscription rules (e.g., rules defining allowable fields to be queried based on each Subscriber’s healthcare specialty).


• For pre-scheduled requests, a node’s Publisher Template executes rules for performing such functions as sending certain Subscribers particular patient data automatically whenever the Publisher updates those data. These rules determine the queries to be executed and the spreadsheet cells into which the queried data are sent.


• Whether ad hoc or scheduled, once the required data sets are queried and stored in the appropriate spreadsheet(s), these data are then processed by cell formulas (which may be in other spreadsheets) and macro functions as defined by the Publisher Template’s models. This functionality may be integrated into third-party products such as statistical/data mining applications, inferential logic engines, etc. This processing performs any required data analytics and transformations. It then organizes the resulting data value and text strings into pre-defined cellular configurations (i.e., “Content Configurations”) in a spreadsheet (i.e., the “Content File Production Grid” or “CFP Grid”), the cell positions of which are known by the Subscriber/Presenter Template as discussed below.


• When this processing is done, the Publisher Template then saves the arrays of values and strings, without any formatting instructions and code, in a delimited text file (such as CSV format) for maximum efficiency, or in other less efficient file formats (such as spreadsheets, XML, etc.). This file is the Content File.


• Once the Content File is created, other Publisher Template functions send it to the appropriate Subscriber nodes as an e-mail attachment or via other means (e.g., FTP).

The Subscriber/Presenter Template

If a node has subscriber and report presentation functionality, its Subscriber/Presenter Template must be pre-configured to execute the operations required for consuming and rendering particular Content Files. Using its template’s spreadsheets and macros to consume and render a Content File enables a node to composite and generate reports without ever having to query a database or connect to other data sources. Following are key processes:

• Prior to receiving a Content File from a Publisher node, the Subscriber node’s Subscriber/Presenter Template must be pre-configured to establish a certain communication standards with the Publisher, as discussed above.


• Once a Subscriber node receives a Content File from an authenticated Publisher node, it uses the pre-configured models that have been assigned to that Publisher node to consume the Content File. This process involves using a macro to take the data and information contained in the Content File and parsing them into specific, pre-determined cells in a spreadsheet (the “Content File Consumption Grid” or “CFC Grid”). There is a semantic correspondence between the cellular locations of the content in the CFP Grid and the CFC Grid, which enables both the Publisher and Subscriber to “know” the particular content elements stored in each cell.


• Once the Content File’s contents are in the CFC Grid, Excel macros and cell functions format the contents of single cells or cell ranges and present them in reports as populated user forms, charts/graphs, grids, lists, text blocks, hyperlinks, etc. as specified by the template’s models. The models may limit reports to single views or provide user interactivity that enables different views of the data (e.g., data slicing/dicing/drill-down, “what-if” scenarios, choice of graphs, etc.). And if a composite report is to be generated, the Subscriber node takes multiple Content Files from one or more Publisher nodes and parses each on to pre-defined portions of the CFC Grid. It then combines parts of this content as defined by its models and renders it accordingly.


• In addition to (or instead of) presenting reports through the Excel workbook, the Subscriber/Presenter Template could enable third-party report writers to access the CFC Grid and generate the reports. Or it can send the data from the Content File to a database the third-party report writers can access.


• If a Subscriber/Presenter Template is configured to populate databases with the data from Content Files for report generation or other purposes, it must have the proper SQL/ODBC query code (macro/script) including the correct login ID & password and ODBC drivers. In addition, the proper fields and records must be identified, as well as the particular spreadsheet cells from which the data are to be obtained.