List of enhancements to the HL7 Accelerator experience in BizTalk Server.

  1. The BizTalk HL7 Accelerator (BTAHL7) is non-compliant with the HL7 2.4 (and 2.3.1) Specification 2.10 in the following manners:
    1. Step 1 Message Construction (serialization):
      1. b.2 if the [field] value is not present, no further characters are required
      2. b.5.iv components that are not present at the end of a field need not be represented by component separators
      3. b.6.iv subcomponents that are not present at the end of a component need not be represented by subcomponent separators
        1. In all of the above cases, the requirement is that the object with no value does not require a delimiter for it, but is certainly gives the implementer the latitude to include it. Incorrectly, BTAHL7 throws a parse error if a sending system sends delimiters at the end of a value that are empty.
        2. The desired behavior is that BTAHL7 quietly accepts any empty field at the end of any object in the system. This behavior is over ridden using a pipeline property or on a party by party basis, but by default the behavior is breaking.
        3. EXAMPLES:

        Field:

        Case 1: Field is not last field in segment:
        NTE|| -> This will cause the parse to fail unless it is the "Allow Trailing Delimiters" flag is set.

        Case 2: Field is last field in segment:

        NTE||| -> This will always fail because BizTalk attempts to parse the extra field in the segment into a non-existent field in the segment.

    2. Step 2 Converting Messages to data values (deserialization):
      1. ignore segments, fields, components, subcomponents, and extra repetitions of a field that are present but were not expected.
        1. BTAHL7 does not ignore any segments, fields, components, subcomponents or extra repetitions if they are not expected. Instead a parse error is thrown and the message is rejected.
        2. The desired behavior is that the HL7 Accelerator retains the extra data for transmission but does not capture the data for processing; additionally this should not cause a parse error.
      2. treat segments that were expected but are not present as consisting entirely of fields that are not present
        1. BTAHL7 does handle this correctly, but the error messages are generally inscrutable if the captured data does not contain required objects.
        2. The desired behavior is that BTAHL7 clearly points to the error.

    The overall impact of the non-compliant behavior is that the HL7 accelerator places a tremendous implementation burden on the implementer. Instead of concerning themselves with values of interest in the message, they spend a tremendous amount of time matching the current system requirements to the HL7 Accelerator defined specification. This increases the implementation time, reduces the flexibility of the solution and in general, makes any BizTalk solution extremely expensive.

  2. The BizTalk Server model differentiates between various participants in the entire BizTalk Process.
    1. Business Analyst (BA)
    2. Solution Developer (SD)
    3. Operations Manager (OM)

    The HL7 Accelerator does not match this model. I believe that this lack of separation has made the entire HL7 Accelerator solution difficult to implement and complete solution engaging all of the roles that are involved. The BA has to provide an HL7 Solution definition that does not reflect the desired solution, for instance, they create a spread sheet or a word document that defines the message structure very loosely. There is no was for the BA to tell the SD what message definition and variations are required from the HL7 Standard. The only way to define the message is to directly edit the Schema in the BizTalk Schema editor. The only way to define transformations from Message Schema A to Message Schema B is in the BizTalk Mapper. The BA is completely disassociated from the definition process. They have to communicate via documents (Word or Excel) and then test the results using sample messages. The OM has control over the solution in such a way via the HL7 Configurator that should only be defined at the Development level. This disconnect makes it difficult for the appropriate roles to be applied and frustrates the users at each level.

  3. The BizTalk Accelerator solution is difficult to debug and troubleshoot. The Developer has to deploy the schemas and pipelines and then manually submit the messages.
    1. Cannot test Schemas and Maps in the IDE you must deploy the entire solution to validate them.
    2. The HL7 Tables/Segments/Datatypes always have a global impact and are difficult to separate out. The relationship between them is not obvious and the XML editor is extremely difficult to master. This is resolved by using namespaces to separate the schemas, but even that solution is extremely complex.
    3. Editing of table values is difficult and not obvious. There is no way to easily import BA defined values into the table definitions.
    4. The MLLP Test tools are difficult to use and inflexible and seem to be as if they were written at the last minute. When errors are encountered, the tools simply throw an undecipherable exception message instead of reporting a helpful error message.
    5. The MLLP Test tools cannot help the solution test high volume message loading. The tools allow you to either send a single message repeatedly very quickly, or you must simply rerun the tool in some kind of loop in the console which processes relatively slowly.
  4. The HL7 Accelerator does not expose any helpful .Net Classes to help decode/encode and handle message content.
    1. The HL7 DateTime field does not map exactly to a .Net class. For instance, the HL7 DT field has 4 digits to the right of the decimal point (ss.mmmm) and the .Net DateTime Type only had 3 (ss.mmm) and so either you must accept a loss of precision (not acceptable for certain lab testing results where the value is a critical measurement) or construct a custom .Net HL7 DateTime datatype to hold this value, deserialize/serialize it and handle it.
    2. The HL7 Serialization/Deserialization does not allow you to choose to accept invalid messages. In other words, the user may want to accept a message that will parse, and then run a second pass on it to validate the data. To do this requires two schemas to be deployed, a loose schema for initial validation and a second tighter schema that must be called to revalidate the message for deeper content validation. It would help that you could turn off validation at the field level using configuration and then determine at which pass the validation will occur.
    3. Promoting message content properties is difficult. For instance, there are many message properties that clients almost invariably want to monitor. Patient Information, Lab Test information, MSH Tracking fields like MSH7 and MSH10 to correlate the message back to the sending system and Provider information. It is certainly possible to build an XPath based property promoter and construct a Property Schema to do this, but pipeline components are always problematic and considering the likelihood that client will want to do this, it seems that a simple pre-built component should already exist and be inside the HL7 Deserializer/Serializer to handle this.
  5. The HL7 Accelerator and BizTalk do not work well together to allow multiple message types that have very similar structure to be routed to a single orchestration and then sent to end points for processing.
    1. The ADT and ORM Messages have many trigger types, but need to be handled similarly. To process the messages the implementer must create many send ports for each message type, but they all go to the same physical send port. Every change to the Orchestration send port, typically requires the implementer to make as many as numerous port changes in a single orchestration. Also, the Send Orchestration ended up being extremely complex to handle all the various message triggers for the same message.
    2. The HL7 Send Ports cannot handle System.Xml documents. The message context contains the schema to use, but the Send port cannot handle the generic message type and cast it to the correct message type. This means that every send port in an orchestration must be strongly typed.
    3. The MLLP Send Port does not allow dynamic send ports making it difficult to use a single send port to send to multiple end points programmatically.
    4. Because of the limitation on the System.Xml documents, it is not possible to use some of the more advanced features in BizTalk like dynamic mapping. Thus all messages must be strongly typed and constructed.
  6. The System does not interact with some of the HL7.org tools and schemas well.
    1. HL7.org provides a powerful tool that allows a Business Analyst to modify, design, diff and export to RIM HL7 Message definitions. Just looking at the feature set of Message Work Bench (http://www.hl7.org/), at a minimum this tool is a tremendous guide to what kind of features a Business Analyst would need.
      1. Diff two schemas
      2. Capture a message and generate a best guess at a schema
      3. Capture a message and verify conformance to a user defined schema
      4. Extensible Table editing for HL7 conformance values
      5. export of a BA Defined schema in xsd format that is not compatible with the BizTalk Schemas.
      6. HTML (XML with XSLT) generation of a readable message specification
      7. Innumerable reports about a message definition
      8. Capture a message and insert sample values from the message into a specification.
  7. Users define custom schemas that have both subtle and widely variant message definitions in comparison to the specification
    1. Make it easier to capture a running message stream and have a wizard that automatically picks a "best matching" schema and adjusts the schema automatically to the actual message data. So that during the design phase, a BizTalk solution could be running in learn mode and then as it runs reports what messages that have failed and make it easy for the implementer to update the schema to allow those messages.
    2. Define reporting tools and mechanisms that update the schema on the fly, suspending messages and then letting the Operations team report and then adjust the schema and resubmit the message automatically.