crs4 / hl7apy

Python library to parse, create and handle HL7 v2 messages.
http://crs4.github.io/hl7apy/
MIT License
231 stars 91 forks source link

ORU_R01 not validating correctly #71

Closed jarzombekdavid closed 4 years ago

jarzombekdavid commented 4 years ago

Running on python 3.6 and hl7apy version 1.3.3

I'm having issue with message validation for ORU^R01. I am running the below code for the below hl7messages. I believe they are valid though with fake data and I keep getting the below validation issues. Is this expected behavior? I've tried both STRICT and TOLERANT validation levels. I've also tried this on real hl7 messages omitted due to the inclusion of phi but I get the same problems.

msg1 = '''MSH|^~\&||VendorCode||accountID|20160205022300||ORU^R01^ORU_R01|msgcontrolID|P|2.5.1|||AL|AL|||||LRI_NG_RN_Profile^^2.16.840.1.113883.9.20^ISO
PID|1||PATID1234^^^^MR~PATID1234567^^^^MR||Patient^Carol^Middle|||F|
ORC|CA|Placer1234|Filler56789|||||||||12345678923^Provider^Stephanie
OBR|1|Placer1234|Filler56789|57021-8^CBC W Auto Differential panel inBlood^LN^^^^^^CBC W Auto Differential panel in Blood|||ObservationDate/Time|||||||||12345678923^Provider^Stephanie||||||ResultReportedDate/Time|||ResultStatus(From HL7 table 0123)
OBX|1|NM|718-7^Hemoglobin [Mass/volume] in Blood^LN^^^^^^Hemoglobin[Mass/volume] in Blood||5.5|mEq/L|2.5-5.3|H|||Status|||20120816122332|||||||||Performing Lab|1234 AnyStreet^Any Town^CA^94102
OBX|2|ED|PDF^PDF||^AP^^Base64^[base64 encoded PDFstrain]||||||F|||20120816122332|||||||||Performing Lab|1234 AnyStreet^Any Town^CA^94102'''

msg2 = '''MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4
PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||123 LONGROAD DR.^^CITY1^OH^12345||(206)1231234|(206)123-1234||||AC555444444||67-A4335^OH^20030520
OBR|1|845439^GHH OE|1045813^GHH LAB|1554-5^GLUCOSE|||200202150730|||||||||555-55-5555^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD
OBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F'''

src = msg2.replace('\n', '\r')
msg = parse_message(src, find_groups=False)
msg.validate()
Traceback (most recent call last):
  File "/hl7/test.py", line 21, in 
    v.validate(msg)
  File "/env/lib/python3.6/site-packages/hl7apy/validation.py", line 208, in validate
    raise errors[0]
hl7apy.exceptions.ValidationError: Invalid children detected for Message ORU_R01: ['OBR', 'OBX', 'PID']
src = msg2.replace('\n', '\r')
msg = parse_message(src, find_groups=True)
msg.validate()
Traceback (most recent call last):
  File "/hl7/test.py", line 19, in 
    msg.validate()
  File "/env/lib/python3.6/site-packages/hl7apy/core.py", line 749, in validate
    return Validator.validate(self, reference=self.reference, report_file=report_file)
  File "/env/lib/python3.6/site-packages/hl7apy/validation.py", line 208, in validate
    raise errors[0]
hl7apy.exceptions.ValidationError: Invalid children detected for Field OBR_31 (REASON_FOR_STUDY) of type CE: [None]
svituz commented 4 years ago

Hi @jarzombekdavid, I actually think the package is right: your OBR_31 field is of type CE, which should have 6 components, according to specification, while your messages have 7 components, so validation fails.

PS: Validation is always performed with STRICT level. You can parse a message using TOLERANT level but validation is performed against the official structures using STRICT policy. We implemented a TOLERANT level since we are aware that the real world doesn't always conform to specification (sic!)

jarzombekdavid commented 4 years ago

Ah ok that makes sense I miss-understood. I thought validation had different levels itself but that totally makes sense in terms of it just allowing the message to be parsed.