Abigail,
We’ve helped ambulatory EMRs and labs with this same issue for roughly the past 3 years: scalabull.com , a sample API we offer to EMRs: docs.scalabull.apiary.io . It seems you may be focused on a more abstract version of the problem - we work primarily between labs and ambulatory EMRs. That said, we would absolutely love to discuss merging efforts and helping you if it makes sense!
You seem knowledgable regarding this space, so I may be stating the obvious, but there are a few quirky things that we run into which may be worth having an open discussion around in order to help the project succeed in the lab-EMR space. I don’t mean to hi-jack your thread, but I think this could be interesting information for some people browsing thru! Would love to hear your thoughts:
-
We regularly see that CAP requirements imply that labs need to do some degree of testing when connecting to an external EMR. This is a bit gray, but usually labs are requesting screenshots or PDF reports that reflect the EMR display of results or requisitions for every single interface, and generating / adjusting these is often the most tedious part of the interface setup process. Even with a modern system based around the latest technology, there is still a labor-intensive setup process… Part of our service to partners is that we automate this testing process - it’s gotten some good feedback from labs. If a process for this setup phase is included in the protocol (thus avoiding the manual labor), labs have a tangible cost incentive to adopt & support the protocol.
-
Maybe around 80% of the labs we encounter are partnered with 3rd parties that handle EMR connectivity on their behalf, and it seems that’s mostly because labs don’t often employ software engineers. Scalabull falls into this 3rd party bracket, as do companies like Halfpenny, 4Medica, Lifepoint, Emdeon, etc. (I’ve seen reports of about 30 service providers in the industry, with around 10 of them handling most of the connections). Although, I believe our new beta solution is the cheapest & most efficient for labs by a factor of 10x (disclaimer, I’m the founder of Scalabull
). But, a new highly-efficient protocol could be smothered in the lab-EMR space unless you can find a way to align with or work-around these ‘hubs.’ For many of these companies, this is a threat to replace their business model as they typically charge a flat fee for every single HL7 connection created to an EMR, so it may be tough to get them onboard if you’re providing a more efficient way to do things and replacing their billable hours… It would be possible to work around them if leveraging the protocol requires very little manual labor on the lab’s part and if you can automatically distribute the update to the lab’s EMR/LIS installation, e.g. allowing the labs to use the new protocol without the hub’s intervention… We don’t charge per connection (our model is unlimited connections for $x/month), so we’re more than happy to align with something more efficient. -
Admittedly, we don’t have vast exposure to the different EMRs in the market, but right now in the ambulatory EMR space it seems most vendors are looking to support ordering in an efficient way. I’ve seen that the long-standing EMRs have offered this service for some time now, and MU2 certified EMRs generally seem to have the technology - although I don’t see many EMRs actually creating these bi-directional connections at scale. However, maybe if the server applications you’re creating include straightforward ways to access test compendiums, requisitions, and specimen labels for laboratories, this would remove a large part of the manual setup process for EMRs and they may be willing to take the time to add OAuth support to cut their bottom line. We give EMRs a way to grab this information from us via an automatic API, and I would say it’s our strongest selling point to partnering with new EMRs.
-
I think the most recurrent issue I run into is that almost all ambulatory EMRs charge fees for interfaces, and therefore labs can usually only afford to connect a few clients at a time. We see a good deal of labs having to turn-down interface requests from clients because of this price wall. And, having worked on the EMR side, we are guilty of charging this fee as well - simply because there is a labor intensive process for creating new connections to labs… If this new protocol gives EMRs a way to instantly connect with labs (and includes all automatic testing procedures), there might be a way to waive the fees since connections would require zero effort on the EMR’s part. That said, in practice it will probably be a little bit of push & pull: if you can help reduce the fees that EMRs charge, labs will be more willing to use the solution, but if the fee reduction isn’t practical for EMRs they won’t use the protocol in the first place… Putting this argument differently, most EMRs are charging money for interfaces and they may be hesitant to adopt a protocol that removes their HL7 interface revenue stream. In our experience, this has been the #1 reason EMRs don’t want to rely on a 3rd party like us - they either have a process that is profitable or sustainable and there aren’t tangible reasons for them to tamper with this.
-
Roughly speaking, I think LabCorp & Quest make up about 40% of the EMR-lab interface projects we complete for EMRs. And in order to complete those projects, we first had to go thru a pretty tedious certification processes for their protocols. After spending a year developing and testing solutions that conformed to LabCorp & Quest’s standards (which combine the industry standard Hl7 interface process with web services), we can much more easily set up connections with labs that are using the standard HL7 interface process. On one hand, finding a way to combine efforts with LabCorp & Quest could possibly put your protocol in the hands of most ambulatory EMRs within a few years. On the other, not being aligned with them raises some complexity for most of the ambulatory EMRs - they’ll have to support yet another format and it may not be a priority.
Hopefully this doesn’t come off as off topic, or over-complicated
Do these points resonate with your experiences? Are we approaching the same problem?
Since Scalabull is a relatively young company, I do have to be careful about where we can spend our time so that we’ll be around for years to come. That said, if you feel we’re aligned, I’d really love to help build-out and push this initiative forward. The caveat is that we’d need to find some funding thru the project or find another means to justify this from a revenue perspective. I’m happy to seek that out independently, but would also like to discuss that with you since it seems you’ve been able to do the same.
Would love to chat with you (or anyone else interested in this topic reading over this thread). Feel free to reach out to me at zach at scalabull dot com!
Thanks!
Zach Boldyga
