Configuring the Evidence Broker for use with the Holding Case

The Holding Case is of little value by itself, it is simply, as the name implies, a Holding Area for Evidence before it is sent somewhere else. Normally the goal once data has been updated on the Holding Case, is to broker these updates to Integrated Cases so that Case Workers can vet the changes and apply them to the relevant cases. Once the data is accepted onto the Integrated Cases then James will start to see the positive impact of submitting a Life Event as the updated data can start to have an impact on his benefits. The bridge between the Holding Case and the Integrated Cases can only be crossed if the appropriate Evidence Broker configuration is defined. This section demonstrates how that can be achieved. For background on the Evidence Broker the reader is referred to the Developer Guide: Cúram Evidence Broker Developers Guide.

Configuring Sharing from The Holding Case

Below is an example evidence configuration for sharing of Pregnancy evidence from the Holding Case to an Integrated Case.

<?xml version="1.0" encoding="UTF-8"?>
  <table name="EVIDENCEBROKERCONFIG">
    <column name="EVIDENCEBROKERCONFIGID" type="id"/>
    <column name="SOURCETYPE" type="text" />
    <column name="SOURCEID" type="id" />
    <column name="TARGETTYPE" type="text" />
    <column name="TARGETID" type="id"/>
    <column name="SOURCEEVIDENCETYPE" type="text"/>
    <column name="TARGETEVIDENCETYPE" type="text"/>
    <column name="AUTOACCEPTIND" type="bool"/>
    <column name="WEBSERVICESIND" type="bool"/>
    <column name="SHAREDTYPE" type="text"/>
    <column name="RECORDSTATUS" type="text"/>
    <column name="VERSIONNO" type="number"/>              
    <row>
      <attribute name="EVIDENCEBROKERCONFIGID">
        <value>10003</value>
      </attribute>
      <attribute name="SOURCETYPE">
        <value>CT10301</value>
      </attribute>
      <attribute name="SOURCEID">
        <value>10330</value>
      </attribute>
      <attribute name="TARGETTYPE">
        <value>CT5</value>
      </attribute>
      <attribute name="TARGETID">
        <value>4</value>
      </attribute>
      <attribute name="SOURCEEVIDENCETYPE">
        <value>ET10000</value>
      </attribute>
      <attribute name="TARGETEVIDENCETYPE">
        <value>ET10074</value>
      </attribute>
      <attribute name="AUTOACCEPTIND">
        <value>0</value>
      </attribute>
      <attribute name="WEBSERVICESIND">
        <value>0</value>
      </attribute>
      <attribute name="SHAREDTYPE">
        <value>SET2002</value>
      </attribute>
      <attribute name="RECORDSTATUS">
        <value>RST1</value>
      </attribute>
      <attribute name="VERSIONNO">
        <value>1</value>
      </attribute>
    </row>    
  </table>

When sharing from the Holding Case to another Integrated Case, the source type should be CT10301 and the source id should be set to 10330. The source evidence type should be set to ET10000, which is the code for all Evidence stored in Holding Cases. Evidence of this type is known as Holding Evidence. The target evidence type in this case is ET10074. In Cúram Common Evidence this identifies Pregnancy Evidence. The evidence sharing type should be set to SET2002 which is the code for Non-Identical Sharing. Note, that the AUTOACCEPTIND is set to 0. It is strongly recommended that this always be set to 0 when sharing from a Holding Case to an Integrated Case. This setting means that a Case Worker will always get to vet any changes that have come in from the Citizen's Holding Case. Assuming the Case Worker agrees with the changes, the "Incoming Evidence" link of the Integrated Case Evidence page can be used to synchronize the data from the Holding Case in the normal way.

To establish Evidence Broker Configuration for a custom component, a dmx file must be created containing configuration that follows the example given above. For example: %SERVER_DIR%\components\Custom\data\initial\EBROKER_CONFIG.dmx

In sharing Holding Evidence to a Standard Evidence Entity like a Pregnancy the Evidence Broker "copies" the Holding Evidence containing the Pregnancy data into a new Pregnancy Evidence Record in the target Integrated Case. Previously this guide has alluded to the fact that Holding Evidence is not "standard" Evidence. In fact it is stored in an XML representation, so in the process of copying the Holding Evidence to the Target Evidence type the Evidence Broker must perform a conversion of the XML data into standard Evidence data. To assist with this conversion process it is necessary to supply meta-data. An example of this meta-data is illustrated below:

<?xml version="1.0" encoding="UTF-8"?>
<data-hub-config>              
  <evidence-config package="curam.holdingcase.evidence">
    <entity name="HoldingEvidence" ev-type-code="ET10000">
      <attribute name="entityStruct">
        curam.citizen.datahub.holdingcase.holdingevidence.struct.
        +HoldingEvidenceDtls
      </attribute>
    </entity>
    <entity name="Pregnancy" ev-type-code="ET10074"> 
      <attribute name="entityStruct">
        curam.evidence.entity.struct.PregnancyDtls
      </attribute>
      <related-entity>
        <case-participant-role>
          <attribute name="linkAttribute">
            fahCaseParticipantRoleID
          </attribute>
        </case-participant-role> 
        <case-participant-role>
          <attribute name="linkAttribute">
            caseParticipantRoleID
          </attribute>
        </case-participant-role> 
      </related-entity>          
    </entity>
  </evidence-config>   
</data-hub-config>

The meta data describes each of the entities that can be copied from the Holding Case to an Integrated Case and vice versa. The meta data describes the dtls structs that are used to build the target evidence. It also describes which of the attributes in Case Evidence refer to case participant roles. This information ensures that when the Holding Evidence is copied, it doesn't just blindly copy case participant role identifiers from holding evidence, instead it looks for the equivalent case participant role id on the target case and, if it doesn't exist, then creates one.

This meta data is stored in a an AppResource (For more information about AppResources, refer to the Cúram Developer Guide Authoring Scripts in IEG2). The resource store key is identified by the Cúram Environment Property curam.workspaceservices.datahub.metadata. Out of the box the value for this variable defaults to the value curam.workspaceservices.datahub.metadata. This points to some default Holding Evidence Data Hub Meta Data. The following steps can be used to replace the default Holding Evidence Data Hub Meta Data with a custom version to support all Evidence Types that need to be brokered from the Holding Case to all Integrated Cases.

Copy the contents of %SERVER_DIR%\components\WorkspaceServices\data\initial\clob\DataHubMetaData.xml to %SERVER_DIR%\components\Custom\data\initial\clob\CustomDataHubMetaData.xml
Edit the contents of CustomDataHubMetaData.xml to describe all the Evidence Entities that need to be updated by the Data Hub.

Create a file %SERVER_DIR%\components\Custom\data\initial\APP_RESOURCES.dmx. Add an entry to this file as follows.

<?xml version="1.0" encoding="UTF-8"?>
  <table name="APPRESOURCE">
    <column name="resourceid" type="id" />
    <column name="localeIdentifier" type="text"/>
    <column name="name" type="text"/>
    <column name="contentType" type="text"/>
    <column name="contentDisposition" type="text"/>
    <column name="content" type="blob"/>
    <column name="internal" type="bool"/>
    <column name="lastWritten" type="timestamp"/>
    <column name="versionNo" type="number"/>
    <row>
      <attribute name="resourceID">
        <value>10700</value>
      </attribute>
      <attribute name="localeIdentifier">
        <value/>
      </attribute>
      <attribute name="name">
        <value>custom.datahub.metadata</value>
      </attribute>
      <attribute name="contentType">
        <value>text/plain</value>
      </attribute>
      <attribute name="contentDisposition">
        <value>inline</value>
      </attribute>
      <attribute name="content">
        <value>
          ./Custom/data/initial/clob/CustomDataHubMetaData.xml
        </value>
      </attribute>
      <attribute name="internal">
        <value>0</value>
      </attribute>
      <attribute name="lastWritten">
        <value>SYSTIME</value>
      </attribute>
      <attribute name="versionNo">
        <value>1</value>
      </attribute>
    </row>
  </table>

Create or append to the file %SERVER_DIR%\components\Custom\properties\Environment.xml adding an entry along the following lines:

<environment>
   <type name="dynamic_properties">
     <section code="WSSVCS"
       name="Workspace Services - Configuration">
       <variable name="curam.workspaceservices.datahub.metadata"
         value="custom.datahub.metadata" onlyin="all" 
         type="STRING">
         <comment>
           Identifies an AppResource used to configure DataHub
           meta-data.
         </comment>
       </variable>
     </section>
   </type>
 </environment>

Round Tripping and Configuring Sharing to The Holding Case

The previous section described how data is shared from the Holding Case to Integrated Cases. Analysts may also want to consider whether evidence should be transferred in the opposite direction, that is from the Integrated Cases to the Holding Case. When sharing is configured from the Integrated Case to the Holding Case, changes made by the Case Worker to selected evidence can be propagated back to the Holding Case. This is essential for Life Events that need to pre-populate data from Evidence Entities in existing Integrated Cases. The example below shows how to configure Pregnancy Evidence for Sharing to the holding case.

<?xml version="1.0" encoding="UTF-8"?>
<table name="EVIDENCEBROKERCONFIG">
  <column name="EVIDENCEBROKERCONFIGID" type="id"/>
  <column name="SOURCETYPE" type="text" />
  <column name="SOURCEID" type="id" />
  <column name="TARGETTYPE" type="text" />
  <column name="TARGETID" type="id"/>
  <column name="SOURCEEVIDENCETYPE" type="text"/>
  <column name="TARGETEVIDENCETYPE" type="text"/>
  <column name="AUTOACCEPTIND" type="bool"/>
  <column name="WEBSERVICESIND" type="bool"/>
  <column name="SHAREDTYPE" type="text"/>
  <column name="RECORDSTATUS" type="text"/>
  <column name="VERSIONNO" type="number"/>
  <row>
    <attribute name="EVIDENCEBROKERCONFIGID">
      <value>2</value>
    </attribute>
    <attribute name="SOURCETYPE">
      <value>CT5</value>
    </attribute>
    <attribute name="SOURCEID">
      <value>4</value>
    </attribute>
    <attribute name="TARGETTYPE">
      <value>CT10301</value>
    </attribute>
    <attribute name="TARGETID">
      <value>10330</value>
    </attribute>
    <attribute name="SOURCEEVIDENCETYPE">
      <value>ET10074</value>
    </attribute>
    <attribute name="TARGETEVIDENCETYPE">
      <value>ET10000</value>
    </attribute>
    <attribute name="AUTOACCEPTIND">
      <value>1</value>
    </attribute>
    <attribute name="WEBSERVICESIND">
      <value>0</value>
    </attribute>
    <attribute name="SHAREDTYPE">
      <value>SET2002</value>
    </attribute>
    <attribute name="RECORDSTATUS">
      <value>RST1</value>
    </attribute>
    <attribute name="VERSIONNO">
      <value>1</value>
    </attribute>
  </row>
</table>

Note that, unlike Sharing from Holding Case to Integrated Case, the AUTOACCEPTIND is set to 1. This is because the target case is a Holding Case and Holding Cases are designed to operate unattended. It is not expected that Case Workers should need to review items being shared onto the Holding Case as they come from an authoritative source, i.e. the Integrated Case.

Issues for Consideration

With suitable configuration, It is possible to share data from the Holding Case to many different Integrated Cases. Imagine that two different Integrated Cases A and B are configured to share information with a James' Holding Case H. Both cases A and B have separately recorded an Income Evidence record for James. In James' Holding Case this will show up as two separate Income Records and as far as cases A and B are concerned they are two entirely separate records, A's view of James' Income and B's view of James' Income. To James however this might not make much sense - he has only one Income and is using one Portal to communicate with the SEM or SEMs concerned. Why should he see two records for the same Income? In cases like this, where there is sharing to multiple Integrated Cases from a single Holding Case, consideration should be given to creating another set of sharing relationships should be established from A to B and B to A. This is an issue that will require proper consideration early on in the project Life Cycle.