2 ms·
I do not usually write posts like this, but I would never write an hl7 parser when things like hapi https://hapifhir.github.io/hapi-hl7v2/ https://hapifhir.gith
by AzzieElbab 7y ago
I do not usually write posts like this, but I would never write an hl7 parser when things like hapi https://hapifhir.github.io/hapi-hl7v2/ https://hapifhir.github.io/hapi-hl7v2/ exist. It is not just a parser, tones of fields in hl7 messages have not obvious meanings and implications
- 3fe9a03ccd14ca5 7y agoThat would have taken care of the message parsing, but the team would still need to do the concurrency work, get it debugged, and working. Also Java is not nearly as easy to deploy on-prem as Go.
- AzzieElbab 7y agoInteresting point about deployment. Though I haven't worked in orgs that would just let you drop an arbitrary binary on servers
- snapetom 7y agoI used https://github.com/deoxxa/hl7 https://github.com/deoxxa/hl7 at my last job to grab HL7 messages out of central processing system. Regardless of the parser, I agree. Writing your own is dangerous. HL7 is deceptively complex. It leaves a lot of room for vendors and your hospital to customize. If you write your own, you can very easily end up with a system that is boxed in to your hospital's own, or even your department's own, implementation.