
Building a patient monitoring system with Go and Vue in 3 days - astdb
https://kasvith.me/posts/how-we-created-a-realtime-patient-monitoring-system-with-go-and-vue/
======
mfashby
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...](https://www.gov.uk/government/publications/medical-devices-
software-applications-apps) in the UK)

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

~~~
fhsm
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...](https://www.fda.gov/medical-devices/safety-
communications/cybersecurity-vulnerabilities-certain-ge-healthcare-clinical-
information-central-stations-and)

[1]
[https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfStandar...](https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfStandards/detail.cfm?standard__identification_no=36409)

------
sergioisidoro
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!

~~~
prostheticvamp
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.

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

[https://www.cms.gov/](https://www.cms.gov/)

~~~
spenuke
Yes.

------
stephenboyd
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
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).

------
saintfiends
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.

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

------
shadycuz
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?

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

~~~
fhsm
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://link.springer.com/chapter/10.1007/978-3-319-43742-2_5)

\-
[https://www.nature.com/articles/sdata201635](https://www.nature.com/articles/sdata201635)

------
SergeAx
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
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.

------
BCATV
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.

------
alexbanks
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.

~~~
kalleth
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.

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

------
joshgel
Also see:
[https://github.com/smarterdx/covid-19](https://github.com/smarterdx/covid-19)

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

------
HorizonXP
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.

------
zoom6628
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.

------
emilburzo
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.

~~~
kisamoto
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.

------
2StepsOutOfLine
> Channels allow mutex free communication between goroutines without a pain.

Channels are not lock free:
[https://github.com/golang/go/issues/8899](https://github.com/golang/go/issues/8899)

------
stonewhite
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.

------
johannes_ne
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/](https://vitaldb.net/vital-recorder/)

------
naasking
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".

~~~
PudgePacket
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
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.

~~~
cma
I always heard hard real time for that, and "real time" could refer to either
and was often used when talking about game rendering, etc.

------
kalleth
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.

~~~
olieidel
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_otp
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?

~~~
p_l
Availability.

Just availability.

This was a quick and dirty hack to improve access to patient data done with
what was on-hand, for a constrained deployment using specific known devices.
They didn't have anyone with knowledge on using any of the tech you mentioned,
some of which requires spending months setting up unless you have practical
experience in delivering on the platforms. Just getting a more safety-minded
setup for a MCU using free software can be a harrowing experience.

And they don't have the money to just contract it out or pay for the
commercial grade stuff.

They did what they could with what they had, with explicit mention that it's
not good on safety and security - but it brings some benefit _now_.

Here in Poland, a few weeks into lockdown, nobody asked for certifications on
volunteer made PPE parts anymore. Because a shoddy PPE with no certification
was still better than none.

------
vchak1
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
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.

------
parhamn
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.

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

~~~
vijaybritto
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.

~~~
capableweb
> 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).

~~~
foldr
A REPL only gives you instant feedback on code that you type into the REPL. If
you make some changes to three modules and you want to find out the effect of
those changes then you need to...recompile the modules. Having a REPL doesn't
help.

I don't find that a REPL really gives me anything that I don't get from tests
in Go. The only difference in practice is that I type the code into a text
editor rather than into a REPL prompt (which is actually a better experience).
On top of that, it's usually good to have that kind of code saved somewhere
rather than existing ephemerally in a REPL session.

~~~
capableweb
Depends on how the language you use works. Golang is not made for repl usage
so of course you don't really get the full power. Compare with something like
Clojure where redefining a function in a repl, makes every function using that
function also use the new definition. Start treating functions as just
functions without any implicit state, and you can start to overwrite things in
the program on the fly. Super valuable when debugging and otherwise also when
creating code as you can much easier test ideas.

I don't know if it has a different word, but a repl for Clojure using a repl-
workflow is very different from a repl for Golang with the normal "save ->
compile -> run" workflow you have with Go.

For example, using a repl-workflow in Clojure doesn't mean you don't write
code in your editor. I use vim + vim-fireplace to write my code, then
highlight the parts I want to evaluate. So I get both in one. The repl is
running in the background, and vim-fireplace communicates with it. Combine
this with a SPA and I can have something like `(.alert js/window @username)`,
highlight it and evaluate, then have an alert prompt in my browser window,
which is next to my editor. Saves me a ton of time.

~~~
foldr
Yes, I've used Clojure and other Lisps before. The thing is, I don't want to
overwrite function definitions in a REPL, because I then lose track of what
code I'm actually running. It's much more effective just to make changes in a
text editor and track your state using version control. In a language that
compiles quickly, a REPL just adds an additional layer of complexity for no
benefit. In a language that doesn't compile quickly, redefining functions on
the fly in a REPL is a useful hack that lessens the pain somewhat.

>I use vim + vim-fireplace to write my code, then highlight the parts I want
to evaluate. So I get both in one.

Sure, and with Go in VSCode, I just click 'run' above the test I just wrote.
It isn't any more difficult.

~~~
capableweb
> much more effective just to make changes in a text editor and track your
> state using version control

Statements like this makes it seem like while you probably have dabbled in
Clojure and other lisps, you haven't used them substantially, as if you're
using Clojure, you still make your changes in your favorite editor and code is
still tracked in version control. It's not REPL _or_ code editor, it's code
editor + repl backing.

Redefining functions on the fly is not a hack to lessen the pain, it's a
defined workflow that makes you be able to work faster. If you're using it and
it feels like something to lessen the pain, you're using it wrong.

> Sure, and with Go in VSCode, I just click 'run' above the test I just wrote.
> It isn't any more difficult.

This assumes a lot of things around the code that you're executing. First,
you've already setup a test and it's already isolated enough. With a powerful
repl + idioms, you don't need to do that, as you can execute parts of a
function just to introspect that part, kind of like a debugger but works
anywhere automatically.

In the end, I'm not gonna try to convince you to try something if you don't
want to try it. But if you're anything like me, finding more productive ways
of working is always interesting, even if they end up not being as productive
as we first thought. With that in mind, since you seem to not have super much
experience with a powerful repl, if you try it I'm sure you'll find what I say
to be helping you be a better programmer.

~~~
foldr
>you still make your changes in your favorite editor and code is still tracked
in version control.

Version control does not track which sequence of code snippets you have
(re)-evaluated to get to your current repl state. I'm fully aware of how
editor integration with a Lisp repl works in Emacs and (to a lesser extent)
Vim.

>have dabbled...In the end, I'm not gonna try to convince you to try
something...seem not to have super much experience with a powerful repl...etc.

As with most Lisp advocates, you seem unable to a accept that I _have_ tried
it and didn't like it. Please stop throwing shade.

> This assumes a lot of things around the code that you're executing. First,
> you've already setup a test and it's already isolated enough

A test in Go is just a function, so no set up is required. A test is more
isolated than an expression evaluated in a repl.

It seems to me that you don't have much experience of writing tests in a
modern development environment, and this is why manually recompiling parts of
your codebase using Vim hotkeys strikes you as a good idea :)

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

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

------
min2bro
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/)

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

------
rud
Just one word: Bravo.

------
kasvith
thanks for sharing the article

------
didntknowyou
great work

