Self-hosted lighthouse.fastenhealth.com an option?

[bugbountyguy]

I noticed while testing the application that, even though I'm on my own environment, there are constant calls to lighthouse.fastenhealth.com for things like search and adding sources. While this wouldn't be a problem if it were just to gather lists, I see this kind of breaking the whole purpose of Fasten - to be "offline" and "private".

When adding a source, a call is first made to lighthouse with the originUrl set to the person's own instance/url. While in most cases this is probably a private IP and of no use to anyone externally, it could get replaced with a domain name that's translated differently from a local DNS server, exposing some identifying information about who's making the request. This request is then forwarded to the provider with a callback to lighthouse.fastenhealth.com, which requires users to trust that lighthouse isn't storing this information for the "to" and "from" calls, leading to private data being compromised.

Not that I imagine you're all doing this, but I think that it would be super beneficial to provide instructions on creating a self-hosted lighthouse and how to hook that up to the onprem app, so that users can know that everything they do is 100% in their control. This also would help in the situation that fastenhealth.com were to not exist in the future and the user would still want to use the application. The way it is now, we're relying on fastenhealth.com to exist and be running just to run our own private instance.

If this already exists somewhere, then my bad on my miss for where this lies and feel free to just link me to those instructions :D

Thanks!

[AnalogJ]

Hey @bugbountyguy I touched on this in my initial introductory Reddit post for Fasten, but I haven't really discussed it since then.

The Fasten Lighthouse data flow documented in the FastenHealth/docs repo but I should probably flesh it out in the reasons it exists in the FAQ as well.

Let me summarize them here first:

---

1. The Lighthouse allows users to search for any supported healthcare institution by name, tag, address (and eventually country). It returns logos and additional metadata about the endpoint so that the Fasten application knows how to correctly communicate with the healthcare institution. As you can imagine, this dataset will be large (NPPES is 8gb by itself -- and that only contains US institutions).
2. Conforming US Healthcare institutions must allow patient access using the SMART-on-FHIR authenication protocol (its basically OpenID Connect). This means that app developers need to register an app with each EMR system (and sometimes each institution) and then securely store the returned client_id and client_secret.
   • Registering applications is supposed to be simple, however in practice it can be a huge pain in the ass (legal contracts, privacy policies, technical documentation, audits, registered corporation, etc) -- its part of the reason why progress in https://github.com/fastenhealth/fasten-sources/blob/main/PLATFORM_LIST.md is taking so long. I think the more PHR applications in the healthcare space will force EMR systems to streamline their developer onboarding flow, but until then a service like Fasten Lighthouse is required to have even a minimally functional user-experience IMO.
3. Fasten Lighthouse is designed such that it is only involved in the authentication flow, but it doesn't have access to the AccessToken/RefreshToken (by leveraging PKCE), and no patient data every transits the service (those requests are made directly by the Fasten Go backend, running on your own hardware). See FastenHealth/docs AUTHENTICATION.md for more information.

Regarding an "open source the Fasten Lighthouse" -- unfortunately for now the Fasten Lighthouse will remain closed source.

• I'm still unsure about the Fasten monetization strategy (which will probably involve the Lighthouse since all new-connections require it)
• I do plan on releasing a "spec" for the Fasten Lighthouse API (other than search, its a pretty simple service under the hood)

I hope that answers all your questions (but happy to dive deeper if I missed anything). I'll keep this issue open until I add this content to the FAQ page.

[bugbountyguy]

Thanks @AnalogJ that answers my questions and concerns clearly, I'll check out those docs as well, and thank you for the quick response to my issue I appreciate it!

[AnalogJ]

No worries, it's definitely an oversight on my part, since the Fasten "marketing" implies that its completely self-hosted -- which is not quite true.