Thanks! We’ve definitely put a lot of thought into making emdash feel smooth, intuitive, and frictionless. We are constantly looking at all the seams where pieces connect and making sure they fit tightly.
We probably over-invested in some details, but we believe those small touches add up, kind of like getting that nice “thunk” when closing a well-built car door. Glad you noticed the polish—it’s something we really care about!
Thanks! One of the benefits of dogfooding our product everyday is that we invest a lot in working out the everyday kinks in addition to the marquee features.
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.
