Thought this was great - especially being so up front about the value of distribution.
I wrote a post about the very same meetup, but note distribution is not one of our "why open source" answers https://www.medplum.com/blog/yc-oss-faq - perhaps we are alone in this regard
We definitely take input from the community and are interested to hear from teams about which compliance frameworks they would like to see. We also think open source and self-hosting has a role to play here. For example, some countries have data residency requirements, and we hope that developers would start by using Medplum and building additional features/validating their self-hosted environment up to a local compliance standard.
1 The features we charge for are usage based. For example on our hosted service the number of FHIR resources and automations (Bot executions) customers use is tiered. We also charge for compliance related features, like a Business Associate Agreement (BAA).
2 I like the paper you linked to and think it is useful.
In terms of the interoperability criteria - this looks very similar to the criteria for ONC certification. Though we are not yet certified, we are working on it and you can see some of our documentation here https://www.medplum.com/docs/compliance/onc
3 Community and support is one of our goals as well and yes, we plan to hire team members explicitly focused on community
4 We do target developers, and not practice professionals. There is value in low-code in specific scenarios, but are focused on the developer because the workflows and data structures are complex enough that programming is preferable to, for example, complex configurations. We do not expect that those who develop on top of us will make their code open source.
5 In terms of consolidation - we do think that having data stored in a standard compliant way (FHIR) and available via well-documented API is useful, both for the consolidation scenario and for other interop use cases. We don't have any plans to coordinate with equity groups at present - but that's an interesting idea
HL7 integrations that are for EHRs that we already support are included at no additional charge. For example, you can export to PracticeFusion, Athena Health and DrChrono automatically as part of the base platform and more are coming. You can also customize your HL7. Some institutions require custom medical/legal documents or complex integration with multiple on-premise EHRs, VPN connections and advanced automation etc, and those are billed separately.
There are a couple cases of underserved merchants based in the US where Bitcoin would compete with CC in a first world market.
The first is marijuana merchants in CO and WA. Marijuana is legal at the state level but not federally. These merchants have a hard time using the banking and credit card systems and transacting in BTC would help them do e-commerce.
The second is very low denomination transactions (like 10c). It may become profitable for compensate people at scale for doing some very small amount of work. Like giving someone who finds a typo some small amount of compensation. Credit cards are very poor for this.
As for replacing CC, that is a tall order. They are expensive and inefficient, but accepting credit cards does increase top line revenue if a merchant accepts them. If a payment method is going to get adoption it needs to grow revenue (vs. reduce cost) for a merchant if the merchant accepts it.
In the short term, I think it will have a hard time gaining use as a currency. A few currency scenarios might pop up, for example countries with unstable government or corrupt governments could see people store $ in BTC instead. However, I do think it could be very valuable as an application. Like if you layered it on top of the existing payment system to provide better security/anti-fraud.