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

81–90 of 108 posts

Re: Simulated Hospital

#81

Post by devilbunny »

ArtWomb wrote: post #62
duffpkg wrote: post #33

I am frequently asked about why systems in institutional healthcare are so hard to modernize, this has come up a lot related to pricing transparency. While HL7 is in theory a standard, in practice it is a semi-parseable "email" between two parties that know each other. Widely used systems like EPIC have bugs and quirks that have existed so long that the bugs themselves have become their own standard. Because HL7 rela…

Bizarro-world that doctors actually defend EPIC! They all complain about the ASP.NET 1.0 UI. It's just the convenience of viewing all patients from all hospitals in one virtual "chart" ;)

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 anesthetic record - not even the surgeon who performed the surgery (!); and that certain contexts do not allow a nurse who is running the schedule in one area to edit their case status board, which is a view of all cases in that area that allows them to see what's been done, what's left to be done, etc., - but if they switch context, they can change things, make their own boards, and then change back to the "proper" one and use the ones they've made).

Re: Simulated Hospital

#82

Post by Spooky23 »

ArtWomb wrote: post #62
duffpkg wrote: post #33

I am frequently asked about why systems in institutional healthcare are so hard to modernize, this has come up a lot related to pricing transparency. While HL7 is in theory a standard, in practice it is a semi-parseable "email" between two parties that know each other. Widely used systems like EPIC have bugs and quirks that have existed so long that the bugs themselves have become their own standard. Because HL7 rela…

Bizarro-world that doctors actually defend EPIC! They all complain about the ASP.NET 1.0 UI. It's just the convenience of viewing all patients from all hospitals in one virtual "chart" ;)

A loved one was inpatient for a few weeks at a local epic hospital/medical system and then a more specialized/academic hospital with a federated collection of cerner systems.

It’s a night and day difference. The GUI may be ugly, but the Epic implementations tend to be soup to nuts. Everyone, from the transporters moving patients to the doctors to the primary care providers to the patients know what’s going on in real time.

At the teaching hospital, they had awesome medical capability, but nobody had a clue what was going on. That leads to risks if you need care from multiple specialties.

I’m sure that it’s garbage enterprise software of course.

Re: Simulated Hospital

#83

Post by ThaDood »

cmiles74 wrote: post #80
djfobbz wrote: post #49

Earlier quoted context omitted.

This message object seems to be missing the HIPAA^ENCRYPTED field (pun intended)...I am assuming the encryption is implemented above this layer? Is there a standard for HL7v2 encryption?

Typically these messages are not encrypted. This is a late 80's spec based on a 70's era EDI spec. IMHO, when these messages are transmitted outside the hospital typically a VPN used. There is a spec for posting these messages to an web service over HTTPS but I haven't seen it in use.

Usually encrypted via a TLS connection right into an HL7 channel/listener. Or the entire connection is encrypted via a VPN connection between healthcare systems.

Re: Simulated Hospital

#84

Post by cmiles74 »

duffpkg wrote: post #33

I am frequently asked about why systems in institutional healthcare are so hard to modernize, this has come up a lot related to pricing transparency. While HL7 is in theory a standard, in practice it is a semi-parseable "email" between two parties that know each other. Widely used systems like EPIC have bugs and quirks that have existed so long that the bugs themselves have become their own standard. Because HL7 rela…

Agreed. While FHIR is clearly more modern, in my experience it's the same data I'm seeing provided over HL7v2. It's easier to parse JSON and it's nice having the data labeled but values are still inconsistent.

Re: Simulated Hospital

#85

Post by cmiles74 »

devilbunny wrote: post #81
ArtWomb wrote: post #62

Earlier quoted context omitted.

Bizarro-world that doctors actually defend EPIC! They all complain about the ASP.NET 1.0 UI. It's just the convenience of viewing all patients from all hospitals in one virtual "chart" ;)

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.

Re: Simulated Hospital

#86

Post by ThaDood »

owenmarshall wrote: post #71
ensemblehq wrote: post #61

Are there any decent parsers in Python/Java/Ruby that someone can recommend?

https://hapifhir.io/ for open source. Mirth is the commercial offering many people use - it is nice because it handles the MLLP protocol, gives you a mapping system, lets you transform and call your own endpoints. That’s also why it sucks: it’s a big heavy system.

Well there is the FOSS Mirth option and the NextGen Mirth Option which is the "premium" corporate-backed version. Mirth is like the glue for healthcare in the US. Most of the companies I've worked with use it. Whats another options? Redox? HAPI? Qvera?

It might not be great but I think its better then most offerings.

Re: Simulated Hospital

#88

Post by cmiles74 »

ThaDood wrote: post #86
owenmarshall wrote: post #71

Earlier quoted context omitted.

https://hapifhir.io/ for open source. Mirth is the commercial offering many people use - it is nice because it handles the MLLP protocol, gives you a mapping system, lets you transform and call your own endpoints. That’s also why it sucks: it’s a big heavy system.

Well there is the FOSS Mirth option and the NextGen Mirth Option which is the "premium" corporate-backed version. Mirth is like the glue for healthcare in the US. Most of the companies I've worked with use it. Whats another options? Redox? HAPI? Qvera? It might not be great but I think its better then most offerings.

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 mentioned, there is a free Mirth offering and parsing HL7v2 is not that bad.

Re: Simulated Hospital

#89

Post by HillRat »

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.
Post reply on HN