Location: Madison, WI
Remote: Yes - ideal
Willing to relocate: No
Technologies: C#, TypeScript, React, Python, SQL
Résumé/CV: https://bhm.sh/resume
Email: bhm [at] brianmorrow.net
About:
Full stack developer with ~8 years of experience in enterprise software development. I'm currently a Senior Software Developer at Epic building electronic medical record software with TypeScript, React, C#, and M. I've worn numerous hats, including: product lead, team lead, and mentor. I have experience leading teams & projects, designing large & scalable systems, and using user-centered design methodologies with end-users and customers to deliver appropriate solutions to the challenges they may be facing. Throughout my career I've learned and internalized the value of clear & effective communication, flexibility, accountability, and empathy.
I'm looking for full stack opportunities at companies that are positively impacting their user's lives. I highly value the impact my work at Epic has on users and the patients they care for and I'm hoping to continue that trend.
The English usage is borrowed from French![0] However, it doesn't look like the original author was French[1]. I shouldn't be, but I am quite surprised to see that the apropos command as we know it is 43 years old!
No it doesn't. It explains what the three as a group do; what I'm asking is, what's the difference between these three? Why did we need three separate commands? When (in the pre-SSH days) would you use one versus the others?
I'd assume rexec runs a command on a remote host non interactively; rsh runs an interactive shell on a remote host; and rlogin allows you to interact with login(1), again on a remote host. But I've not read the man pages as I'm on my phone.
slogin is just a symlink to ssh, and sexec does not exist. So the s-commands' manpages tell me nothing about the difference between rsh, rlogin, and rexec, or why all three needed to be created.
The irony here is that these manual pages are the very things being patched in the headlined message. Their exact locations in the source tree, and some of their contents, are right there in front of us.
So read the older man pages? Why is this a problem? You can also easily read the man pages for a specific version of FreeBSD here https://www.freebsd.org/cgi/man.cgi
Right. They say that rsh can be used to get a login or run a command on a remote host. So why do the other two commands exist? In what situations would a person have wanted to use rlogin or rexec instead of rsh?
Maybe rexec appeared first? And when rsh arrived later, they still kept rexec around? Perhaps they had a lot of shell scripts that contained "rexec" and didn't want to bother changing them to "rsh"? The actual reason is probably so mundane that maybe there is no accurate historical information on this topic.
I agree. He's got a great ability to drive conversations on Talk Python With Me that may be floundering due to a guest with little podcast experience. He also does a great job on Python Bytes with Brian Okken who is a less strong host in my opinion.
It appears that PatientBank acts as a decentralized medical records/Release of Information office that may communicate with a number of physicians and hospitals. I'm curious though, how are you collecting the medical records? Are these interfaced directly from EHRs, or some other method? Do you handle releasing to 3rd parties (legal, etc); the article seems to hint that it's directly to patients and immediate family. Lastly, when a patient has shared their records with a new physician via PatientBank, is there any functionality for exporting these records into the physician's organization's EHR? Or will relevant data need to be manually copied into the new chart?
Great questions! So while the way a user orders medical records on PatientBank is the same across all U.S. hospitals, we have 5-6 different ways hospitals can fulfill those orders. These vary from fax or even snail mail to integrations. We actually opened up a lot of our performance data from hospitals here, if you're interested: https://www.patientbank.us/stats/about!
About exporting the data we gather to a new PHR and integrating the new information to patient's existing chart:
There seems to be a couple options!
1) Once we gather your records, we will work on creating a shareable summary of your health history. In that case, the physician can look at that summary via our web portal.
2) In many cases, most EHRs support the upload of PDFs. So, the documents you share can be "integrated" to hospital's EHR. This already happens in large hospital networks when hospitals gather medical records on behalf of patients before their appointments! When hospitals receive the records via fax or mail, they scan the pages to the EHR. Obviously, in the future, easier ways to export data (via EHR integrations) could be extremely valuable to patients and physicians!
In general most providers are never going to read through a bunch of scanned pages exported from another provider's chart. They just don't have enough time.
