Closed rbeckman-nextgen closed 4 years ago
I will supply a patch soon, that implements custom validation into Mirth.
Imported Comment. Original Details: Author: dabuddhaman Created: 2006-08-29T12:50:51.000-0700
HL7 defined "Message Profile". Using message profiles for the validation of the message is in my opinion something that should be available there.
Imported Comment. Original Details: Author: eric Created: 2006-09-04T01:11:17.000-0700
Could this be done with filtering rules?
Imported Comment. Original Details: Author: chrisl Created: 2007-01-30T10:36:41.000-0800
Mirth now includes the option to:
Additional business logic should be performed in filters/transformers.
Imported Comment. Original Details: Author: chrisl Created: 2007-03-21T02:14:21.000-0700
A nice want to have feature for mirth would be custom validation filtering.
Nowadays (version 1.1.0) Mirth uses no HL7 messages validation. As you can see in http://svn.sourceforge.net/viewvc/mirth/trunk/server/src/com/webreach/mirth/server/mule/util/ER7Util.java?view=markup
PipeParser pipeParser = new PipeParser(); // disables all message validation pipeParser.setValidationContext(new NoValidation());
and
XMLParser xmlParser = new DefaultXMLParser(); // disables all message validation xmlParser.setValidationContext(new NoValidation());
the default HAPI validation mechanism (DefaultValidation - see http://hl7api.cvs.sourceforge.net/hl7api/hapi/ca/uhn/hl7v2/validation/impl/DefaultValidation.java?view=markup) is disabled/overriden with no validation (NoValidation - see http://hl7api.cvs.sourceforge.net/hl7api/hapi/ca/uhn/hl7v2/validation/impl/NoValidation.java?view=markup)
Now we could implement custom validation into Mirth (next to filtering and transforming) for every destination.
Something like right click on a destination -> Edit Validation Now you could see a screen with a list with 4 columns where you can add your custom rules: 1st column: the hl7 version (* for all the versions) 2nd column: the scope (ex: "NM", "ST", "ID") (select from a list of all the available datatypes) 3th column: the rule name (ex: TrimLeadingWhitespace, SizeRule, RegexPrimitiveRule) 4th column: the rule parameter, this is not for every rule required
Now whenever the message get parsed instead of the NoValidation we can use our own validation! If the message doesn't pass the validation the message will never get to it's destination and can be logged or stored in an error queue.
Imported Issue. Original Details: Jira Issue Key: MIRTH-1 Reporter: dabuddhaman Created: 2006-08-29T12:46:58.000-0700