Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating an OBX.5 field with ED data type breaks on toString #102

Open
andrezipf94 opened this issue Aug 10, 2023 · 5 comments
Open

Creating an OBX.5 field with ED data type breaks on toString #102

andrezipf94 opened this issue Aug 10, 2023 · 5 comments

Comments

@andrezipf94
Copy link

andrezipf94 commented Aug 10, 2023

Greetings!

I've been using the library to parse ORUs and ORMs, and have found out that when creating an OBX segment using the ED data type for OBX.5, it tries to implode() the segment array, but as ED.1 is also a complex data type (therefore an array), the implode fails causing an array to string conversion exception to be thrown.

Here's how the OBX structure looks like.
Screenshot 2023-08-10 at 17 33 46

From what I've gathered looking arround the conversion code, the implode happens at HL7/Message.php:336, and doesn't seem to support an complex data type inside a repetition.

Am I doing something wrong or should I work on a fix for this?

@senaranya
Copy link
Owner

Hello! Can you please give me a sample message, so that I can try it out? Please also share the expected and observed output for toString() from the sample

@andrezipf94
Copy link
Author

andrezipf94 commented Aug 11, 2023

I'm building the ORM segments arrays based on data from a DB.

This data was also consumed by HL7, using this library. The message I consumed was:

MSH|^~\&|Example|324|BWF|324|202303201305||ORM^O01|25847428|P|2.3
PID|1|123451|||LAST^FIRST^MIDDLE||19511108|M|LASTALIAS^FIRSTALIAS||456 7TH BLVD^^TAMPA^FL^33601||8135557126|2015558964|||||111223333
PV1|1||MAIN BLDG^room 103^^TEST LOC 1||||
ORC|NW|B1231230320020223B||||||||||1234567899^ProvLast^ProvFirstT^ProvMiddle||8131360140
OBR|1|B1231230320020223B||71046^X-RAY, CHEST, 2 VIEWS|||202303201415|202304201415||||||||1234567899^TEST^TEST^^^^^NPI|||||||||||^^^^^R||||Example reason for exam
DG1|1|I10|J10.08|
DG1|2|I10|F55.0|
OBX|1|ST|Example^Medical Necessity:||Traumatic Injury
OBX|4|ED||Signed Providers Order|Example&Example 2&^Clinical^multipart^PDF^Base64^JVBERi0xL~Example&Example 2&^Clinical^multipart^PDF^Base64^JVBERi0xL

Note: I've edited because I've added the wrong HL7 string before.

Just a important note, the message I've consumed did not have the repetition, but as my data mappings for the HL7 standart have them, when parsed into an array it also created the array of repetitions (containing a single element). In this case, I've added a repetition to maybe make it easier to debug on your side.

The expected output is basically the same ingested message.

The actual output was an Exception of type ErrorException:

Message: Warning: Array to string conversion
File: [...]aranyasen/hl7/src/HL7/Message.php
Line: 336

@andrezipf94
Copy link
Author

Just to add on that, I think the issue is that when inside a repetition the library doesn't account for complex data types (such as an ED). But I may have built the array structure for the repetitions wrong.

@senaranya
Copy link
Owner

Can you try using doNotSplitRepetition:

HL7::from($msgString)
  ->doNotSplitRepetition()
  ->createMessage()
  ->toString(true);

@andrezipf94
Copy link
Author

Hey, I've spent some time looking more deeply at the libs code, and I belive the issue here is having a simple array as the structure for rebuilding the message. It makes it very hard to distinguish betweeen repetitions and datatypes at the component/subcomponent level.

I've tried to work arround that during the weekend, had it working for some cases and failing for some as well. After that I've decided to try out using doNotSplitRepetition as true and that recompiled the message in an identical form.

So I belive the way to fix that would be creating data structures for repetitions, components and subcomponents. This way when rebuilding it would be easily distinguishible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants