HTN | Community Brain Trust | 6/13
👋 Welcome to this week’s edition of 🧠HTN Community Brain Trust🧠 – a community-only email, sent to your inbox every Tuesday, surfacing the top insights and conversations from our community.
Note: We’re testing changing the formatting of the Community Update this week. Let us know what you think of the changes at the bottom of the newsletter!
🧵TOP THREADS OF THE WEEK:
In case you missed them, here are highlights of a few interesting conversations from different channels:
Threads included below:
- Optimizing surgical implant inventory
- The future of e-prescribing in the US
- Striking a balance between product & engineering
- ELI5: Why FQHC's can't take downside risk?
- Understanding SOC2 requirements
1. Optimizing surgical implant inventory
Q: A question for the surgeon/proceduralists tech nerds in the crowd.
In case of implants - be it stents, orthopedics or anything else, usually a large variety of sizes is stored / brought in for a surgery. I was wondering how much is it possible to narrow this range based on the patients digitized information (imaging, height, weight and other things in the patients notes). And if it’s possible, is this somehow used today or you just have all sizes available for each procedure?
I’m sure answers will vary drastically by specialty and procedure - so the more input the merrier
– Boris Goldin | via #buildersask
John Klaus: Cardiac Stents and Atrial Appendage Closures: Generally we have a variety of sizes in stock, they are on consignment from the vendor, or in rare instances we will purchase a variety of sizes and exchange the ones that are close to expiration.
Sizing estimation is done via imaging studies, if it's a case where we won't have the size, we would call the vendor and have them bring it over. This works in a large metro area, but in rural areas this can significantly delay procedures.
For us trunk stock the item was manually entered (or scanned the UPC) into the EHR to capture the implant information (serial number, expiration, and so on) and bill the patient, then it would need to be manually entered in the hospital purchasing system to generate a PO for the vendor to receive payment. At the end of the month they would have to be manually reconciled to make sure we captured everything, and the vendor would have their own list to reconcile.
It's an odd flow, but the systems don't talk to each other so that is usually why there's that process.
Kiel Dowlin: For some implantable (let’s use ortho for instance) cases you have the implantable device rep with you and they may even be bringing Trunk Stock (i.e. variety of sizes, items) that are basically bought during the surgery - though PO is cut after surgery and then used to bill against other items. I know Orx.ai is working on some of this point of surgery process capture since right now it’s a lot of manual upc code + stick to a sheet in the OR and hope it makes its way correctly to the procurement department and ultimately to revenue cycle Ops to bill insurance appropriately.
Doesn’t really answer your digitization to save question but found this flow in OR to be so odd.
Boris Goldin: Thank you all!
Few follow ups:
- Is the process the same for consigned items in terms of capturing, cutting a PO, and paying (except they are brought way in advance)?
- For how much procedures did you need the vendor to bring is stock vs use stock that's in the hospital?
- The trunk stock (except consumables) is still sterilized by the hospital, right?
- No, for consigned items once the product is used, a new one is ordered from the company through normal purchasing process. Consignment requires an agreement between the vendor and the hospital, it is for a defined mix of products to be placed on the supply shelf, it requires regular inventory checks to ensure the right mix of products is still there, if not, then replacements are ordered. Any change to the mix requires a contract amendment.
- It varies a lot (not helpful I know, but unfortunately it depends on specialty)... EP Lab, 50% of total spend was trunk stock, Cath Lab maybe 20%, Vascular was generally <10%.
- Trunk stock is not sterilized by the hospital. Trunk stock is typically only single use or implants (sterilized by the manufacturer).
- No worries - to get the ranges is helpful too!
- Interesting. I’ve heard that hospital does that but in the context of orthopedic implants. Maybe it’s due to the size of the implants and kit involved (so you have a full sized tray instead of a small plastic wrapped pack)
- Re: sterilizing; if its sealed, its sterilized (broad strokes speaking here). e.g. plates, rods for ortho/spine/mfc. But for specialty tools, screws (4mm etc) that are in a kit depending on the procedure, those are sterilized at the hospital
- Re: stock; I've seen reps run to their car mid surgery to grab more stock; and I've seen multiple cases of low or no stock when systems showed full stock for core items
2. The future of e-prescribing in the US
Q: Anyone have thoughts on how new e-prescribing is going to evolve in US?
A few things on my mind:
- Digital first prescription for scheduled drugs
- Integration timelines for broader EHRs
- Integration with patient support programs and copay programs
- Limitations on refills/cross-state prescriptions
Would love to put together a fire-side chat for folks who are interested in sharing knowledge or talking about this. DM me– Yash Prajapati | via #topic-policy-regulation-legal
- for all intents and purposes, e-prescribing of controlled substances in the law of the land. most states require it, the DEA requires it, and it’s now part of ONC certification requirements
- to e-prescribe, you have two basic options: direct connect with surescripts or use an on-ramp-- see various @Brendan Keeler work including this article and this twitter thread. Both are viable for scheduled drugs, it’s an extra layer of certification. I think many people in this group have first hand experience with both options. As a general matter, you use an on-ramp if you need it fast and/or are relatively small. you direct connect only if you need to (have a very weird workflow) or lots of resources.
- all the major on-ramps as far as I’m aware have some relationship with co-pay and patient support aggregators as well as price transparency aggregators all to varying degrees of sophistication and success. there’s only so much you can do within surescripts rigid framework, but it’s something A LOT of people are working on since life sciences will throw money at the problem
- limitations are mostly driven by a combination of DEA policy, federal law, state law, board of pharmacy, and state medical boards.
I’d be remiss not to mention the very cool work @Otto Sipe is doing at Photon Health.
Otto Sipe: Awe, thx for the love @Martin Cech. We're always down to jam on this even tho we've not yet completed EPCS certification yet (given most customers of ours don't send controls). Coming soon. Emily on our team wrote a blog post about some DEA rules changes. We're hoping that we can add "logic" to Rx to help pharmacies and providers follow the new DEA rules when the come into effect.
3. Striking a balance between product & engineering
Q: Hi all! I have a question for CTOs, 1st engineers at a startup. How do you balance product work vs engineering work? How do you advance the product while also helping fix bugs/fulfill client requests to keep current clients happy and maintain their accounts as you grow? Any recommendations in terms of structuring your day or first hires you make are welcome!
– Eva Hibnick | via #buildersask
Ted Cheng: A strong Eng team should be able to advance product features while keeping tech foundation relatively stable. That said, early stage startups generally have a massive amount of tech debt. Not sure there’s any silver bullet. It’s a grind.
Eric Jain: I'm on west-coast-late-time, so I'd typically start the day catching up on code reviews, following up on customer support requests, reviewing error reports. Catch up with the team and other scheduled meetings before lunch. In the afternoon, "engineering work". Infrastructure work or releases happen in the early evening, when our users start going home, but it's still early enough to catch issues (so I don't need to roll back a botched update at 3am).There is never enough time to address all the tech debt and do all the feature work, so you have to prioritize what technical shortcomings are slowing you down most and causing the most unacceptable risk, and features have to be cut into the smallest chunks that can be shipped.
Patrick Leonard: My approach is to prioritize engineering work alongside features. These non-functional requirements should be assessed using the same data-driven decision making process you use for features (value to the business and customers).In quarterly PI planning, sprint planning etc, treat capacity as one bucket to fill up with functional and technical work.
Jonathan Belanger (JB): engineers should be talking with customers. great source of discovery. early engineers are flying the plane and building while flying... they are in many cases best suited to balance value/cost, especially if they are product-centric engineers and are talking to customers.
4. ELI5: Why FQHC's can't take downside risk?
Q: ELI5: Why can't FQHCs take downside risk?
– Kevin O'Leary | via #eli5
Kevin O'Leary: Saw this news from Yuvo Health this AM on their funding round (link). I found this quote curious about how FQHCs are prohibited from taking downside risk:
“Our mission is to increase access to primary care by supporting FQHCs, particularly in giving them access to meaningful revenue that comes through value-based care,” Herrera said. “The reason why we're doing this is because FQHCs need our support, but also because FQHCs literally cannot participate in value-based care. Unlike any other provider, FQHCs are prohibited, via regulation, from taking on downside risks.”
Anyone able to explain why FQHCs are unable to take downside risk, and how a model like Yuvo allows them to do it? Is there just a statute or something somewhere that says an FQHC entity isn't allowed to take downside risk (but it is allowed to take upside risk)? So is Yuvo just allowed to take risk on their behalf because its a different legal entity partnering with an FQHC?
Kevin Wang: fqhc’s don’t have a ton of financial, technical and administrative horsepower to administer and take risk even doing quality reporting for them can be a pretty difficult task
Kevin O'Leary: yeah that i totally get - but it reads to me like a regulatory restriction rather than a capability restriction
this slide seems to confirm that (and suggests some ways around it, which I'd assume Yuvo is doing the third suggested bullet) [Link to presentation]
Andrew Wess: Does this just mean the FQHC can’t contract for downside risk on their own but an FQHC-only ACO or MSO could? Have never heard of this.
A quick check shows the 3rd and 18th most successful (by savings rate) two-sided risk, “low revenue” MSSP ACOs in 2021 are FQHC-only. So I guess it’s true in theory but not in practice that FQHCs can’t take downside risk.
David Gross: FQHCs cannot directly take downside risk but are permitted to do so through an IPA/ACO arrangement. This has been the position taken by CMS, and it relates to concerns that if FQHCs take downside risk, they may (1) end up diverting their federal grants to cover these losses and/or (2) getting paid less from federal payors than required under federal law.
There has been some advocacy to get CMS to be more flexible to allow downside risk taking as some FQHCs have increased their sophistication. But I have only heard of it happening - on a very limited basis - in CA, where the State got federal approval to try a new FQHC reimbursement methodology and the individual FQHC opted in to the arrangement.
Michael Dolot: Alex, I think you answered your own question here, but yes - an ACO/MSO made up completely of FQHCs can take downside risk. Interestingly, it is actually becoming pretty common to see that. Each state has a Primary Care Association (PCAs) that represents the state's FQHCs. Many of those PCAs are looking into creating CINs to allow them to run their own VBC programs and take downside risk.
As to whether individual FQHCs can take downside risk, David's answer represents the mainstream thinking. The primary reason I have seen is that FQHCs cannot receive less than their PPS rate for a visit and downside risk could lead them to receiving less on a "net basis".
I will say that I have seen legal opinions that suggest that individual FQHCs could take downside risk. With that said, the vast majority of FQHCs are relatively small in terms of patients, so they would struggle to reach the number of patients with a given payer needed to have actuarially-sound risk pools.
5. Understanding SOC2 requirements
Q: I am on the product team for a tech enabled digital health company. We're in early conversations with employers. I am trying to figure out if / when SOC2 applies to us (e.g. not at all, when we're of a certain size, only if the employer requires it, etc). If anyone has insight, I'd appreciate it!
– Anonymous Bot | via #buildersask
Mark Olschesky: It's entirely free to say that you follow all the safeguards to comply with HIPAA/GDPR/CCPA but having it independently validated by a 3rd party allows the customer to be assuaged that they are well suited to take on mutual risk with your business.
You'll find out pretty quickly how much you need it based on:
- You just lose deals to a vendor with more maturity/better security/compliance modeling/offering. (usually in the deal lost someone will tell you this pretty explicitly that they'd buy your thing but they want you to have whatever cert)
- You can win deals but you have to take on a disproportionate amount of liability.
It's not an absolute blocker. Even SOC 2 companies themselves can carve out exceptions for companies that don't have a SOC 2 Type II but usually it means you have to be on a path to do so imminently you might win the initial deal with the carve out but then fail to renew/expand. You'll find that some organizations are much more dogmatic about SOC than others.
Roc Hargrove: You can go a long way by saying that you are in the process of getting your soc 2 and fill out any security questionnaires. at least we did. i would start the process asap. the questionnaire approach also assume you have your act together. this is a small consulting shop that can help you get started. lots of newer services that weren't around when i went through this that i'm sure make it easier. [Link here]
Kevin Holland: Use Vanta and say that you are in the process right now
Kaitlyn O'Connor: You can also often negotiate an onramp if you have a customer that requires it. For example, you can request 12 months to conduct your first SOC audit(s) and in the meantime comply with ISO 27001. This is helpful for early stage companies that don't have the budget or time to go through the third-party process unless/until there is a significant deal in the pipeline.
Here we highlight a question from the Slack that needs some additional community insights - if you have a helpful thought, jump in below!
Q: Has anyone seen a psychiatric hospital provide chronic care management for Medicare/Medicaid mental illness?
Who would be the appropriate provider to use a CCM solution specifically targeting depression? PCP? Psychiatrist?
And more, have you seen substance use or psychosis work for conditions eligible for PCM/CCM?
🤖HTN KNOWLEDGE BOT:
If you have your own question(s) to ask, don’t forget that a good place to start is our HTN Knowledge Bot. It’s our smart search tool that makes it easier to access the wisdom shared within HTN powered by ChatGPT. You can log in and use it on the website (here) or see how to use it directly in Slack here. Check out the example ask below!
Here we highlight helpful resources from across the community:
- Harvard Business School Case Study: Sword Health via Kevin Wang
- Gust (accredited Angels list) and Signal NFX (stage agnostic investor list) via Ajay Gopal
- The State of AI in Healthcare PART II via Rikin Mathur
- Death by a thousand point solutions via Arpan Parikh, MD MBA
- America's Physician Groups conference via Zach Mitchell