4 ms·

I do not understand why can't we make a dashboard on Go with Streamlit or Dask. That will be a faster alternative. Why do you even need to spend 3 days when the

I do not understand why can't we make a dashboard on Go with Streamlit or Dask. That will be a faster alternative. Why do you even need to spend 3 days when the job can be done in 3 hours https://streamlit.io/ https://streamlit.io/

superzamp 6y ago
I thinks this article packs several engineering lessons and that this part is one of them: > we worked on a custom layout which is similar to a bedside monitor interface. It's great they went that route and did their best to stick to what doctors know by heart, instead of going creative.
AzzieElbab 6y 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 6y ago
  That 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 6y ago
    Interesting point about deployment. Though I haven't worked in orgs that would just let you drop an arbitrary binary on servers
- snapetom 6y ago
  I 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.
IanCal 6y ago
I love streamlit but don't think it's really the right architecture for this. It's not great for externally triggered or timed updates.

superzamp 6y ago

I thinks this article packs several engineering lessons and that this part is one of them: > we worked on a custom layout which is similar to a bedside monitor interface. It's great they went that route and did their best to stick to what doctors know by heart, instead of going creative.

AzzieElbab 6y 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 6y ago
That 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 6y ago
  Interesting point about deployment. Though I haven't worked in orgs that would just let you drop an arbitrary binary on servers
snapetom 6y ago
I 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.

IanCal 6y ago

I love streamlit but don't think it's really the right architecture for this. It's not great for externally triggered or timed updates.