HDR Inbound Message Processor

The Inbound Message Processor (IMP) lets HDR receive inbound HL7 version 3.0 messages, compliant with HDR messaging schema, from sending systems and persist information to the HDR repository.

IMP provides a processMessage API to persist a HL7 V3 message, which returns a Result object containing the acknowledgement. IMP provides an invalidateCache API that will invalidate the configuration cache.

To persist a message, user must configure sender, sender interaction, and side effect for the message and create the receiver of the message as an organization in HDR. You can use Messaging Configuration Service or IMP Configuration Administration Service to do IMP configuration.

IMP extracts Sender, Receiver, and Interaction Id available in the message, and picks up the associated side effect configuration. Based on the side effect configuration, IMP sets the Reference Modifier on RIM Objects of the message. Based on which, RIM objects available in the message is created, updated, overlaid or ignored. There are certain rules that influence the value of Reference Modifier to be set on RIM Objects, which is described in the section Side Effect Configuration Rules.

After persisting the message, IMP returns a successful acknowledgment (AA), if the message is persisted successfully. IMP rejects a message with an Application Error (AE) typecode, if the content or format of the message is incorrect (such as identified object validation failed, mandatory code attribute missing). IMP rejects a message with an Application Reject (AR) typecode, if message processing fails for any reason unrelated to the content or format of the message (such as system down, internal error, and so on).

Messaging Schema

HDR includes messaging schemas for all supported message types. Messaging schema includes the following for each message type:

Schema (XSD Files) for the Payload of the Message Type
Composite Message Schema (XSD File) for each Interaction ID of the Message Type
Model Interchange Files (MIF files) for the Payload of the Message Type

In addition, messaging schema contains a common Vocabulary schema and data type schema for all message types.

The Composite Message Schema (CMS) has three parts: Message Wrapper, Control Act Wrapper, and Payload Reference. If there are three Interaction IDs seeded for the same Payload, there will be three composite message schemas; one for each Interaction ID and all of them will refer to the same Payload.

For samples, refer to the schemas for Lab Result available at the following locations:

Payload Schema for a Message Type (Lab Result)
<hdr_domain_home>/config/hdr/message/defs/rim214101/schemas/POLB_MT004000HT01.xsd
Composite Message Schema for Interaction Ids POLB_IN004003, POLB_IN004004 (Lab Result)
<hdr_domain_home>/config/hdr/message/defs/rim214101/schemas/POLB_IN004003.xsd

<hdr_domain_home>/config/hdr/message/defs/rim214101/schemas/POLB_IN004004.xsd
Common Data Type Schemas
<hdr_domain_home>/config/hdr/message/defs/rim214101/coreschemas/datatypes.xsd

<hdr_domain_home>/config/hdr/message/defs/rim214101/coreschemas/datatypes-base.xsd
Common Vocabulary Schemas
<hdr_domain_home>/config/hdr/message/defs/rim214101/coreschemas/datatypes.xsd

<hdr_domain_home>/config/hdr/message/defs/rim214101/coreschemas/datatypes-base.xsd

For more information on message types supported, refer to the Oracle Healthcare Data Repository HL7 Version 3 Conformance Specification.

Acknowledgement Processing

Upon receipt of a message from the sending application (the source of the message), IMP synchronously processes the message into HDR, and returns an Application Acknowledgment (AA), an Application Error (AE), or an Application Reject (AR).

Application Acknowledgement (AA): An AA response indicates that the message was successfully processed and persisted in HDR.
Application Error (AE): An AE response indicates an error reported by HDR, including error information in message content or format (error type code, error detail code, free text). It is the responsibility of the interface engine to determine if the acknowledgement message is returned to the sending system or if the message should be resent to HDR or skipped (abandoning the message). IMP does not support sequence number protocol--the interface engine is responsible for assuring that messages are delivered in order.
Application Reject (AR): An AR response indicates that the message is rejected, for reasons unrelated to its content or format (system or network down, network transmission errors). For most such problems, the receiving system may be able to accept the message at a later time. The sending system or interface engine must decide on an application-specific basis whether the message should be sent again. Ultimately, the AR is resolved to either an AA (upon successful retransmission) or an AE--which thence generates a call to error processing.

The acknowledgement message contains the following XML segments:

Table 9-1 XML Segments in an Acknowledgement Message

Components	XPATH	Sample values
Acknowledgement Type	MCCI_MT002300HT01.Message/ acknowledgement/typeCode/@code	<typeCode code="AA"/> , <typeCode code="AE"/>, <typeCode code="AR"/>
Acknowledgement Detail Code	MCCI_MT002300HT01.Message/acknowledgement/ acknowledgementDetail/ code/@code	<code code="NS250" codeSystemName="AcknowledgementDetailCode"/>
Acknowledgement Error Text	MCCI_MT002300HT01.Message/acknowledgement/ acknowledgementDetail/ text	<text mediaType="text/plain" encoding="TXT"> Application: CTB, Message Name: CTB_MS_INVALID_PROCESS_MD_CD. Tokens: PROCESSING_MODE_CODE = T1; </text>
Acknowledgement Error Location	MCCI_MT002300HT01.Message/acknowledgement/ acknowledgementDetail/location	<location> CTB_MS_IMP_EXCEPTION_LOCATION2 :Error occurred while processing XML data located at line 6, column 30. XPATH: /PRPA_IN400000[1] COMPLEX_TYPE: MCCI_MT000100HT04.Message</location>
HDR Error Code	MCCI_MT002300HT01.Message/acknowledgement/ acknowledgementDetail/text	CTB_MS_INVALID_PROCESS_MD_CD
Responder Information	MCCI_MT002300HT01.Message/sender/device/id	<sender type="CommunicationFunction"> <typeCode code="SND"/> <device type="Device" classCode="DEV" determinerCode="INSTANCE"> <id root="9.989898.5.100" extension="ORG1000"/> <asAgent type="RoleHeir" classCode="AGNT"> <representedOrganization type="Organization" classCode="ORG" determinerCode="INSTANCE"> <id root="9.989898.5.100" extension="ORG1000"/> </representedOrganization> </asAgent> </device> </sender>

Sender Configuration

Before processing a message, the message type must be configured for the sender. IMP extracts Sender, Receiver, and Interaction Id available in the message, and picks up the associated side-effect configuration. If Interaction ID is not configured for the Sender and Receiver, IMP rejects the message.

Based on the side-effect configuration, IMP sets the reference modifier on RIM objects available in the message. If a particular RIM object is not configured for side-effect, IMP defaults the value of reference modifier for the RIM object to MUST_EXIST. There are certain side-effect rules in IMP that influences the value of reference modifier of a RIM Object.

Message Validation

In addition to being compliant with messaging schema, IMP imposes certain validations on messages before processing the message. Major validations that affect messages are described in this section.

Identified Object Processing

All RIM objects containing ids are identified objects. If a message instance contains repeating objects with same ids, IMP merges the information of repeating objects and persists union of data from different instances into HDR Repository. This is called Identified Object Processing. If the repeating objects in the message contain inconsistent information, IMP rejects the message. For example, if the age of a particular person (having same II) has different values at different segments of the message, IMP rejects the message. For information on complete set of rules to merge information of repeating objects, refer to the Oracle Healthcare Data Repository Programmer's Guide and Oracle Healthcare Data Repository Conformance Specification Guide.

Media Type and MIME Type Validation for CDA Messages

For CDA Message Types, IMP supports only certain Media Type and MIME Type. Refer to the CDA Message Type section of the Oracle Healthcare Data Repository Message Conformance Specification V6.1.

Master Catalog Validation

Master Catalog entries must exist in HDR Repository for all Acts, Entities, and Roles submitted to HDR for persistence.

Vocabulary Validation

Code System Names used in the message must be loaded into ETS and the Codes used should be part of Coding Scheme.

State Transition Validation

All Acts, Entities, and Roles submitted to HDR for persistence is subjected to Generic State Transition validation. The Focal object in the message is subjected to focal class state transition.

Immutable Attributes Validation

An update message cannot modify values of structural attributes and code (example, act.ClassCode) of an already persisted object.

RIM Service Validation

Every message is persisted as a control act graph in HDR Repository and subjected to the validations done by RIM Persistence Service.

Messaging Metadata

To process a message, IMP needs the following RMIM schematic information about the message elements:

Name of RIM Foundation Class of the RIM Object available in the message element.
Type of RIM Association.
Constrained RIM Data Type of the attribute.
If the association is a choice.

The RMIM schematic information is not available in the schemas for message types, but present in the MIF files for the same message type. The information is extracted from the MIF file and loaded into the database after installing HDR. This information is known as Messaging Metadata.

To load Messaging Metadata, use ConcurrentProgService.loadMessagingMetadata() API.

Profile Options and System Properties

Use the CTB: Store Incoming Message profile option to indicate whether the incoming message has to be stored or not. The valid values are Y and N. If the value is Y, the incoming message is stored in the submission unit table. If the value is N, the incoming message is not stored.

The following system properties impacts behavior of the IMP engine:

Table 9-2 IMP System Properties

Property Name	Valid Values	Description
IgnoreUnrecognizedElements	Y or N	With value 'N' throws an exception when an unrecognized RIM attribute is encountered. With 'Y', just skips it. If N, IMP throws an exception when an unrecognized RIM attribute is encounters. If Y, IMP skips the validation. The default value is N.
IMP_NONDESTRUCTIVE_MODE	Y or N	If Y, IMP rollbacks all transactions and does not update the audit log. The default value is N.
IMP_BUNDLED_MODE	Y or N	If Y, IMP collects all non-runtime exceptions, and continues processing. If N, each exception aborts processing immediately. The default value is N.

Configuring Interactions

IMP extracts Interaction Id and Trigger Event Code from the incoming message and checks whether it is configured or not. The following table lists the location of the parameters in the message

Table 9-4 Location of the Parameters in the Message

Parameter	XPath
Interaction Id	Top Level Element in the message. Example, PRPA_IN400000
Trigger Event Code	PRPA_IN400000/controlActProcess/code/@code

Interaction Ids for all supported message types are seeded. Refer to the Oracle Healthcare Data Repository HL7 Version 3 Conformance Specification for the list of seeded interaction ids. You can also configure new Interactions Id for supported messages. Use the Interactions window to configure new Interaction Id. For more information on the Interactions window, refer to Oracle Healthcare Data Repository User Interface Guide.

When you configure a new Interaction Id, an Interaction schema is generated by the Healthcare Data Repository User Interface and stored at the following location with the name of {InteractionId}.xsd::

<hdr_domain_home>/config/hdr/message/defs/customSchema/newMessageType/interaction.

Configuring Sender, Sender Interaction, and Side Effect

IMP extracts the following information (in the table) from the message and validates them for the configuration:

Table 9-5 Information Extracted and Validated by IMP

Parameter	XPath
Interaction Id	Top Level Element in the message. Example, PRPA_IN400000
Sender Root	PRPA_IN400000/sender/device/ id/@root
Sender Extension	PRPA_IN400000/sender/device/id/@extension
Receiver Root	PRPA_IN400000/receiver/device/asAgent/representedOrganization /id/@root
Receiver Extension	PRPA_IN400000/receiver/device/as Agent/representedOrganization/id/@extension
Trigger Event Code	PRPA_IN400000/controlActProcess/code/@code

If the Sender Root and Extension and Receiver Root and Extension is not configured, IMP rejects the message. This configuration thus controls a valid sender and HDR enterprises authorized to send messages. This is called the Sender Configuration.

Important: You must only use Organization's external II while creating sender configuration. You must not use any of the Internal IIs that are automatically generated in HDR.

Upon validation of the Sender Configuration, IMP uses its configuration to determine if the Interaction Id is valid for the Sender Configuration. If it is not configured for that Sender Configuration, IMP rejects the message. This configuration thus controls which types of Interaction Id a sender is permitted to send to a receiver. This is called the Sender Interaction Configuration.

Upon validation of the Sender Configuration and Sender Interaction Configuration combination, IMP processes the message payload. The focal object is created or updated in the HDR Repository. However, for non-focal objects, IMP inspects its side effect configuration to determine its behavior. You can configure IMP to let each non-focal object type create or not create the object if it is not present in the repository, and to update or overlay or not update or overlay the object if it is present in the repository. This configuration of side effects is called the Side Effect Configuration.

Use the IMPConfigAdminIntrService to configure sender and side effects.

Invoke Inbound Messaging Services

Reference

Oracle Healthcare Data Repository Javadoc
Oracle Healthcare Data Repository HL7 Version 3 Conformance Specification

The following table lists the principal IMP service and methods:

Table 9-6 Service and Methods: IMP

Level	Detail
Package	oracle.hsgbu.hdr.message.improcessor
Class	IMPService
Methods	processMessage
Class	RawIMPService
Methods	processMessage
Class	Result
Methods	getResponseXML getStatus getControlActId getTriggerEvent

This is an API-based implementation procedure.

Navigation

This is an API-based implementation procedure.

Steps

Use the Service Locator to access the IMP Service.

Note:
RawIMPService is implemented as a container-managed transactions (CMT) bean, and does not create SubmissionUnit. Use RawIMPService if you want to use the Java Transaction API (JTA) support of IMP.
Use the processMessage method with an HDR-compliant message (see following Note) as a parameter to invoke message processing services; a Result object is returned.
Use the following methods to inspect the result of processing the message:
- getResponseXML
- getStatus

Note:

IMP supports XML formatted inbound messages that conform to the HL7 version 3 messaging standard. The messages must conform to the messaging schema for the message types supported in HDR. The schemas for all supported message type is available at the following location:

<hdr_domain_home>/config/hdr/messge/defs/rim214101/schemas

The list of supported message types is provided in Oracle Healthcare Data Repository HL7 Version 3 Conformance Specification. Using Messaging Tool Kit, additional message types can be supported. For more information, refer to Oracle Healthcare Data Repository Messaging Tool Kit User Guide.

IMP Configuration API Usage

The Interaction ID based IMP Configuration Administration Service provides functions to create, remove, and find Sender Configurations. HDR Configuration Service also provides same functionality. To update a Sender Configuration, the client application removes it and creates the new Sender Configuration, including all of its child objects (sender interaction configuration and sender side effect configuration). HDR APIs support the following:

Moving configuration data from one environment to another
Writing loader applications

This section contains the following topics:

Note:

The client application must call the Master Catalog Service to resolve Master Catalog IDs.
You can use Messaging Configuration Service for updates.

Sender Configuration Attributes

Attribute Name	Field Type	Length	Mandatory	Description
Sender Id Root	`String`	240	Yes	Root part of the OID of the sending device
Sender Id Extension	`String`	240	Yes	Extension part of the OID of the sending device
Receiver Id Root	`String`	240	Yes	Root part of the OID of a valid organization registered in the system
Receiver Id Extension	`String`	240	No	Extension part of the OID of a valid organization registered in the system
Sender Interaction Configuration	`SenderInteractionConfiguration[]`	-	No	An array of Sender Interaction Configurations for this Sender Configuration

Sender Interaction Configuration Attributes

Attribute Name	Field Type	Length	Mandatory	Description
Interaction Id	`String`	80	Yes	Valid Interaction Id for this Sender Interaction Configuration
Sender Side Effect Configuration	`SenderSideEffectConfiguration[]`	-	No	An array, of Sender Side Effect Configurations, that defines permissions (create if/create or overlay/update/must exist/create or update) on referenced objects

Sender Side Effect Configuration Attributes

Attribute Name	Field Type	Length	Mandatory	Description
Master Catalog Id	`String`	-	Yes	The Master Catalog ID of the RIM object for which the side effect is configured. You can retrieve the Master Catalog details from the `MasterCatalogService`
Object Reference Modifier Code	`String`	-	No	Object reference modifier code value: `CREATE_IF, OVERLAY, CREATE_OR_OVERLAY, MUST_EXIST, UPDATE, CREATE_OR_UPDATE`
Player Reference Modifier Code	`String`	-	No	Player reference modifier code value: `CREATE_IF, OVERLAY, CREATE_OR_OVERLAY, MUST_EXIST, UPDATE, CREATE_OR_UPDATE`
Scoper Reference Modifier Code	`String`	-	No	Scoper reference modifier code value: `CREATE_IF, OVERLAY, CREATE_OR_OVERLAY, MUST_EXIST, UPDATE, CREATE_OR_UPDATE`

Figure 9-2 Sender Configuration Objects

Sender Configuration is the top-level object, with Sender Interaction Configuration object as its direct child. Sender Interaction Configuration object in turn has Sender Side Effect Configuration object as its child. The client application must create the complete hierarchy before invoking the create functionality. Before removing a Sender Configuration, the client application must invoke the finder API to get the handle associated with the target configuration item to delete.

Sender Configuration Search Parameters

SenderConfigSearchConfig is a criteria object passed to the finder API as a parameter. It provides methods to set search attributes used for retrieving the Sender Configuration and associated Sender Interaction Configurations and Sender Side Effect Configurations, based on the following parameters:

Sender Id Root
Sender Id Extension
Receiver Id Root
Receiver Id Extension

Because Receiver Id Extension can have a null value, in order to support a query where in the client application searches specifically for items with Receiver Id Extension as null value, a boolean flag ReceiverIdExtensionIsNull can be set to True. If ReceiverIdExtensionIsNull is not set or set to False, the criteria matches the given root and any extension.

IMP Sender Interaction Configuration Administration Service

The IMP Sender Interaction Configuration Administration Service lets the client application create, remove, and find Sender Configurations. The code samples that follow illustrate each of these use cases:

Note:

SenderConfigFactory class is not available from 8.0.

Create Function

This code sample creates a new sender:

Example 9-1 Sample Code to Create Sender Configuration Using the newXXX Functions Returning Empty Objects

public SenderConfiguration createSenderConfiguration()
{
SenderConfiguration senderConfig = new SenderConfigurationImpl();
        senderConfig.setSenderIdRoot(SND_ROOT);
        senderConfig.setSenderIdExtension(SND_EXTN);
        senderConfig.setReceiverIdRoot(RCV_ROOT);
        senderConfig.setReceiverIdExtension(RCV_EXTN);
        SenderInteractionConfiguration senderIntrConfig = new SenderInteractionConfigurationImpl();
        senderIntrConfig.setInteractionId(INTERACTION_ID[0]);
        SenderSideEffectConfiguration sseConfig = new SenderSideEffectConfigurationImpl();
        sseConfig.setObjectRefModifierCode(SenderSideEffectConfiguration.CREATE_OR_OVERLAY);
              sseConfig.setPlayerRefModifierCode(SenderSideEffectConfiguration.CREATE_OR_OVERLAY);
        sseConfig.setMasterCatalogId(MC_IDS[0]);
        SenderSideEffectConfiguration[] sseConfigs = { sseConfig };
        senderIntrConfig.setSenderSideEffectConfiguration(sseConfigs);
        SenderInteractionConfiguration[] senderIntrConfigs = { senderIntrConfig };
        senderConfig.setSenderInteractionConfigurations(senderIntrConfigs);
        SenderConfiguration createReturn = configService.createSenderConfiguration(senderConfig);
              return createReturn;

It is not mandatory to set the Receiver Extension on the Sender Configuration because this attribute is nullable. If a reference modifier code is not set, the value, the values defaults to null.

Find Function

This code sample lets the client application retrieve a Sender Configuration using the Sender Configuration Search Criteria:

Example 9-2 Sample Code to Find Sender Configuration Using the newXXX Functions Returning Empty Search Criteria

public SenderConfiguration[] findSenderConfiguration()
{
        SenderConfigSearchCriteria criteria = new SenderConfigSearchCriteriaImpl();
        criteria.setReceiverIdRoot(RCV_ROOT);
        criteria.setReceiverIdExtension(RCV_EXTN);
        criteria.setSenderIdRoot(SND_ROOT);
        criteria.setSenderIdExtension(SND_EXTN);
        SenderConfiguration[] queriedSenderConfigs = configService.findSenderConfiguration(criteria);
        return queriedSenderConfigs;

Because all Search Criteria setters are optional, all of the records are returned if you do not set any criteria. The Receiver Extension is the only attribute that is nullable, and is thus treated differentially here. You must either set the Receiver Id Extension to a particular non-null value or set the flag using the function setReceiverIdExtensionIsNull(boolean). Setting both results in a query that ignores the value set by setReceiverIdExtension(String). The boolean flag thus takes precedence over setting of the ReceiverId Extension to a particular value. Failing to set of them either lets the user search for all records-records with both null value and non-null value Receiver Id Extension attributes.

Remove Function

This code sample permits the deletion of a particular Sender Configuration and all its child elements. The client application is expected to invoke the find function to get a handle on the Sender Configuration it wants to delete.

Example 9-3 Sample Code to delete Sender Configuration

public void removeSenderConfiguration()
{
    SenderConfigSearchCriteria criteria = new SenderConfigSearchCriteriaImpl();

        criteria.setReceiverIdExtension(RCV_EXTN);
        criteria.setSenderIdRoot(SND_ROOT);
        criteria.setSenderIdExtension(SND_EXTN);
        criteria.setReceiverIdExtensionIsNull(false);
     (RCV_ROOT, RCV_EXTN, SND_ROOT,SND_EXTN, false);
criteria.setReceiverIdRoot(RCV_ROOT);
    SenderConfiguration[] senderConfigs = configService.findSenderConfiguration(criteria);
    if (senderConfigs != null && senderConfigs.length > 0)
    {
            for (int i = 0; i < senderConfigs.length; i++)
            {
              configService.removeSenderConfiguration(senderConfigs[i]);
            }
          }
}

Examples: This section contains the following examples:

Persist a Sample Message (see Example 9-4)
A Sample Acknowledgement Message (see Example 9-5)

Example 9-4 Persist a Sample Message

Perform the following steps to persist a sample encounter message:

Create the Receiver Organization (root="9.989898.5.100" extension = "ORG1000"), using RIM Service.
Load sender and side effect configuration for the message using Bulk Load Service.
Execute the program to persist the message. On successful persistence, IMP returns an acknowledgment.

Side Effect Configuration Rules

Following are the side effect processing rules enforced by IMP:Also, there are additional rules applied by RIM Services.

RIM objects without IDs are always created.
If side effect is not configured for a RIM Object, IMP defaults the reference modifier to MUST_EXIST.
For Focal Objects, IMP overrides any side effect configuration with reference modifier to CREATE_OR_OVERLAY.
If Focal Object is a role, player and scoper of the role are processed as per the side effect configuration for these entities, except Person and Unmerge messages. IMP overrides the configuration for player and scoper attached to the Focal Role of Person and Unmerge messages, with CREATE_OR_UPDATE.
All side effect processing follows the traversal path through the message model. This means that side effect processing is disabled for objects downstream from an object that has been configured as MUST EXIST.
If a backward/inbound participation to a role is referenced, the act that directly participates with that participation is processed as if CREATE_OR_UPDATE modifier is set on the act.
Owned roles are processed following the side effect processing of the Owning Entity. If the Owning Entity is configured for the side effect reference modifier as:
- CREATE_IF, and if it exists, the Owned Role and the associated entity are ignored.
- MUST_EXIST, the Owned Role and the associated entity are ignored.
- For other configurations, the Owned Role is always created or overlaid.
While processing Identified Objects, the merged object is assigned with the side effect of the object with the most restrictive side effect configuration.

Example 9-5 A Sample Acknowledgement Message

Acknowledgement message returned by IMP is compliant with HL7 V3 standard. The message contains the following elements:

Receiver (same as respond to in the processed message).
Sender (same as receiver in the processed message).
Acknowledgement typecode.
- AA - Message processed successfully.
- AE - Message processing failed.
- AR - Failed to process (reject) the message for reasons unrelated to its content or format (system down, internal error, and so on).
Error message, if message processing fails.
acknowledgementDetail. The element may be repeated couple of times, if there are multiple errors in the message. This element contains the following attributes:
- Code: corresponding HL acknowledgement detail code.
- Location: contains XPATH, XSD Complex Type Name, and line number of the message element responsible for the error.
- Text: contains error message. The error text message is represented in the following format: {ERROR CODE NAME}: {ERROR MESSAGE TEXT}.

The following is a complete xml message, as it appears in an acknowledgment message:

<MCCI_MT002300HT01.Message xmlns="urn:hl7-org:v3" type="Message" xmlns:htb="http://xmlns.oracle.com/apps/ctb/messaging">
     <id root="Messsage Id root value" extension="Message Id extension value"/>
    <creationTime value="Acknowledgement creation time"/>
     <responseModeCode code="D"/>
    <interactionId root="Interaction Id root value" extension="Interaction Id extension value"/>
    <processingMode code="P"/>
     <processingModeCode code="T"/>
     <acceptAckCode code="NE"/>
     <acknowledgement type="Acknowledgement">
        <typeCode code="Type Code (AA or AE)"/>
 
   <!--Use <acknowledgementDetail> only for typecode = AE, skipped for typecode = AA -->
    <acknowledgementDetail type="AcknowledgementDetail">
      <typeCode code="E"/>
      <code code="Error Code" codeSystemName="AcknowledgementDetailCode"/>
      <text mediaType="text/plain" encoding="TXT">Error Text</text>
	  <location>Error location</location>
    </acknowledgementDetail>
      <targetMessage type="Message">
         <id root="Inbound Wrapper Message Id root value" 
    extension="Inbound Wrapper Message Id extension value"/>
        </targetMessage>
      </acknowledgement>
      <receiver type="CommunicationFunction">
        <typeCode code="RCV"/>
        <device type="Device" classCode="DEV" determinerCode="INSTANCE">
          <id root="Inbound Wrapper Respond To Application Id root value"
    extension="Inbound Wrapper Respond To Application Id extension value"/>
          <asAgent type="RoleHeir" classCode="AGNT">
            <representedOrganization type="Organization" classCode="ORG" determinerCode="INSTANCE">
               <id root="Inbound Wrapper Respond To Enterprise Id root value"
      extension="Inbound Wrapper Respond To Enterprise Id extension value"/>
            </representedOrganization>
          </asAgent>
        </device>
      </receiver>
      <sender type="CommunicationFunction">
        <typeCode code="SND"/>
        <device type="Device" classCode="DEV" determinerCode="INSTANCE">
          <id root="Inbound Wrapper Target Enterprise Id root value" extension="Inbound Wrapper Target Enterprise Id extension value"/>
          <asAgent type="RoleHeir" classCode="AGNT">
            <representedOrganization type="Organization" classCode="ORG" determinerCode="INSTANCE">
              <id root="Inbound Wrapper Receiver Organization Id root value"
         extension="Inbound Wrapper Receiver Organazation Id extension value"/>
            </representedOrganization>
          </asAgent>
        </device>
      </sender>
    </MCCI_MT002300HT01.Message>

Task-Step	Description	Optional?	Interface
9-1	Configuring Interactions	Yes	API
9-2	Configuring Sender, Sender Interaction, and Side Effect	No	API
9-3	Invoke Inbound Messaging Services	Yes	API