Documentation
¶
Overview ¶
Package sanitizer illustrates how the Rewrite capabilities of the HL7 library can be utilised to deal with tweaks of HL7v2.
Index ¶
Constants ¶
This section is empty.
Variables ¶
var CommonNormalizedDeathIndicator = map[string]string{
"y": "Y",
"yes": "Y",
"Deceased": "Y",
"deceased": "Y",
"n": "N",
"no": "N",
"Y": "Y",
"YES": "Y",
"DECEASED": "Y",
"N": "N",
"NO": "N",
}
CommonNormalizedDeathIndicator contains the most common mappings for death indicators.
Functions ¶
This section is empty.
Types ¶
type Message ¶
type Message struct{ Message string }
Message is a message used as input for the Sanitizer.
type MessageSanitizer ¶
type MessageSanitizer struct {
// The list of Universal Service Identifiers that define a message as a Vital Signs message.
VitalSignsUSIs []string
// OBXRemovalStatus is a list of observation statuses that, if found, the OBX segment will be removed.
OBXRemovalStatus []string
// UnescapeOBXValues determines whether to unescape obx value field.
UnescapeOBXValues bool
// Whether to rewrite patient identifiers
RewritePatientIdentifiers bool
AddMRN bool
RewriteIdentifierLocations []string
// Whether to squash OBXs
// Generally this will depend on parameters such as the sendingApplication, sendingFacility, messageType...
ShouldSquashOBXs func(message *hl7.Message) bool
// Map from old sending facilities to the new one
OldSendingFacilities map[string]string
// Whether to strip zeros from MRN fields
RemoveLeadingZerosFromMRN bool
// Map of death indicators to the correct one
DeathIndicatorNormalizer map[string]string
}
MessageSanitizer is a message sanitizer. The fields represent configuration that might be useful in a real setting.
func (MessageSanitizer) SanitizeMessage ¶
SanitizeMessage removes known partner-specific nuances in the HL7 format. For instance, even if there's a reserved field to send a patient's zip code, some partners might use a different field. The sanitization process modifies the underlying HL7 message and unifies it for all partners so that downstream services don't have to deal with such nuances. The sanitization step also takes care of known problems within a partner's messages, for instance, it can fix known parsing errors without failing the parsing stage. The MSH segment in the message needs to be present and parsable, otherwise an error is returned. After the sanitization, if there were no errors, the returned message will have the following properties: * All messages will have valid and parsable MSH, PID and ZCM segments. * Vital Signs messages will also have parsable OBR and OBX segments, if present. If an error is returned, it will be a SanitizerError. An error of type MESSAGE_SANITIZATION_FAILURE means that something went wrong while sanitizing; any other error indicates a problem with the message.
Source Files