Shift+6

Ryan@Folx

Episode Summary

Ryan Scharer, CTO of Folx spills the beans on his new startup, a telehealth play for the LGBTQ+ communities. We dive into early-stage technology decisions and contrast those with scale.

Episode Notes

We’re thrilled to announce Shift+6, a developer-focused, health-tech podcast from Redox. Here we'll explore the ways amazing technologists are bringing new innovation to market, growing their teams, and dealing with an ever-changing landscape in one of the world's most complex industries.

Our first guest is Ryan Scharer, the CTO of a new (and maybe in stealth mode?) telehealth startup called Folx. You might be wondering, “Does the world really need another telehealth offering?” Short answer: yes, this world does. Folx is aimed at LGBTQ+ communities with representative care providers, “Telehealth that’s pretty queer” as their website states. Check out their purpose statement here, it’s moving. 

Ryan’s building on a long history of success in the digital health space, having played this early-stage engineering lead role at Humedica (acquired by Optum) and PatientPing. We dive into those early decisions and tradeoffs we make in building product and eventually taking it to scale. Here are some highlights:

Ryan mentioned to reach out to him on LinkedIn if you have questions or want to start a conversation. 

Thanks for tuning into our first episode of Shift+6. We’ll be launching our own podcast show soon so look out for that and be sure to subscribe. And let me know (podcast@redoxengine.com) if you have ideas or feedback for the show. We’re excited to bring this to the healthcare developer community. 

Episode Transcription

James: [00:00:04] Welcome to shift six, a developer focused health tech podcast from redox. I'm your host and the CTO at redox James Lloyd

Here, we'll explore the ways amazing technologists are bringing new innovation to market growing their teams and dealing with an ever changing landscape. And one of the world's most complex industries.

We believe that technology from diverse and empathetic creators holds the power to improve the lives of patients across the globe. And we hope this podcast helps make your work in healthcare even more impactful. Let's jump in.

I first met Ryan Scharer few years back when he was the VP of engineering for patient ping, one of digital health up and coming success stories. And friend of redox. Ryan has a long history as an engineer in health tech, working at the Institute for health metrics and Humedica through their acquisition by Optum creating Optum analytics.

Ryan's now launching a new startup in the telehealth space called Folx that I'm super excited about. It's a pleasure to welcome Ryan as our first guest on the new Redox developer podcast. Shift+6, Ryan, thank you for joining us.  

Ryan: [00:01:05] 

thanks for inviting me, James. Super happy to be here.

James: [00:01:07] Yeah, well, let's jump right in and I would love to hear a little bit about,  your new company and your new endeavor and, overview of what you're trying to do and kind of how the product engineering team is, is getting started there.

Ryan: [00:01:18] Yeah, absolutely. so Folx is a brand new company. It's a seed round startup, aimed at being a health and wellness platform direct to consumer healthcare. Specifically aimed at the LGBTQ plus community. so you can think of it as like a, for hymns or for hers Roman or keeps or any of those others were direct to consumer companies, but with a focus on a very specific community.

and there's a. Bunch of loggers check behind why it makes sense for Folx to exist sort of standalone instead of being an outgrowth of like a HIMS or something similar. most of them rooted in things like authenticity and credibility, but, as to why the community sort of needs its own platform, there were a number of issues.

sort of affecting the community as regards to healthcare, as you can imagine, healthcare is one of the more sort of personal and private things that one can go through, especially for, you know, depending on where you're going in. and to have a practitioner you're working with that really understands your concerns and has background.

in what your sort of path might be in your thoughts might be, is super important. that said, we're trying to make this as sort of empowering as possible. So, you know, if you look at the current crop of direct to consumer companies, it's all about choosing your own path and really where medicine creeps in is at the.

Edges and where necessary. So to offer expert advice or to check whatever boxes are required by a regulatory environment, to make sure that, you know, you're, you're safely achieving your goals, but really it's about empowering the consumer to, pursue. You know what it, what it is that they're after.

So, you know, in some cases in the, you know, in the case of hymns or hers, like, you know, often that turns out to be something like a haircare or, yeah. It's, you know, and skincare or something or ed or something similar. and some of those are common to the queer community as well. But, you know, for example, we're looking to pursue things like hormone therapy for the trans community, which is something that is, very specific and requires its own protocols and its own expertise.

James: [00:03:31] Yeah, that's super interesting. And, and, Amazing mission. I'm I'm so glad that, you all are working on it and, we get a chance to chat today about it. are there beyond sort of just providing them normal scope of care and you know, everything that goes into providing a health care technology product.

Is there anything unique from the demographic that you're trying to serve that really bubbles up in. Engineering life that may not be, something we would expect, or maybe, maybe it's been interesting kind of challenge you've had to deal with at all.

Ryan: [00:04:04] well, I mean, they're really the we're the impinges on the technology is really, it's specific edge cases. So again, if you're dealing, with a lot of Folx in the trans community, for example, there are a lot of, correct sensitivities around using, an affirmed name, for example, and affirming name, as opposed to a legal name that they no longer recognize, but which might be required to write medications, for example.

So you have to be very sensitive when you're selecting. All your platform technologies that you pick a suite that can work together and can respect that choice and only surface the chosen name where appropriate to the patient.

James: [00:04:39] Yeah, that's really interesting. And are you finding that that's a, a challenge to find technologies that are able to meet your needs?

Ryan: [00:04:47] It definitely can be like we're, we're in an interesting space. I think there's general awareness amongst vendors that this can be a concern though. I still run into some that are sort of caught flat footed by it. But often it turns into like a workaround, right. Where it's like, Oh, well, you can kind of do that.

Except you have to jump through these hoops and you have to be careful not to do this. and there are some that have actually, Gone above and beyond, and really integrated into the core of the system. So that's one thing that I was completely ignorant to that when starting with Folx a couple of months ago, as far as what the technology landscape and support looked like, and then sort of gratified that some of the groundwork has been laid, and it's not something that we have to start over from scratch with.

James: [00:05:25] Yeah, that's really great. That's really great. Maybe changing gears a little bit. I would, I would love to hear a little bit from your personal active on what it's been like to go from, you know, patient paying, which is a fairly established now, I guess my may still be considered a startup to some, but you know, a fairly established company to, to now, sort of a brand new new event.

Sure. We're completely clean slate, blue sky, whatever you want to call it. what are the sort of the what's your day to day? You know, changes has been like a, you know, from one role to the next.

Ryan: [00:05:56] right. And this is obviously a very particular time, for myself in the country in a lot of ways, because it's not just dealing with, you know, changing from a mid stage company to a seed stage company. But it's also, you know, for me as for many people, this is my first remote. Purely remote position.

and you know, my first time working with colleagues whom I've never met in person had no immediate prospect of doing that. So there's a lot of sort of figuring things out as we're going. that said, if you're talking about the general points, I mean, this is a journey that I've taken four or five times now where like, you know, I go into a very, very early stage thing because my favorites stage of a company honestly, is going from zero to one and maybe one to two.

but, you know, if you look at. Any particular job that you might have being a series of trade offs between, you know, there's no perfect position, but the kinds of aggravations that you deal with, which are significant and a seed round startup are the kinds that I actually enjoy. and the kinds of aggravations you deal with that, like a medium stage company, can be a little bit, you know, things that, that were on me a bit.

So for example, I personally really enjoy having my hands on in both those strategy. And the architecture and the implementation and that that's something that really famously isn't very feasible as a company grows for very good reasons. you really want to take the GitHub keys away from somebody, when they're focusing on something else, 90% of the time.

but that said, you know, it's, it's extremely gratifying to build a team. It's, it's amazing to see. You know, a seed stage thing grow into like it's its own and see if he recognized out in the world. But when it finally comes time to sort of move on to the next thing and green slate, it's like, you know, Christmas morning, all the ways, because you get to like, You know, really dig into all the things you've been reading about in blog posts, but haven't really had a use case bubble up yet, or has been too much of a technological technical shift, you know, for you to really turn the battleship before and adopt.

and you know, there's nothing you don't have. All the accretion of all of the sort of assumptions and, solids, code and tests to cut through to really implement something. You can go very fast, very quickly. and inevitably, you know, you, you know, things mature and that sort of slows down, but, getting a chance to go back and do that again is, is terrific.

James: [00:08:10] And is there any new, you mentioned sort of the, the exciting technology that you may not have had a chance to interact with before? Is there anything that is, you know, you've encountered over the past couple of months, that that would. Kind of check that, check that box. It's something you've been super excited to get a chance to use.

Ryan: [00:08:26] Right. And for, you know, for some of these, somebody listening to this podcast, that's coming from maybe a different industry. They'll be surprised at some of the things I mentioned, but healthcare moves famously slowly in a lot of ways. again for often very good reasons. It takes a while for technology to be proven to the point where it can be trusted in a particularly secure environment like healthcare needs to be.

So. As an example, you know, three jobs ago when I was starting Humedica, we still did everything with like physical machines, and, you know, eventually did VMs racks, but we weren't really comfortable with public cloud and very few healthcare companies were. And then when I was at patient ping, I was all excited because, I got to actually use a public cloud.

So I really got deep into AWS while I was there. which was great, but we were all easy to base. and it took us forever to get to like IAC and stuff like that to patrol if that's our infrastructure is code best practices. And now, you know, that's a wonderful machine they've got over there, but, I wanted to do something much more lightweight, especially just getting into e-commerce.

So there's a very different set of concerns that we can too, but because I wanted to keep the team very small and focused, I really wanted to do as close to a purely serverless implementation as I could. at, Folx and so far we've been sticking to that. So when you're talking about things like infrastructure as code, instead of using like Terraform or Sam or something, I've, I've started using, what's called CDK or the cloud development kits from AWS.

And I won't. Unpack that in a lot of detail here, unless people really want to chase that into the weeds, but it's a way of like programmatically. I'm doing infrastructure as code work in a very efficient and reusable and productive way. Like I was able to stamp out like, you know, you know, what I think is a, is a pretty respectable, multilayered AWS multi accounts set up in like three days after just cracking open my first CDK examples.

So that's a particularly great technology that I can recommend. and then as far as fielding, the actual application code I've been relying recently on the serverless framework is again, a very productive way to just write your logic, send it up into the cloud. We don't ever have to worry about, you know, especially in a healthcare environment, something that's very regulated, you know, that at some point you're probably going to want to pursue high trust or a SOC two or some very, you know, a certification that requires a lot of proof.

That's what you are doing conforms to best practices as far as security goes. And that can honestly be a huge pain, especially if you're talking about even, you know, VMs and easy to require you to have like a really detailed and rigorous patching regimen for all those machines and, being able to cycle credentials and all that stuff.

And being able to push all of that into Amazon's concerns, if I'm using Lambda or a step functions or other serverless technologies, I'm using all of their security, auto rotate, platforms and surface stuff. you know, I think that when we do decide to do take a high trust journey at some points, like this'll be a much later process in this case than it is.

if you were taking on a lot of those responsibilities yourself,

James: [00:11:27] Yeah, that's awesome. That's awesome. It's as, as someone who is currently going, going through a high trust certification, I can, I feel a lot of those things that you're trying to avoid, so

Ryan: [00:11:37] Yeah, it's not the most pleasant thing. And I can say also that there are still technologies that I, you know, keep thinking that I'm going to get into and that there's finally going to be a problem that I can apply it to and then backing solely away. So, as an example, I've once again, read three books on dynamo DB, because if you read any of the AWS examples, they still push you heavily into using that as your persistence mechanism.

but as I have many, many times before I get. Already to do it and then realize that I don't have a compelling use case for it. In fact, I can see why I'm going to run into issues. And so I just, you know, back down and start using a relational technology again. So I'm using Amazon Aurora, the Postgres flavor, and we're going to be accessing it using graph QL.

So at least that's new and cool, but, still no, no SQL for me really.

James: [00:12:28] Cool. Cool. And how are you thinking about, the balance of. Scale with getting something out to them, the market quickly. I know this is something, I feel like every, every new company, even outside of healthcare, you know, deals with, but, just from, from somebody who's making these decisions day to day right now. yeah, I think about it.

Ryan: [00:12:45] PR ruthless and relentless priorities. Really? So yeah, you just need to know what Hill you're going to die on and you have a budget for that. So, you know, you've, you've got, yeah. After you've been through a few of these, you sort of have, a pretty good set of heuristics as to what's kind of expensive and what's going to be cheap both from like a level of effort perspective, as well as a risk.

Perspective. So, you know, you want most of your portfolio to be full of stuff that is commodity that, you know, you can either purchase from a third party or knock out really quickly, you know, that you're going to have at least a couple of things that are going to have an awful lot of unknown unknowns built into them, especially if you're moving a product space that you have no experience with and you want to sort of over budget for those things.

So, you know, for at least, you know, e-commerce play. Y, you know, you, you probably wants to spend an awful lot of time on. Really communicating effectively through your products, you know, who is this for? conveying through the aesthetics of it and the interaction patterns with it. Like, you know, why it's exciting to work with it.

how can this change your life relative to other things? And then. In the back, like really your it's an integration story here, you know, you're, you're purchasing a bunch of functionality and you're stitching it together with automation. You, you, because that's how care you're going to put a high premium on, audit logs and, traceability, that you may not have, it's do in some other domains.

So you've got a bunch of data in as well. and there are some things that you're just gonna are going to be suboptimal from your perspective, but you're just going to have to swallow. So, so, I want deeply to make life as easy as possible for our clinicians. I think that, you know, some of it may have to be a lot of documentary workarounds at first, just because if we are going to be stitching together a number of solutions, it's not going to be a perfect streamlined beast out of the gate.

And so we're just going to have to sort of documents where those cracks are and. Commit to fixing it later. So the trick is to just not get sucked down into very many shiny rabbit holes, because as engineers, you know, we want to be as helpful as possible, and it's very easy to weight your colleagues and convenience very, very highly, because you want to make them happy.

And I still want to make them happy, but you just have to be cognizant with the time budget you're working with the risk budget you're working with and just every day focus on where you can impact you or most important values.

James: [00:15:14] Yeah, absolutely. And so you mentioned a little bit about the, about the team. tell me a sort of, is it, is it just you, or do you have a, you have other Folx you're working with or,

Ryan: [00:15:22] No, I'm an engineering. so we've got three people right now and, you know, it's probably going, gonna be about that size if not exactly that size for quite some time. so it's, you know, really myself. we, have a woman Jess, who is, basically the do everything. she, she's a deep background as a.

healthcare executive as well. you know, she's been at all zero and a number of other places. but she agreed to take a sort of hands on position with us, which I'm extremely grateful for. and then she's going to effectively be, you know, running the team into the future. but, she also has a deep product background as well.

So she's sort of playing both sides right now, doing both product and engineering. and then, there is Avery and, she is sort of our front end lead architects implementer. and so, she is sort of the aesthetic brain, and has a lot of deep experience and sort of passion for accessibility in front of technologies.

And, No, I think that's, that's, it's, it's a fantastic team. And, we are basically as small as you can get whilst still sort of effectively pushing things through where we need them to go. and we're going to be leaning, as I said, very heavily on, sort of third party products and integration to sort of make that dream.

Happen. and we've, we have a bench of technology, resources that we can sort of like tap beyond that sort of core team, but like, those are pretty much the stress.

James: [00:16:51] Cool. Cool. And, yeah, I guess other than, you know, you've sort of talked a little bit about the integration of the systems that you're pulling together and some of the new, exciting technology. Are there any other, any other challenges of, As I was poking our, our prospective audience a little bit for what kinds of things people might want to hear.

you know, you know, especially in engineering, crowd is not one to shy away from challenges. It's one that really leans into it. And so, yeah, anything that you're kind of wrestling with right now, I think could be, somebody might, sympathize with, or,

Ryan: [00:17:22] Yeah, I mean,

James: [00:17:23] came out of.

Ryan: [00:17:23] Yeah, especially, I mean, one of the things about the seed stage is that like, you know, it's a cliche that you do wear a ton of hats, but it is absolutely true and it's especially true on the technology end. So there are some things that, you know, I've been uniquely prepared for over the last few years to come in and be, you know, abandoned a box with.

So that's like get our compliance, regime started, pick our sort of HIPAA documentation platform. even like set up our MDM solutions. So the thing that's actually going to manage the laptops to make sure that they're in compliance. I, you know, we, we, I just audited like six or seven different antivirus solutions a couple of years ago.

So I know which one I wanted to go because our clients are, you know, again, HIPAA is gonna want to see that. So get that configured in the MDM and pushed out, get our IAC stuff sorted out. So there's like all of these things that. Just by virtue of the fact that like I had them already loaded into my brain.

I can sort of gloss past that. I think, Folx just kind of diving into this space might find a bit challenging so we can sort of expand on any one of those, but things that I find challenging or just. Things that other ones of your, our listeners might, you know, just roll their eyes out and just keep going because they've had themselves opposed to a lot more recently than I have.

So for example, things like even just helping pick a CRM solution. Right. Super important for what we want to do. I haven't worked with CRM in years, except like tangentially with Salesforce and stuff. So. what is the state of healthcare CRM? How do you even think about that? how would that integrate with the rest of our pieces?

How can I work with our marketing team to make sure that that thing is configured? Well, similar set of concerns for our CMS, just to add another similar acronym to the pile. Like how, you know, there's there community and blogging aspects of what we want to get underway. So, how are we, we're going to empower our team to, you know, be able to effectively use those platforms without being threaded through the engineering team.

So think about it. you know, things like, just e-commerce concerns, right? Like what are the series of eCommerce capabilities that we need to stitch together from either headless e-com solutions or elsewhere to just enable this. Do we want to work directly with Stripe? Do we want to delegate that elsewhere?

You know, there's, there's just a million concerns that the difficulty of them are just gated by like, just how familiar is this team with these pieces and what do we have to just resign ourselves to reading a lot of documentation, talking to vendors and talking to our network to really load up into our heads.

James: [00:19:51] Yeah. Yeah, that makes a lot of sense. And I'll, I'll add a space here in case you, don't want to answer this and we can chop it off. but, have you chosen and EHR or other type of backing, medical record, system of, of. T to use. And how has that process gone?

Ryan: [00:20:09] Yeah. So I'll speak vaguely about that. Just because like, we are in the midst of talking to a couple of vendors. I can very happily talk about the EHR space and, and, you know, because one of the more interesting saying things about getting a customer facing solution up and running, as opposed to, you know, more BNB where I've been for years, it's just like, There are probably let's say 10 or 11 different capabilities we need from like the unicorn platform.

And of course the unicorn platform doesn't exist. So there's some kind of Venn diagram that we're going to stitch together from EHR, from AAV to secure messaging. To, you know, maintenance workflows, like, Hey, you're on HRT therapy with us. We, that means that in a couple of months, we're gonna have to remind you to send this lab back in.

And if you need to wrap your medication, you've got to do it here. Like there is a ton of stuff that we need working that makes no sense to build, but that nobody offers all of, so EHR is, You know, they can offer pieces of that. Like, so for example, for the secure communication, and they typically have their own portal, often that portal is slightly skinnable, but not very, and as an eCommerce solution or at least that e-commerce want to be solution that like really wants to, demedicalize the experience of interacting with the healthcare provider.

That's not great. So, again, this is one of there's like compromise things where, you know, you may start out with the HR solution, but then you sort of want to pull that back into, something that you offer yourself or like you, you scan a third party product, and then you, you do API integrations to get that work.

there are some solutions out there that. Grew out of the telehealth space and have subsumed pieces of EHR into them. So they either can operate standalone or they can integrate with an existing EHR. and it's very hard to understand as like a vendor just getting off the ground. Like we are, You know, which of those make sense?

Like, is that integration really just a thing that's being offered so that they can sell into people with a preexisting EHR footprint? Or is it now you don't really want to use this because it only does like a 10th of what an actual EHR would do. so these are the kinds of questions we're sort of scraping at and then trying to tease apart.

you know, it's possible that the technology that we launched with, you know, today may not. Get us exactly where we want to be in a couple of years. And that's okay. Well, we met the plan. Yeah. Migration or two, but we're trying to be as forward-thinking as possible and picking something that we can gradually.

Hide from our members. even as we sort of, continue to build automation around to make our practitioners lives easier. but you know, a lot of HR is, are pretty old and creaky and don't play well with others. So you're bounded by API driven or at least API retrofitted EHR.

James: [00:23:05] Yeah. Yeah, absolutely. And on the one other thing I was really curious about from the telehealth space is operating sort of this, you've called it a bit of like an eCommerce type platform. Are there, are there specific regulatory components that are kind of. Getting into your way or causing impact to the user experience.

I'm thinking, is there anything like, inter-operating between different States or anything, any of those sorts of things that are, challenging right now?

Ryan: [00:23:34] Yeah, I guess, I guess I just assume that's the cost of doing business to some extent, especially coming from patient paying where, you know, you can have various overlapping yet distinct privacy laws from state to state. And to an extent we're. We're we're constrained by some of those. usually it just, it has to do with sort of licensure.

It has to do with which States allow, what kinds of interventions to be conducted over telehealth versus in person. All of that is overlayed by sort of temporary measures that have been taken because of COVID. So there are certain kinds of waivers for telehealth that have been issued, but there's threats.

In some cases, there may be temporary there's rumors that some of them may be made permanent. So, you know, as with so many sort of medical, startups, we are targeting the States that make the most sense, given our sort of go to market strategy and, you know, which clinicians, we want to work with.

at the beginning and then are planning to be a fully national solution, but sort of have to plan our sort of step wise function there carefully. especially given, you know, one of our first things that we're gonna be prescribing most likely is going to be testosterone, which is a controlled substance, you know?

So we, we, that, that is a particular regulatory thing that we just have to be sensitive with as it interacts with, different States regulatory structure.

James: [00:24:47] Yeah. And is that something that you're looking for the, I guess I'm just curious if you have to figure out some of those rule sets and,

Ryan: [00:24:55] Oh, sure.

James: [00:24:55] your own, or are they baked into the, these EHR solution?

Ryan: [00:24:59] I would definitely not. I mean, they help with it to some extent. So like a lot of HR is, you know, any major one has pretty good PDMP integration these days. So that's the database that says, like looks for things like drug seeking behavior in patients, if you're going to be prescribing them a controlled substance.

So that's something you need, if you're going to be prescribing that, it's great to have it integrated into the HR so that you don't have to log into that state's PDMP system separately. So. all of that's great. However, you really do have to understand the legal lands Cape like down. and because, you know, as with so many healthcare regulations, there is quite a bit that is individually interpretable by different attorneys.

So, you know, finding affirm that you really want to work with that has a really good sort of grounding and track record and background in this kind of law and is, offering you substantive and specific opinions is essential. No, there are a couple of times where I've reached out to our sort of HIPAA vendor and just be, you know, not as, you know, with regards to controlled substances, but you know, some questions around like, do you think doing X will be HIPAA compliance?

So, you know, if, if. Yeah. If you do medical marketing to somebody, but they're not currently a patient of yours, that's not governed by HIPAA because any information you get from that patient isn't yet auspices of a healthcare interaction. It's just between a vendor and a patient. However, There are differing opinions as to whether or not once that pay, that person becomes a patient, whether or not retroactively, the things that they submitted to you are then governed by HIPAA.

So, you know, usually it just makes sense to just treat everything as if it's radioactive, just so you don't get into these, these problems, but like, these are the sorts of landmines that are continually sort of lying around just because of the room for interpretation that lurks in a lot of these generally very old regulations that predate.

Any kind of eCommerce solution like this

James: [00:26:59] Yeah. Yeah, that makes a lot of sense. interesting. and. So you mentioned it a little bit earlier that maybe, maybe you're even thinking about planning for future migrations and kind of is how you, you know, I think many of us who've gone through this a few times, they've gone through, unplanned migrations, that have just come up by necessity.

and I, yeah, I guess, you know, kind of thinking about how you're thinking, you know, just, how are you thinking about, These planning for these migrations or, you know, what, where can you take shortcuts now? And it's fine. Versus that ends up being sort of the, the tech that you can never pay back or something like that.

Ryan: [00:27:38] sure. I mean,

James: [00:27:39] going a little deeper than that. Yeah.

Ryan: [00:27:40] Yeah. I mean, there are, there are generally a few bedrock principles that I think anybody that's been through, one of these has already internalized, which is that while you definitely need it single source of truth for any particular dataset, if that source of truth resides in a third party system, back it up locally and often, preferably in real time, just because, The one thing that you can't reconstruct later is data.

So one of the nice things about this kind of accompany, as opposed to an incredibly. Like high volume data play is that we're not going to generate that much data, which means that you can basically afford to do change data capture on everything. So there's no reason not to store everything safely in a compliant way in triplicate, in various formats.

So, you know, you want to have your analytics store, you want to have your audit trail. And ideally you've got your data sort of backed up in a format so that if you do desperately find yourself having to shove it in another system, which we all hope never happens. you've got it pretty much ready to go or with like a, a modicum of ETL, instead of having to invoke whatever triggers are in your contract with that vendor that compel them to produce some kind of extract and who knows a format that's going to be, or who knows what.

James: [00:29:03] Got it. Got it. Very cool. Very cool. well I think I have one last question, which is just for someone who may find themselves in a similar situation or, who's just getting started in, in the healthcare technology scene as a, you know, software engineer or, or, or product person. do you have any recommended resources or anything that you would want a one to point them to or advice you'd want to get them?

Ryan: [00:29:29] so, you know, obviously the advice differs depending on whether or not they're already an engineer, or if they're just looking to break into healthcare. I think, you know, for somebody who wants to make the jump from some other kinds of engineering to healthcare, you know, in a lot of ways you may be, It's not as different as you may think.

I think the one piece of reassurance that I would offer is that if I were contemplating a jump into healthcare today, the thing that would scare me the most is the heavy hand of HIPAA and all the sort of regulatory guidelines. I know that's dominated, you know, probably at least 30% of the conversation you and I have just had for all that.

It really doesn't. Hurt you as an individual developer most of the time, especially these days. I mean, used to be the case, like I would literally subscribe to the RSS feed and yeah, AWS that would tell me whenever they added a new HIPAA compliance service, because I was always so excited to get access to a new set of tools.

they've really come very, very far, almost everything is HIPAA compliant these days. it's still, you know, it's definitely, you still need to check the list. But, they're very aggressive about, bringing those things under the umbrella of the business associates agreements. So really, if you are an individual developer or just getting into healthcare, you can use almost any tools you want just as long as you do sort of due diligence and make sure that you, you know, hopefully somebody else is handling the security in your system.

you know, approves it. So. I wouldn't let that be too much of a hindrance. And I would say it's more than offset by how gratifying it is to work in the healthcare space. just because you know, it almost any the system, wherever you are in the healthcare. Yeah. A continuum you can point to individual patients whose lives you've impacted.

and if you don't get that feedback, definitely sort of ask your growth or customer service team to sort of share those because it's such an incredibly motivating thing as opposed to other. Technology sectors you can work with where there's a lot of personal gratification and solving problems and seeing your code run at scale, which, which, which is great.

I mean, that's, that's, that's a fun thing, but, it really doesn't have the same kind of reward structure as just being able to have a positive impact on people's lives. So definitely give it a shot if you're on the fence. you know, as to how to break into engineering in general, you know, I, I think these days, You know, this, this is sort of a commonplace on these kinds of interviews, but you've got it.

You've got it made at this point, just because like, there are so many amazing and readily Google-able tutorials that will walk you through every step of almost any process that you want to wrap your head around. Can't even from somebody who got into the technology, like in the late nineties who was fleeing from an English literature degree, because somebody told me that I wouldn't be able to make a living doing it.

Like. That was staying up till 2:00 AM, reading O'Reilly books cover to cover. And that's just not how things work anymore. Like, there are incredible, like. Things that companies lead with these days are how to tutorials and videos and, you know, just things that are essentially cookbook ways to structure your brain around these new concepts.

And, you know, it's a, it's a fun time to just, even if you're not even gonna use technologies, take a weekend out and wrap your head around something new. I mean, I still make time for that every couple of months, just to keep things different.

James: [00:32:44] Cool. And, if, if anybody from our audience wanted to, find you, how, what is it the best place to reach out to either you or the, the find people or Folx.

Ryan: [00:32:53] Yeah, I mean, for, for better and for worse, the easiest thing is probably just to find me on LinkedIn. so, our share our S C H a R E R. and 

I'm reasonably active. I respond to things pretty quickly and it is incredibly flattering to get, queries for advice or anything else people want to reach out for. 

James: [00:33:11] Awesome. Well, thank you so much for joining us and. For all the work that you're doing over at Folx, I'm excited to see what comes out of it. So we will talk to you soon, Ryan. Thank you.

Ryan: [00:33:22] you, James, for the opportunity.

Niko: Well there, you have it. The first episode of the redox shift, six developer podcast in the books. 

If you liked the podcast, or if you have feedback for us, shoot us an email. Hello. At redox engine.com. It'll find its way to me in James, where we will take that feedback and incorporate it into future episodes. , and of course, if you liked it, Definitely subscribe to the shift. Six podcast, wherever you get your podcasts, just search shift six, you should be able to find it. 

Yeah, we'll see you next time. Thanks for listening.