Welcome to the NEW CHUG— your ultimate destination for cutting-edge insights and discussions at the intersection of healthcare and technology.

Our platform is dedicated to exploring the dynamic landscape of healthcare technology, empowering professionals, enthusiasts, and innovators alike with the knowledge and resources to navigate the rapidly evolving field.

From telemedicine revolutionizing patient care to the transformative potential of artificial intelligence in diagnostics, we delve into a myriad of topics shaping the future of healthcare delivery. Whether you’re a seasoned healthcare IT professional, an aspiring entrepreneur in the digital health space, or simply curious about the latest innovations, our curated content, expert interviews, and thought-provoking articles provide a comprehensive exploration of healthcare technology’s most pressing issues.

Join us as we navigate the forefront of innovation, driving forward the transformation of healthcare for a healthier, more connected world.

Have questions or suggestions? Please use the contact button below.

Notifications

Clear all

Patient API Web Application Firewall

Patient Self Service

Last Post by Anonymous 1 second ago

4 Posts

2 Users

0 Reactions

149 Views

RSS

[email protected]

(@tbarnespainmd-com)

Posts: 2

New Member

Topic starter

We are looking to get the Patient API up and going. Veritas/Athena has recently publish a guide, "Guidance for Implementing Internet facing deployments" in which they seem to be highly recommending the use of a Web Application Firewall. (WAF)

My original thoughts we simply opening the 9443 port to the FHIR server via our firewall.

Would like to know what other practices are doing to enable FHIR (Patient API) access.

Does port 9443 just have to be accessible to certain sites or the whole internet? If a patient has an app made by say Medical Apps, does the port just have to be open to Medical Apps IP addresses, or does the patient's actual phone ip need access?

Thanks for any input.

Posted : August 8, 2019 9:43 am

tnc

(@tnc)

Posts: 517

Honorable Member

I have been looking at this since the beginning of July. From what I have learned it needs to be open to the whole internet. The measure calls for anyone being able to access their information just by installing an app on their phone/tablet without having to set anything else up besides the app and their identity. The apps will authenticate with Azure AD and get a token but the IP address would be that of the phone/tablet. I don't think has anyone invented an app yet so 99.999 percent of the traffic will likely be malicious/snooping for now. That .0001 percent will be testing during setup.

We are going to use a WAF to keep the bad guys/bad bots out. I don't know how a WAF knows the difference between good/bad traffic besides the obvious DOS attacks or out of band traffic or portscan activity. If you are required to let everyone in on that port then you can't really narrow it down. We already have fail2ban technology implemented so that will prevent any brute force abuse.

I wondered why they implemented things this way and have had discussions with support on this. I would have thought that they could have kept the FHIR separate from Jboss and you could just put the FHIR in a DMZ but I guess there are reasons why you couldn't do that.

I have been told that it would be easy to find a vendor willing to help design and implement a WAF but that has not been my experience. The trick is to find a vendor who knows immediately what you are talking about instead of one who wants to get a conference call to "see what you are looking for". That soft of conference call (to me) seems like one that vendor would need to have with Athena, not me.

From my high level view it seems simple enough, to place the WAF between Jboss/FHIR and the internet, inside of your firewall open to port 443. The leap of faith is to trust the WAF technology.

Just what I wanted-More security logs to parse.

Mike Zavolas
Tallahassee Neurological Clinic

Posted : August 12, 2019 5:49 am

[email protected]

(@tbarnespainmd-com)

Posts: 2

New Member

Topic starter

thanks so much for responding.

I had heard back from support that the API calls may come from just the APP vendor or from actual devices depending on implementation. In short, Virence/Athena doesn't even know at this point.

I think we are going to implement a WAF appliance in our DMZ zone. Protect the front end with a SSL from a CA, but probably connect to the FHIR server through the back end (DMZ to LAN) with just the current self signed certificate.

Looking at a Sonicwall SMA (secure mobile access) appliance at the moment. These are designed for systems access for offsite users but they have an add on service for WAF. May be able to kill 2 birds with one stone. Barracuda has nice WAF, but twice as much as the Sonicwall.

Thanks again for response. Any other input/advice much appreciated.
tom

Posted : August 20, 2019 4:22 am

tnc

(@tnc)

Posts: 517

Honorable Member

I don't think we will ever know so we would need to build things to allow everything and never be able to lock things down, unfortunately. I think some App developers will need access from the device IP and some vendors will use their own resources, likely those will be collecting data. If companies like Facebook/Google/MS/Apple design such functionality we will surely see data collection going into their databases, for YOUR convenience of course.

Don't worry, their EULA you signed to use the app protects them so there is nothing for them to worry about 🙂

By the way, is the Sonicwall a cloud solution or an appliance?

Posted : August 20, 2019 8:36 am

Share:

24 Forums
9,940 Topics
39.9 K Posts
2 Online
6,470 Members

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed

Powered by wpForo Powered by wpForo version 2.4.0