Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simulated Hospital

github.com

Post reply on HN
Print view View original

101–108 of 108 posts

Re: Simulated Hospital

#101

Post by riceart »

TeMPOraL wrote: post #36
warent wrote: post #24

Earlier quoted context omitted.

no shot anyone actually types this out, right? surely this must be generated by machines for machine ingestion.

They probably do, and if NOTAMs are any indication, it's probably also read by people too.

Not comparable. HL7 is a machine interchange format - virtually no docs or healthcare personnel except those involved in informatics (and then generally only superficially) are familiar with HL7.

These NOTAMs were designed for human consumption and brevity, they date back to the 40s (debate about their ergonomics nonwithstanding).

Re: Simulated Hospital

#102

Post by robertlagrant »

nradov wrote: post #93
robertlagrant wrote: post #76

Earlier quoted context omitted.

It's normal to not encrypt it, in my experience.

It's really not normal to not encrypt HL7 V2 messages. Every interface that I've seen uses a VPN.

I'm in the UK in the NHS. Perhaps that's the difference. They just do network lockdowns inside the hospital.

Re: Simulated Hospital

#103

Post by ThaDood »

owenmarshall wrote: post #92
cmiles74 wrote: post #88

Earlier quoted context omitted.

Redox has already priced themselves so high, it's unclear what value they are providing. A big reason to go with Redox is that you don't have to setup a VPN with the target hospital, have staff monitoring the VPN to ensure it's up and you don't have to parse your own HL7v2 messages. IMHO Redox is now so expensive that you have to wonder if you might be better off doing all of this work yourself. As others have mentio…

I think it really depends on your scale. If I'm a small healthtech startup and I can interchange with people hooked up to the candidate QHINs like eHealth and CommonWell I just saved thousands of independent VPN setups and HL7 mappings. But I already have thousands of independent VPN setups and API integrations, so the cost is harder to justify at scale.

That is exactly how my previous employer (HIE) operated. Mirth was fairly low-cost and if we wanted. We could bootstrap our own Mirth Servers. But managing that many VPNs was a giant pain.

Re: Simulated Hospital

#104

Post by specialist »

HillRat wrote: post #89
ape4 wrote: post #22

When they say "Most EHRs use a message format called HL7v2, which is ugly and tedious to type." they aren't kidding, here's an example of it: MSH|^~\&|FROM_APP|FROM_FACILITY|TO_APP|TO_FACILITY|20180101000000||ADT^A01|20180101000000|P|2.5| EVN|A01|20110613083617| PID|1|843125^^^^MRN|21004053^^^^MRN~2269030303^^^^ORGNMBR||SULLY^BRIAN||19611209|M|||123 MAIN ST^^CITY^STATE^12345| PV1||I|H73 RM1^1^^HIGHWAY 01 CLINIC||||51…

Don't forget the most ridiculous part of EDI-style protocols (X12, HL7, etc.), which is that they don't have an explicit looping construct; you have to look at each implementation spec and your trading partner's specific companion guide and determine where repeated or looped sequences area through context. Makes for some exciting issues in implementing parsers.

Agreed.

On the positive side, being domain specific and well known, Hl7v2 "interface" specs are more simple and predictable than other IDLs I've used. (Just vibes. I haven't done a formal comparison.)

We had a stock human-readable "interface" template to use. It's basically literate programming. Paragraphs of descriptive text and well-formed tables.

I wrote a simple parser which turned those well-formed tables into actual code. Our HL7 tools made it trivial to subclass generated classes whenever a special case (difficult to describe in the spec's tables) had to be hard-coded.

Our HL7 tool stack allowed our "business analysts" (domain experts talking with customers) to do most of the implementation themselves, with speedy deploys, low cost of change, and super easy to verify. For instance, our team could make changes and deploy and verify while on the phone with customers / partners.

What could be easier?

Our customers loved us.

So of course the mega-corp which acquired our startup had to strangle our effort in the crib, dumping our corpse in a land fill. Mostly out of spite.

Re: Simulated Hospital

#105

Post by devilbunny »

cmiles74 wrote: post #85
devilbunny wrote: post #81

Earlier quoted context omitted.

As a doctor, Epic is mediocre software that just happens to be less mediocre than most of the alternatives. My biggest problem with Epic is that things are so heavily silo'ed by your job description (RN, MD, PharmD, etc.) and job context (without getting too deep into the weeds, it is a fact that the Epic implementation at my hospital does not allow anyone other than anesthesia personnel to see an intraoperative anes…

It's more than just the job description, I believe many EHR vendors require people who use particular modules to be "certified" for that module. Obviously this leads to a silo effect where the information is available but one clinician may need to request another clinician to actually read the data to them.

Which is beyond moronic.

If you need the anesthesiologist on call to come back to the hospital just so the surgeon can see what drugs were given during the case and what the vital signs looked like, your EMR is less useful than paper.

Re: Simulated Hospital

#106

Post by owenmarshall »

nradov wrote: post #96
owenmarshall wrote: post #73

Earlier quoted context omitted.

R4 is where things get a bit kinder and gentler. https://www.hl7.org/fhir/us/core/Condition-condition-duodena...

I think you're kind of mixing up version or release numbers there. HL7 has several major standards: V2 Messaging, V3 (including CDA), and FHIR. And each of those has gone through multiple releases. FHIR was on R4 for a couple years and R5 was recently published.

Yeah, I’m doing that thing where I speak sloppily. HL7 is the standards organization, so talking about “HL7 messages” is like talking about “ISO messages”. It’s a misnomer.

But as someone at the sharp end of the stick wrt integrations? If I hear someone talk to me about HL7 I’m thinking HL7v2, and if someone says FHIR I’m thinking US Core v2 + FHIR R4. That just seems to be lingua franca.

Re: Simulated Hospital

#107

Post by vntok »

duckmysick wrote: post #39
vntok wrote: post #37

Earlier quoted context omitted.

You can ask GPT to expand it for you without any context and it will fill in the headers and explain each field.

Good learning tool if you use it on generated data. Don't paste actual patient data.

Why not? Can you articulate what could go wrong?

Re: Simulated Hospital

#108

Post by duckmysick »

vntok wrote: post #107
duckmysick wrote: post #39

Earlier quoted context omitted.

Good learning tool if you use it on generated data. Don't paste actual patient data.

Why not? Can you articulate what could go wrong?

You're sharing someone's sensitive data without permission. On top of that, patient data has additional protections in many countries. You can get into legal troubles because of that.

Major providers like Azure or AWS have programs in place to handle sensitive patient data. I'm not sure if OpenAI has one too. Either way, you would have to enter into a special agreement to do so.

Bonus point: ask ChatGPT if it's ok to paste private patient data there.

Post reply on HN