4 ms·

It's great to see (and to see you have fans here) -- Veeva for EHR? If/since this is a freemium model, can you talk about the kinds of features you would end u

by w10-1 4y ago

It's great to see (and to see you have fans here) -- Veeva for EHR? If/since this is a freemium model, can you talk about the kinds of features you would end up charging for? The 2019 state of open-source EHR is reported here: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6517630/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6517630/ It would be interesting if published an assessment of your status and plans using their criteria. I've seen practices successfully using two of the recommended EHR systems. Technically most seem in the ballpark, but the key seems to be whether there is a robust community validating the code and providing timely support. In that respect, another open-source alternative is not necessarily a good thing. Do you have any community-building hires in mind? As for clients: the adopters are often medical people who picked up enough technology to wire things together, and do so for their practice employees. They're not super interested in sharing the secret sauce of their practice with consultants who will simply repurpose that knowledge for the competition. The most successful OS EHR's seem to be configurable by these adopters. But it seems medplum targets developers (not the practice professional). If (since) those developers may have a tough time, do you have designs to pivot to new low-code approaches for end-user? Conversely, if you stick with the EHR-AAS back end, the trend of the last few years has been for private equity to buy practice groups. I don't see yet the incremental value for the adopter or users of your offering over existing EHR's. But equity would be super eager to buy practices with EHR's ready to audit for due diligence before purchase and ready to integrate after. That could be a selling point for practice managers. Do you have any biz-dev plans to coordinate with the equity groups playing in the medical space, or investments from them, to tide you over the long process of gaining mindshare in a conservative market?

reshmakh 4y ago
Good questions. Some thoughts: 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 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

by w10-1 4y ago

reshmakh 4y ago

Good questions. Some thoughts: 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 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