Building a patient monitoring system with Go and Vue in 3 days

https://kasvith.me/posts/how-we-created-a-realtime-patient-monitoring-system-with-go-and-vue/

by astdb • 6 years ago

436 133 6 years ago

shadycuz• 6 years ago

I really like this idea of monitoring people like we monitor servers.

I wonder what useful information you could extract from this. Like a very slight downward trend in blood pressure over a day. Could this be used to detect something like a slight internal bleed after a surgery?

JshWright• 6 years ago

The body is very good at compensating for stuff like that. A falling blood pressure is a very late signal. The body has several tools at its disposal to maintain pressure (constricting the blood vessels, slowing the output of the kidneys, increasing the heartrate, etc). Two of those (urine output and heartrate) are already trended throughout the day for hospitalized patients.

LanceH• 6 years ago

You hear about athletes having their blood monitored to balance recovery, but it seems every instance of this turned out to be about doping.

rasmus1610• 6 years ago

Our hospital actually records the patient monitor data of ICU patients and analyzes them for scientific purposes. And I agree, there is a tremendous amount of information in it, although bleeding is detected otherwise faster (blood gas analysis e.g.)

stephenboyd2• 6 years ago

Patient vital sign monitoring has been a regular practice much longer than server monitoring.

fhsm2• 6 years ago

Not just a long standing part of medicine as you said but also one of the best trodden topics in informatics:

- https://link.springer.com/chapter/10.1007/978-3-319-43742-2_...

- https://www.nature.com/articles/sdata201635

emilburzo• 6 years ago

Are there any similar monitoring (hardware) devices that you can buy just for yourself? (aka you don't have to be a hospital or talk to a sales representative to be able to buy one)

I don't care that much if it has a display, just being able to access the information similarly to what's described in the article would be enough.

xvf22• 6 years ago

This one covers pulse and blood oxygen: https://www.gadgetvictims.com/2019/02/contec-cms50dplus.html

kisamoto• 6 years ago

Withings (was bought by Nokia but now Withings again) have a set of off-the-shelf tools you can buy. Scales, thermometer, blood pressure monitor, sleep tracker.

didntknowyou• 6 years ago

great work

saintfiends• 6 years ago

Interesting idea. I'm not sure how scalable this would be given the fragile nature of the tools.

I want to believe with enough indications of the monitoring itself (Is the screen being refreshed? Is network connected ? When was it last checked?) that this is a viable option and that would unlock a lot of possibilities.

But I can't shake off the feeling of uneasiness (What if it's not working and we don't know it's not working)

PS: I'm not bashing on what was done, just the general idea.

vijaybritto3• 6 years ago

It's not written with scalability in mind. It simply needs to get the job done. Other programmer requirements can wait!

min2bro• 6 years ago

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/

superzamp• 6 years 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.

AzzieElbab2• 6 years 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/ exist. It is not just a parser, tones of fields in hl7 messages have not obvious meanings and implications

3fe9a03ccd14ca52• 6 years 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.

snapetom• 6 years ago

I used 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• 6 years 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.

HorizonXP• 6 years ago

This is really fantastic to see. I've been involved in contracts using HL7 protocol, and it's always a big and expensive beast with proprietary connectors. The fact that you figured it out so quickly is awesome.

joshgel• 6 years ago

Also see: https://github.com/smarterdx/covid-19

Similar concept with different data that we are deploying in US hospitals. Using React and Hasura.

geeklord2• 6 years ago

What was the main factor for choosing Go instead of C or Java?

Kaze404• 6 years ago

What makes C or Java such better options that they had to have explicit reasons to use Go?

KaoruAoiShiho• 6 years ago

It's probably because they existed when he first started learning programming.

IshKebab• 6 years ago

There's a whole section in the article about that. C would be a pretty obviously terrible choice so I'm not sure why you would consider that.

Java would be ok but Go is much simpler to get started with and to deploy. In general it is more lightweight and easier to use (unless you need generics, though Java doesn't really do those right either).

vijaybritto3• 6 years ago

instant feedback is possible in Go as it compiles super fast. Also its much simpler to write cause its a small language and the concurrency primitives are so simple to understand and use. It has its problems but its a great choice here.

The most valid reason for using a language is simply because the team is comfortable with it.

3fe9a03ccd14ca52• 6 years ago

Considering they got it working so quickly, I think they made the right choice.

capableweb4• 6 years ago

instant feedback is possible in Go as it compiles super fast

Heh, you should try a language that comes with a repl and allows you to evaluate code directly from your editor in any context and get the results back. Then you'll have experienced "instant feedback". Until then, I can agree that Golang compiles faster than other languages, but it's nowhere near instant. In some other languages, you don't really care how fast it compiles as you only do it for deployments anyways (like Clojure).

geeklord2• 6 years ago

I see. Being comfortable is the one of the most important factors.

jftuga• 6 years ago

One nice thing about Go and C vs Java, is that a program can be (statically) compiled into a single, stand-alone executable that have no external dependencies.

esprehn• 6 years ago

Java supports packaging as well: https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...

kisanme• 6 years ago

This is a great implementation and you have done it real quickly. Great stuff!

naasking8• 6 years ago

It's unfortunate "real-time" is getting so heavily overloaded. It used to mean "guaranteed bounded latency".

"Real-time" is now being used for streaming APIs to mean "small latency on average, but no guarantees".

egeozcan• 6 years ago

Is there a more correct marketing term for "small latency on average, but no guarantees"?

junke• 6 years ago

soft real-time

https://en.wikipedia.org/wiki/Real-time_computing#Criteria_f...

mrits• 6 years ago

I agree. In my experience it now means anything that could be shown during a sales demo without needing intentional pauses.

PudgePacket• 6 years ago

I assumed they used the words "real time" in a patient monitoring sense to mean Doctors being able to monitor patient data without having to go between rooms themselves or wait for reports.

Kind of how you'd say you have a dashboard for your business to see metrics in real time (as opposed to some kind of daily report).

I think that usage of real time is very common outside of a pure engineering sense, so you're being a bit of a stickler by being annoyed at this specific instance ;)

sergiotapia• 6 years ago

When I learned about this stuff years ago with SignalR this was called soft real-time.

My Phoenix channels, your rails action cable, your web sockets: soft real-time.

Real-time was reserved for true real time guaranteed delivery times.

lobotryas• 6 years ago

I don’t see why you had to call him out. “REAL TIME” is also an engineering term with a strict definition. If You paid me for a real time stock ticker and you later found out it had a delay of a second or two you would want a refund.

naasking8• 6 years ago

Kind of how you'd say you have a dashboard for your business to see metrics in real time (as opposed to some kind of daily report).

I think calling it a "streaming" or "live streaming" interface is a better descriptor than "real-time".

I think that usage of real time is very common outside of a pure engineering sense

Maybe, but we're talking about the software engineering world here aren't we? I think we should seek to be precise with our terminology and try to avoid unnecessary ambiguity.

sb82445• 6 years ago

I agree that this is soft real-time but think that the usage is pretty clear in the web world. I'm not sure it's a bad thing that is taken on a different meaning in a different context.

I view real-time as "the clients reflect the true state of the world without taking action." So if something changed the state of the world, all clients paying attention to that should also be updated.

naasking8• 6 years ago

I view real-time as "the clients reflect the true state of the world without taking action." So if something changed the state of the world, all clients paying attention to that should also be updated.

That's a perfect description of "live streaming".

erikpukinskis• 6 years ago

I’ve been working professionally in the web for decades and I can’t remember anyone ever using the term “real-time”. I hear “live” a lot. Live updates.

pgwhalen• 6 years ago

This comment always shows up and I find it strange. Surely engineers can realize that while "real-time computing" has a strict definition, the phrase "real-time" has much broader meaning and it bumps up against the software world very often.

naasking8• 6 years ago

Sure, but this is a engineered solution we're talking about. Don't you think it should use the engineering terminology?

I'm not calling out this person specifically, I'm just hopeful that we can use more precise terms instead of overloading existing ones. I think "streaming API" or "live streaming" is a better fit for these purposes.

corporateslave5• 6 years ago

It’s more the case that your usage of the term is outdated, but you still complain that the world doesn’t conform to your understanding

bluebknight• 6 years ago

The real problem in speech is not precise language. The problem is clear language. The desire is to have the idea clearly communicated to the other person. It is only necessary to be precise when there is some doubt as to the meaning of a phrase, and then the precision should be put in the place where the doubt exists. It is really quite impossible to say anything with absolute precision, unless that thing is so abstracted from the real world as to not represent any real thing. Richard Feynman

SergeAx• 6 years ago

Good job!

I personally would take Grafana with Prometheus (as it has great Go library) and reduce the whole project to some kind of HL7 wrapper.

ggregoire• 6 years ago

My thoughts too, but I'd not be surprised if they didn't know these tools existed. From my experience, Prometheus and Grafana (and monitoring practices and tools in general) are absolutely unknown to most developers.

mfashby2• 6 years ago

The developer here did a good job putting this together so quickly, and it's hopefully beneficial to the hospital staff and the patients themselves. I hope they keep working to improve it, and consider open sourcing it.

The circumstances are pretty exceptional, two things shocked me a bit: 1. The manufacturer already produces remote monitoring software for the device but its _too expensive_ 2. Software like this is usually classed as a medical device, which comes with regulations (e.g. https://www.gov.uk/government/publications/medical-devices-s... in the UK)

et2o• 6 years ago

Software that merely displays data is not typically a medical device, as long as it doesn’t transform or otherwise alter the data.

fhsm2• 6 years ago

US only knowledge but in the US...

This is (possibly depending on use) a biomedical device. These are regulated such that we pull separate cat5/6 and put up chain link in network closets. The Cisco switch in one side of that fence just vanilla corporate IT with email, EHR, Netflix etc; the same switch on the other side and all the stuff connected to it - from the bedside monitor out through the central alarm station - is a medical device.

That isolation is the presumption referenced in the recent GE vulnerability [0] and the challenges of getting bio med chocolate in the corporate (ehr) peanut butter presents significant challenges [1].

[0] https://www.fda.gov/medical-devices/safety-communications/cy...

[1] https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfStandar...

sergioisidoro• 6 years ago

I just came here to say: Major credit to standards like HL7 (and other projects for ontologies like LOINC and SNOMED)

HL7 and FHIR are a major step in interoperability for health, and they should not be taken for granted.

I've worked with integration projects with EHR (Electronic health record) Systems, and a lot of hospitals still have proprietary formats for exchanging data with limited documentation.

If you ever work on any health related system, consider starting from those standards!

prostheticvamp2• 6 years ago

As someone who was involved in the evolution of HL7 from the policy/medical side, I can tell you:

EMR systems lock us (healthcare systems) into proprietary formats to make migration to new clients difficult; likewise, we don’t (didn’t) push for interoperability because exporting data to other healthcare systems cost us more than it benefited us (we didn’t fight it, we just weren’t gonna spend our money to make it happen).

HL7 and other interoperability tech only emerged because CMS reps made their way to -a lot- of conferences and, with varying levels of bluntness, said “find a way to improve interoperability on your own, or you’ll see it show up in federal regs 12 months from now.”

This is a change that came from active regulators doing their jobs correctly, in spite of the active efforts of the tech industry and the indifference of the hospital industry.

So, I rarely say this but, thank you CMS.

WrtCdEvrydy• 6 years ago

only emerged because CMS reps made their way to -a lot- of conferences and, with varying levels of bluntness

I mean, to be honest, it makes sense... locked platforms are just death.. especially if you can't get your shit off it when it shuts down.

fludlight• 6 years ago

What's CMS? Centers for Medicare and Medicaid Services?

https://www.cms.gov/

atmosx• 6 years ago

Amazing! Go regulators, thanks for sharing, stories like these give me hope :-)

kalleth3• 6 years ago

I apologise for this comment, you've done some great coding, but this scares the shit out of me.

There's a reason medical certifications are so hard to get, and medical software is so expensive.

You're storing patient information in postgres. What certifications do you have to assert that the patient data is stored securely, in line with your government guidelines on patient/medical data? There's a damn good reason this is the "holy grail" of information security certifications.

You've got critical alerting built into the browser window using JavaScript.

This "alerting" is the kind of critical thing that sometimes needs *immediate" intervention, or someone could die. What happens if your browser experiences a JavaScript error blocking processing? And your alerts don't fire?

What happens if they fire too often and you get "alert fatigue" because they're not tuned correctly or in line with the other alerts available at the bedside/nursing station?

How much testing have you done to correctly assert that you're interpreting the HL7 or other specs correctly? And aren't misinterpreting data for some conditions or types of individual?

The "throw things together quickly" startup mentality might (I stress might!) Be okay where it's the difference between nothing at all and something that can save lives, in a country like Sri Lanka, during a global pandemic, fine.

But afterwards, this is so much junk without serious thought and time put into certifying it.

Medical, Aerospace -- really, any safety critical industry where your code working or not could mean someone is seriously injured or dies as a result -- is an industry that needs disruption, but that disruption should happen slowly, carefully, and safely.

harikb2• 6 years ago

We created this software on a request from healthcare staff

If this is some small town hospital in Srilanka, the choice is between an unaffordable certified solution and not having any monitoring. If Medical software didn’t bleed them dry, they wouldn’t go this route.

disruption should happen slowly, carefully, and safely

Disruption always happens this way - same way Uber broke existing laws. Yes, few people will die. But this isn’t surprising when the alternative is even worse.

kalleth3• 6 years ago

the choice is between an unaffordable certified solution and not having any monitoring.

No, this isn't _necessarily_ the choice. Without a "false sense of security" that an imperfect monitoring system might instil, you have nurses and doctors actually doing rounds and checking their patients.

Disruption always happens this way - same way Uber broke existing laws. Yes, few people will die. But this isn’t new when the alternative is even worse.

This is an absolutely horrible viewpoint to have. People dying because of "disruption" so a few companies can make a few more dollars is _never_ acceptable.

PaulRobinson• 6 years ago

You’re right. There is no way this would be deployed in a UK hospital as it stands. It might be some of the most dangerous ideas encapsulated in code I’ve ever seen. I disagree with standards like DCB0129, but they’re there for a reason. This would not pass.

p_l2• 6 years ago

UK also has a lot more resources to work, even with conservative government trying to break NHS financing for the last decade.

pstuart3• 6 years ago

The perfect is the enemy of the good.

This could likely be "good enough" for those that have no other options if open sourced.

prostheticvamp2• 6 years ago

That’s one of the dumbest platitudes ever deployed to deflect criticism, and I wish people would use it correctly.

“This thing has absolutely no evidence of reliability or safety in a critical environment” is not criticizing it for being less-than-perfect. It’s criticizing it for being possibly inferior to the status quo.

Here’s one simple example:

Staff gowning up for routine rounds are much more careful, and safe, than staff rushing into an emergency code. If this thing throws up even the occasional false alarm, its cost to staff (in exposure) could easily outweigh, massively, and reduced rounding requirements.

That’s not “oh, well that’s not perfect.” That’s “oh, that might be worse, masquerading as better.”

“Perfect is the enemy of the good” is a wildly irrelevant comment.

mfashby2• 6 years ago

This is the comment that was in my thoughts and I failed to write it.

I really hope they 1. Open source it 2. continue to work on this throughout the crisis and get it to a state where its actually suitable for critical care, and then 3. Work on achieving the relevant certification.

It sounds (just guessing) like the device vendor sells their own software separately, and is unwilling to budge on price during this time, forcing an already stretched hospital to look for new solutions.

olieidel• 6 years ago

I had the same thought. But I think it's more complex than that.

Always consider the alternative. This could be a hospital in a remote part of a third-world country. Maybe they're understaffed. How are they currently handling the task of gathering information from monitoring devices and reacting to alarms?

Maybe, their nursing staff has to run from bed to bed to check patient's vital signs and device alarms. Emergencies would frequently be missed because they are understaffed and checking is irregular. Now, you could introduce software which provides centralized monitoring. If it's introduced on top of the existing activities (i.e., running from bed to bed), it leads to a net benefit - you catch emergencies earlier and consequences of malfunctions are less severe. But if it's introduced to replace the existing activities, it may lead to patient harm.

Sure, it's self-coded, browser-based and buggy - but you always need to weigh risks with benefits, and those depend on usage context.

Of course, in most western countries, this would be completely illegal. But these are also the countries in which medical software looks like it's from the 90s, with catastrophic usability and missing features.

We need to ask ourselves: Right now, we heavily prioritize patient safety over innovation - but have we got that balance right? What are patients missing out on if we could just bring a few more of the latest advances in technology to their bedside?

You know, not machine learning, the blockchain or the internet of things. Rather things like browser-based applications which "just work" and have great usability.

Note: I'm a physician, software developer and consultant for medical software certification :)

im_down_w_otp5• 6 years ago

Sure, but there are plenty of technologies that are applicable to safety-critical systems or are safety-critical adjacent which are freely available. There are MCUs, application boards, RTOSs, programming languages, compiler toolchains, network stacks, parsers, etc. available which are the same-a or close-to those which would be commonly sourced and deployed in a safety-critical context.

So, why not use those to build the "something is better than nothing" solution?

DanBC• 6 years ago

Maybe, their nursing staff has to run from bed to bed to check patient's vital signs and device alarms.

It feels to me like the management has misunderstood the cost of the software vs not having the software. It feels like they're saying "this software is expensive, and doing nothing is free" when they should be saying "having all these healthcare professionals spending time putting on and taking off PPE the check patients is costing us this much per year".

As you probably know, an ICU will go through 30 sets of PPE per patient per day. That's a lot of time putting stuff on and taking it off.

parhamn• 6 years ago

Anyone have any recs for a pulse oximeter you can hack on? I’ve been looking for one that wouldn’t be too difficult to connect to. I could barely find any of the old ones let a lone something that looks like it can be borderline portable.

2StepsOutOfLine• 6 years ago

Channels allow mutex free communication between goroutines without a pain.

Channels are not lock free: https://github.com/golang/go/issues/8899

vchak1• 6 years ago

IMHO, this would be a perfect application to build using Elixir and Phoenix LiveView. I think it would provide really robust realtime capabilities, and fits well with things like binary pattern matching that Elixir and Erlang handle well.

innocentoldguy• 6 years ago

I personally wouldn't use web technologies to write critical medical software, but if I did it would be in Elixir or Erlang for the optimized garbage collection and supervision trees.

I agree with you on LiveView as well. I believe it would prove to be more reliable than client-side JavaScript.

mister_hn• 6 years ago

Also something like a C++ core connected to sensors and InfluxDB+Grafana to display the data would be good.

stephenboyd2• 6 years ago

Would a close-up cctv display of the bedside monitor have worked for this kind of remote monitoring?

I write enterprise medical software for a living and if a hospital had told me they were desperate for a solution in 3 days, I would exhaust other options before writing new critical software.

exdsq• 6 years ago

That's not a bad idea either! Webcam pointing at a bedside monitor and a clock (to check it's working correctly, not frozen, etc).

OJFord• 6 years ago

That'd be a lot more data to push, and not be able to record specific data or alert on anything. I don't write enterprise medical software for a living, I just think hundreds (? thousands?) of video streams isn't necessarily more reliable or elegant in its simplicity than rushed out new software. There's always a (many) trade-off.

johannes_ne• 6 years ago

If anyone need to view or record data from multiple medical devices, e.g. for research purposes, Vital Recorder is a quite well documented solution. It is free of cost, but unfortunately it is not open source.

They also have a solution for an ICU like monitoring system with several beds, but I have not used this functionality.

https://vitaldb.net/vital-recorder/

alexbanks7• 6 years ago

It's as though no one commenting negatively actually read this article.

We created this software on a request from healthcare staffs. It is not a commercial application. Even with this system, we strongly suggest doctors to visit their patients, take real measurements. As this software was developed fast due to prevailing pandemic situation, we released it with the most urgent feature monitoring. We tested this for long run, with multiple devices as well. So far it worked out well. It does not indicate this is perfect, we are working on improvements and fixing bugs until its very stable. Thus we have adviced doctors to use this with CAUTION

It's almost as if the options were either "Do nothing" or "Do something", and they chose to "Do something." This does not sound at all like someone just decided to build their own version of a software they already had access to. It sounds very much like they could either make this software or try to get along without it.

kalleth3• 6 years ago

I did read the article.

I understand the desire to "do something", but the certification and testing process for something like this is how you find out if this actually improves patient outcomes or not. Sometimes "doing nothing" in a certain area gives a better outcome.

I'm glad they're advising doctors to use caution.

I have some architectural concerns about how it's built (a browser's javascript engine is not reliable enough to be used as a safety-critical alerting engine!), but I can see how it's attractive.

alexbanks7• 6 years ago

It feels like you've lost the forest for the trees.

im_down_w_otp5• 6 years ago

I expect there are a lot of viable and useful shades of grey in between official standards certified commercial products and from-scratch one-off Go/JavaScript.

Even if they're going to roll their own rapid uncertified solution, they could have still done so with more reliable and proven technology than what they appear to have chosen to assemble this system.

Many components for making safety-critical systems are commonly available in non-certified variants. These could be used to assemble a viable system, but would of course lack the process, practice, and evidence for certification that would normally be required. But, at least the technology choices would have, at a minimum, "proven in use" benefits if one is going to otherwise punt on the procedure & practice rigor that is typically applied.

Given that most of the components to build a safety-critical system are commonly available, or their non-qualified kin are, it doesn't make much sense to me why if you were tasked with putting this together quickly and cheaply, but were still taking serious the safety-critical nature of it, why you would cobble it together with the stack chosen here.

Even if the choice is "Do something" or "Do nothing", there's more than one way to "Do something", and this seems like a particularly odd way to have gone about it all things considered.

alexbanks7• 6 years ago

Many components for making safety-critical systems are commonly available in non-certified variants.

Can you elaborate on this?

robocat• 6 years ago

I think people just don’t understand the budget difference between countries - Sri Lanka has two orders of magnitude less spending on healthcare per person than the US (Sri Lanka: 160 per person, US: 10200 per person, 2017 [1]).

2 orders of magnitude less means there is a lot of making do with what you have.

[1] https://data.worldbank.org/indicator/SH.XPD.CHEX.PC.CD

alexbanks7• 6 years ago

Yeah. The urgency vs. resources I think is getting lost.

BCATV• 6 years ago

As others have stated this kind of solution would not be accepted in europe or north america, but as the blog post stated this work was requested by local health authorities. If a place can not afford a solution developed by companies in the field I think this can be better than nothing. At least it is something that can be improved. It's a shame that solutions exist but there is not enough money to buy them.

stonewhite• 6 years ago

I think there are some redacted out parts of the blog. The difficulty with the "Realtime Result Interface" not using HL7 remained unaddressed.

I'd like to read about those challenges as well.

zoom6628• 6 years ago

Hats off to these students. Great job under time pressures and in realities of an environment in which one can't just spend your way to a solution. If only more people spent time building useful things like this instead of yet another cat monitor, new ways to waste more money without leaving the house, and other non-life-enhancing trivia. The collective skills out there are almost unlimited.....especially the incredible people who post and comment on HN.

Please everyone reconsider the uses to which you put your amazing abilities. Code could change the world if we built more useful things, less blogs, less shopping carts.

Closing point.... Once a project is dealing with hardware it's 20x harder. But the outcome is better. In code as in life, when faced with easy choice or hard, always take the hard one. It's how we grow as people and extend our skills.

rud• 6 years ago

Just one word: Bravo.

scared2• 6 years ago

Very nice. But one question, what other languages do you know at a level of competence comparable to go?

kasvith• 6 years ago

thanks for sharing the article

Building a patient monitoring system with Go and Vue in 3 days

Related Stories