Simulated Hospital
github.com
github.com
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||||5148^MARY QUINN|||||||||Y||||||||||||||||||||||||||||20180101000000|
Certain characters are ok (ASKII) but when a Mac gets a nice ' into the field, all hell breaks loose. Things like "lesion at 9 o'clock" then break the system, as does Mr O'Leary. The hours spent chasing down how some failure happened are countless. Pity those working with HL7.
And then Mr. O'Leary checks in.
Fuzz testing tools would be great, but I haven't seen many institutions that have functional 1:1 lower environments (i.e. including all system-system integrations working in test).
These NOTAMs were designed for human consumption and brevity, they date back to the 40s (debate about their ergonomics nonwithstanding).
Don't paste actual patient data.
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.
Its normal to secure the endpoints via network level security - ipsec etc. HL7v3 transformed into FHIR which is done over HTTPS instead.
you can often find these messages flying unencrypted over flex pager channels in the us
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.
https://www.hl7.org/fhir/us/core/Condition-condition-duodena...
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.
https://hl7-c-cda-examples.herokuapp.com/
Most new HL7 work has moved on to FHIR which is essentially "HL7 V4".
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.
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 relationships typically happen between longterm consistent partners both parties tend to evolve the format to suit localized needs and this business logic and the reasons for it are lost to time. It isn't that rare to find HL7 interfaces that have been in use for 20+ years that have become vital black boxes. HL7 2.x, still widely used, was originated in 1989.
In a lot of case modernization like FHIR is nothing more than taking the old garbage and putting it in a new fancier bag.
As whacky as HL7 may seem it is really nothing compared to its much bigger uglier older brother, X12 837/835, used for communication of billing information from performing entity to insurer.
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).
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.
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.
Turns out, for large known counterparties, there are indeed de facto processes that incorporate each party's eccentricities and are "known" on the floor (processors typically have long tenures in their jobs) but unknown above a certain level of management.
E.g. a large children's hospital that reliably spit out misformatted requests to the local payer, but which the payer papered over on their side by converting them to payable requests (naughty, but kept them from bouncing back and requiring resubmission)... and had been doing so for 10+ years.
In order to establish real interesting between two organizations you generally need to follow an Implementation Guide which constrains and profiles the baseline standard. HL7 publishes some IGs itself and others are available from organizations like the CDC and DirectTrust.
I haven't checked what my record is on our (Aussie) national health record yet [1]. I'll have a limited view for sure, but when I meet with my GP (general practitioner, MD, physician) to discuss my discharge summary on Monday, I might ask him to see what he has access to, and his complete it is.. I know I have been disappointed at what seemed to be quite devoid of info, despite all the controversy that ensued when it was introduced a few years back.
[1] https://www.digitalhealth.gov.au/initiatives-and-programs/my...
There shouldn't be any issue to view all the received documents on the screen during your visit though.
Hospitals, banks, government... just think of the tech these heavily regulated industries could have had, and how it could have improved our experience, if they actually had a strong incentive to improve. And it goes far beyond the tech stack.
In the long term, regulation often kills competition, which inevitably kills innovation.
The current prevalence of these venerable technologies may be in part due to regulation, but more often has to do with their success.
HL7v2 is just token delimited ascii. Not unlike the similarly primitive but ubiquitous csv. The fields within it are defined by standards documents and once you use it a little, you can read enough to get the gist of most messages. As you might guess, modules in your language of choice are used to parse and compose HL7v2 so its detail isn’t that important.
[Edit: looks like the project has written Synthea out in favor of an integrated data generator]
Something I’d like to point out about Google Hospital is that under the hood it uses MITRE’s Synthea to generate synthetic patient data.
https://www.healthcareittoday.com/2017/09/13/open-source-too...
It's also useful for expecting similar in future industries. Ultimately, I think it doesn't even matter if the reason is regulatory complexity, industry rigidity, or technical debt.
The question is how do we dig out of such holes.
If we were starting from scratch, it's almost certain we'd have better software, better firms, norms, standards and such within a short period of time.
How do we do that when not starting from scratch?
So does non-regulation, often. A lot of this carp is "emergent" bureaucracy between insurers, other insurers, hospitals, etc. Regulation and monopolies often support eachother, merging into a nasty complex such as this... it's impossible to tell where one begins and the other ends.
I see financialization as a bigger factor currently than regulation. It's not a coincidence that "medical billing" is the epicentre.
I just don't buy the idea that less regulation means less mindless complexity.
The best if the early neoliberal/austrian economists was IMO Schumpater. Creative destruction. Complexes evolve into cludges over time.
Creative destruction is often presented as a feature of free markets... But that's theoretical. Irl, we see firms and complexes become effectively immortal... Immune to market forces and moated from competition. These tend to be the massively inefficient ones.
Regulated or not, insurance consortiums are much more like a government department than they are like a local restaurant. There are a lot more "private" regulators in the mix than public ones.
Can simulated hospital simulate efforts by staff to quickly add into many charts a medication Rx - by taking one patient note and copying 1 note, then pasting that into several?
Does it simulate staff forgetting the dosage was not edited after pasting into all those charts ?
Or staff not logging out of their userID, to avoid the need to log in every time someone needs to add a note/document into a chart? So that , in fact, the doc added by Dr Smith, was actually done by his assistant Tully?
Life is complicated. People use systems in wild and unexpected ways.
Real solutions require real data.
What CPOE system involves notes? None of the handful I've used in the US.
No modern EMR here involves any copy pasting for orders.
While I don't think it's a bad career move, and that may have been part of their consideration, I find the trivialization of the work put in by someone here to open source something they thought would be a positive contribution hurtful.
More broadly, all big 3 cloud providers (Azure, AWS, and Google) have offerings for FHIR data storage and API access, as well as common NLP based healthcare data analysis workflows. Many of these seem relatively new, or as if they have had a lot of recent attention focused on them. I'm definitely interested in how/why these companies (as well as some other VC funded ones, like Medplum), are entering this space with products that are not directly sellable, but are rather things that other tools would have to build upon. It seems like AWS works directly with end-customers to use their APIs to build products, but I'm not sure what Azure and Google are doing.
This one's probably too complex for my use case, but I thought the concept looked very neat and wanted to share.
Fairly sure they built this to test their HL7v2 store[2]. Also presuming it hasn't been very active given that Google surprisingly shut down their Healthcare division (and probably restarted it somewhere)[3].
[1] https://github.com/google/simhospital/blob/master/docs/dashb... [2] https://cloud.google.com/healthcare-api/docs/concepts/hl7v2#... [3] https://www.businessinsider.com/google-health-shutting-down-...
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.
It might not be great but I think its better then most offerings.
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.
But I already have thousands of independent VPN setups and API integrations, so the cost is harder to justify at scale.
It's okay Google, we know you'd abandon it a few months anyway.