At Datavant, we invest heavily in growth and development for our employees. One way Datavanters can continue their growth journey is by taking on new roles through a transfer or internal mobility assignment.

Internal transfers have many benefits for the individual and the company. In terms of individual benefits, they allow you to:

Chart a career path around strengths and aspirations. Encouraging team members to be active participants in charting their own career path creates a culture where more employees are deciding what they want to work on (as opposed to a culture that limits employees to what is expected of them within their current role). We believe employees who work on things they want to work on are happier, more engaged, more creative, and ultimately more productive. (But don’t take our word for it. This belief is also supported by research.)

Build out a toolbox. Employees shouldn’t have to leave a company to advance their skills, knowledge, and abilities. If they like Datavant but don’t love their current role, they should have the opportunity to expand their skill set at Datavant.

Expand your value proposition. Datavanters who are agile, adaptable, and versatile are critical contributors to the organization and are also contributing to their own long-term career success. If there is one thing we are certain of in tech, it is that it will change. Agility, adaptability, and versatility are critical to everyone’s long range career trajectory.

Impact the organization. Internal moves are the best way for teams to cross-pollinate, share knowledge, and build relationships. Again: good for the individual, good for the organization.

In terms of ancillary benefits to the organization, most estimates put the real cost of replacing a valuable employee at anywhere from 1.5–4 times the cost of their annual salary.

How it works

Hypothetically, this all means that an engineer who wants to change pods can do so as long as:

1: The pod they want to move to has an open headcount

2: The manager of the pod they want to move to is excited to have them

We want Datavanters to act like owners and be respectful of their colleagues throughout this process, but there are no other rules beyond these two. (We do publish our full process internally for transparency.) The current manager of an employee cannot block a move because someone is “too valuable” to their current team. That’s not how the world works externally (if you receive an appealing offer at another company, your current manager cannot stop you from accepting it), so that shouldn’t be how it works internally. Also, people can have high value working on things that don’t necessarily align with their interests, but keeping people too long in these situations will almost guarantee that we lose them to another company. Better to lose a high-value employee to another team than lose them to a competitor.

There are several stories about Datavanter mobility on the blog. Check out stories from Sheena (IT to SysAdmin), Max (Data Ops to System Architecture), or Leon, Anjali, and Carlos, who at this point have done most things on the engineering team.

It’s also understood that the person being championed for a move is high-performing. Essentially, the new manager is making a job offer, similarly to how they would with an external candidate. The new manager needs to believe in the candidate and be excited for them to join their team. It would be exceedingly rare for someone not meeting expectations to move pods.

And we want moves to be timely. Typically a person would have been in their current role for two quarters before entertaining another move (which is not to say we’re encouraging people to move every two quarters), and the most respectful transfer timeline would be to move at the end of a quarter. This gives the manager of the previous team time to advertise the seat that is opening (both internally and, if necessary, externally), arrange backfill, and transfer knowledge during the handoff. It also means that if the conditions are right, the employee would never never have to wait longer than 13 weeks to begin their new role.

It’s not taboo to want to explore other options

In an ideal world, an engineer who wants to find a different role would engage in open dialogue with their current manager about their interests. Something like, “For XYZ reasons, I think changing pods would be good for me.” They could discuss. The manager could do some exploratory work and help direct them to the best pod, or figure out a way for them to take on a project that resembles the ultimate goal. Ultimately, the two managers would agree on the timeline for the move, set a start date, and inform HR for system updates.

Of course, it’s not always so straightforward. It can be difficult to talk with your manager about wanting to move. Telling your manager, “I want to change teams…” could be perceived as, “I want to move away from you.” As CTO, I’m always willing to have conversations with engineers about their current assignments and their career ambitions, and to work with engineers and managers to find the best arrangement for everyone on the team.

While the individual steps in a career journey may be highly personal to the engineer, they should not be personal to the engineering manager. Ultimately we want a team of engaged, creative people who are happy to work on their pod’s projects. And it’s important that we discuss the benefits of a mobility-oriented environment in order to normalize it.

Matt Vail is the Chief Technology Officer at Datavant. Before becoming CTO, Matt joined Datavant as a software engineer when the technology team was eight people. Matt led multiple teams at Datavant before becoming CTO in November 2023. Connect with Matt on Linkedin.

Nicholas DeMaison writes for Datavant, where he works on the Strategic Communications team. Connect with Nick via LinkedIn.

We’re hiring remotely across teams. Check out our open positions.

Talent Mobility at Datavant was originally published in Datavant Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Datavant is revolutionizing its approach to team dynamics within its Technology department by building a generative culture deeply embedded in every aspect of its operations. Generative cultures — those high in trust and collaboration and low in blame — have been shown to drive more shareholder value and foster happier, healthier teams. At Datavant, we achieve this by promoting autonomy at the individual level and removing barriers so that teams can innovate swiftly.

Datavant is committed to securing, making accessible, and utilizing the world’s health data. By focusing on fostering an inclusive culture, ensuring transparency, and empowering our team, Datavant aims to not only enhance our organizational health but also secure our long-term competitiveness and create enduring value.

A comprehensive study by Gallup found that highly engaged teams show 21% greater profitability, underscoring the link between employee engagement — a key aspect of generative cultures — and financial performance. Research published in the Harvard Business Review highlights how positive team cultures contribute to employee well-being, significantly reducing burnout rates and improving overall job satisfaction.

Core Elements of Datavant’s Generative Culture

• Psychological Safety and Risk-Taking: Datavant is cultivating a safe environment that encourages team members to take risks and learn from failures, thereby promoting an inclusive culture of inquiry and growth. For instance, engineers are encouraged to identify gaps and present them as investment opportunities. This often leads to the formation of new pods tasked with addressing these gaps or even the establishment of new organizational OKRs.
• Alignment and Transparency: Every team at Datavant operates with a clear understanding of their objectives and their contributions to the broader success of the company. The decision-making process is transparent, fostering a high level of alignment across the organization. Consequently, pods independently create and own their OKRs and revisit them quarterly to ensure they are delivering maximum value to the business.
• Empowerment and Autonomy: Individuals and teams at Datavant have the freedom to select their projects and approaches, fostering a strong sense of ownership and responsibility for the organization’s success. We facilitate this by encouraging engineers to identify gaps and then utilizing our internal mobility process to match the best engineers with the most challenging problems.
• Remote-First Communication: Datavant prioritizes asynchronous communication to support a flexible and inclusive work environment that accommodates different continents and time zones. While virtual meetings foster community, we also depend on engineers to write concise papers that document ideas, process changes, and technological solutions. These papers are openly shared across the Technology organization, reinforcing our belief that our best ideas are built together.

How We’re Making Our Generative Culture a Reality

At Datavant, we’re committed to deliberately nurturing our culture through the following strategies:

• Clear Growth Paths: We implement a rigorous performance management process that clearly outlines expectations at all levels and defines growth trajectories. Managers and employees meet multiple times a year to review these paths.
• End-to-End Ownership: We empower our teams with complete ownership of their products, fostering a sense of responsibility and initiative.
• Continuous Learning: Datavant is dedicated to the continuous personal and professional development of our team members. We provide access to the latest technologies, learning paths, and tools. Managers actively facilitate rapid growth by exposing individuals to new initiatives, tasks, and teams.
• Enhanced Communication: We maintain open communication channels and conduct blameless retrospectives to learn collaboratively, ensuring safety and transparency in all our activities.
• Measuring our success: We view every Datavanter as an owner of the company, deeply invested in Datavant’s success. Our open policy on sharing team charters, roadmaps, and OKR achievements ensures clarity and transparency. We believe that understanding these elements and tracking our progress against them enhances a sense of belonging and collective achievement.

Conclusion

At Datavant, our commitment to cultivating a generative culture is a core component of our strategy and a defining aspect of our identity. By integrating trust, collaboration, and empowerment into our operations, we’re not only advancing technological innovation but also enhancing our organizational health. The positive effects on team engagement and financial performance are clear, affirming the global research that links a thriving workplace culture with increased profitability and employee well-being. As we move forward, Datavant remains dedicated to creating an environment where every team member is empowered to contribute to our mission of harnessing the world’s health data. This approach not only shapes the future of Datavant, but also establishes a new standard of excellence across the tech industry.

By Angie Zhou

About the author

Angie Zhou has a background in leadership development and is currently a Talent Acquisition Manager at Datavant. Connect with Angie via LinkedIn.

We’re hiring remotely across teams. Check out our open positions.

Generative Culture at Datavant was originally published in Datavant Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sheena Allana joined the IT Support Team as a contractor in February 2022, and transitioned to a full-time role in September 2022. We spoke with Sheena about her journey into the health-tech space and her approach to IT Support. Looking to get out of your comfort zone and join a team of smart, nice people who get things done? Check out our open positions.

Tell us how you found your way to Datavant.

I learned about Datavant from the former Head of IT, and initially joined as a contractor to help with the ticket queue and offload work from more senior members of the IT team. I had intended to stay a contractor for a while, but after working a few months in that role, decided to apply for a full time position. This was a big decision because I was working in a completely different industry (broadcast production!) at the time. I was nervous, as anyone would be when considering a full career switch, but I don’t regret it and would make the same choice again without hesitation.

What about working at Datavant compelled you to make the leap to full-time?

Lots of things: Growth opportunities, working remotely, fair pay, kind coworkers, and a friendly culture. I particularly liked the culture in the IT, Security, and Compliance teams.

What kind of growth opportunities have you had since joining the team?

Soon after I transitioned to full time, we were looking to hire additional IT support. I wanted to learn more about management processes, so Chris Watson gave me the opportunity to help hire for an open role.

I helped rewrite a new presentation prompt for candidates that better mirrored a typical work day. This helped us better evaluate the candidate’s knowledge, decision-making, and critical thinking skills, and also helped us reduce our hiring pipeline to a one-month turnaround from the role opening to the employee start date. I was also involved in getting approvals from the People team, screening resumes, and I joined the first round of interviews — all things outside of normal IT duties. It was kind of like a very hands-on version of hiring manager training.

Being involved in the interview process was very important to me. As a woman in tech, I have sometimes come across people who want to undermine you just because you’re a woman. If I was going to be in the position of onboarding and training our new hire, I wanted to know that the person we were hiring would be eager and excited to learn from me.

Being very direct and very personal in communication helps build trust and makes people feel more comfortable asking for help next time.

You also mentioned the culture of the IT team. What’s that like?

The teams genuinely care for each other, and do their best to help each other and work collaboratively towards solutions to complicated problems. They embrace a culture of teaching, learning, and regular check-ins. We’re encouraged to take on projects beyond the scope of our specific role…and we’re rewarded for it.

I consider it imperative that folks should feel happy and fulfilled. Responding to IT requests can be tough sometimes, but it doesn’t mean we have to feel overwhelmed. We try our best to help each other out and keep things light and a bit silly. For example, I have a personal stake in expanding the palette of emojis available in the company Slack. We currently have over 1600!

Do you have an MVP emoji?

Definitely ThumbsUpCat. I use it to acknowledge IT requests:

I’d also like to point out that not long after I introduced CatKool into Slack, it landed in a company-wide Town Hall presentation:

And some time ago I started using a picture of my cat as my Slack profile pic:

I’ve kept it up because, let’s be honest, it’s a bit comedic when you’re asking a serious question and receive a serious response from that face. It caught on and now most of our IT Support folks use a picture of their pet as their profile pic.

Why so many cats?

IT Support has the potential to feel like it’s far removed from the other teams in the company, and often people interact with us because something isn’t working. It’s really important to me to set a tone that’s both candid and friendly in this environment. People have a lot on their plate, and they often don’t know where to go for a specific request, or don’t know some of the complications involved in a specific request. Being very direct and very personal in communication, like using my cat as a profile pic, or starting an email with “Happy Wednesday. Here’s a thing…” helps build trust and makes people feel more comfortable asking for help next time.

This extends to our channels for interaction as well. When I started, we only supported requests that came through email, but I set up a Slack channel for IT requests and now this has become the more popular channel for making requests. Slack requests are super helpful because they allow us to quickly loop in the appropriate parties that need to review or approve the request. It feels like a less formal process than email does, but is just as efficient because it triggers our ticketing system the same way an email would.

I’m proud of how much we prioritize growth. We set high standards for ourselves.

If you could reveal an invisible aspect of your job, what would it be?

The people on the IT team aren’t just there to support onboarding and troubleshoot issues, they also have to be compliance officers. We are the ones who uphold the rules Compliance has set up. How to dispose of a laptop, for example, is both an IT problem and a compliance problem.

We keep a very bottom-up culture where individual contributors can lead projects and processes, and also suggest changes to those processes. Due to the type of work we do, we often have to put our heads together to make a decision before moving forward in order to ensure any changes we make are compliant and maintain the security of our tech stack. There is a lot of collaboration involved both within our team and with other teams. Everyone is happy to provide input, so we can feel confident that we’re making the best choices.

And what would you want somebody thinking about applying to Datavant to know?

I’m proud of how much we prioritize growth. We set high standards for ourselves. As a company, we’re always working to improve our systems for training and mentorship. I want to help ensure that employees from all backgrounds have equal opportunity towards growth.

Sheena Allana has a background in Computer Science, Engineering and broadcast production. She is an IT Support and SysAdmin at Datavant. Connect with Sheena via Linkedin.

Nicholas DeMaison writes for Datavant, where he works on the Strategic Communications team and leads talent branding initiatives. Connect with Nick via LinkedIn.

We’re hiring remotely across teams. Check out our open positions.

Sheena Allana: From Broadcast Production to IT Contractor to ITSupport and SysAdmin was originally published in Datavant Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the nascent stage of a new company, the goals of a young Engineering Team are simply to ship new products (fast) and to iterate in a way that continues to meet customers’ needs. The team is small, can maintain continuous conversation within itself and with other company leaders, can divide responsibilities, and can organize according to whatever structures and habits best facilitate the work.

As the Engineering Team grows with the company, responsibilities divide and sub-teams form. In our case, we call these sub-teams “Pods.” Each Pod is relatively autonomous and develops its own working culture and habits, and can more or less continue to act like its own nascent Engineering Team. The Pod works in the way that it needs to work in order to ship the product it owns.

At some point along the way, there are enough people in enough Pods that an “Engineering Group” emerges. Over the course of several years of working together, individuals adapt to each others’ working preferences and efficiencies, and Pod cultures start to become more fixed.

Fixed cultures can be good: they can be a sign that Pods have found the most efficient way to work together to generate value for customers. Fixed cultures can also present challenges.

There is a risk that innovation can stagnate due to lack of cross-pollination, Pod cultures can come to stand at odds with the culture of the entire Engineering Group, and of course, working on the same types of projects for too long can contribute to burnout. Finally, if Pod ownership lanes become too rigid, things invariably come up that seem to fall in between well-defined lanes.

Or, think of it like a physical factory. If everybody in the Eng Group is dedicated to building and shipping products, whose job is it to keep the factory running, to address internal proposals, build new tools, expand current tools, and in general provide the support necessary to improve engineer quality of life?

Before you respond with, “It’s the job of the DevOps Pod!”* let’s consider a few things…

*For non-technical readers, DevOps is a cultural movement that’s centered around expanding the developer’s view of the software lifecycle beyond just writing code. Expanding that understanding to span from design to implementation to building to deploying to operational concerns to observability is what closes the feedback loop between what developers write and how that delivers value, which in turn gives developers the agency they need to become more effective in improving the systems around them.

First, we care a lot about individual career growth and the options available to our engineers.

We want to build into our structure the potential for fluidity in an individual career journey. It is often true at Datavant that people who become an Engineering Manager move back to an Individual Contributor role. We try to think about the engineering career journey not as a single ladder, but as many possible staircases.

Second, like any other Pod, the DevOps Pod also has to prioritize its work, often selecting for the broadest impact.

If a problem sits somewhere in between “I can add this time-saving internal feature in an hour during the course of developing a feature for a customer,” and “This is a problem the entire Eng Group is dealing with regularly,” it’s very possible that this problem will persist and become “just the way things are.”

An added consideration is that many of these kinds of problems don’t show an immediate result for having been solved. If solving one of these thorny in-between problems created immediate value, it would be rolled into shipping a feature for a customer. In efficiency-oriented environments, it can be a big mental hurdle to decide to take the time to tackle problems with long-tail results when there are literally dozens of immediate-impact problems to solve.

For example: CI/CD Performance

When we push code, it goes through a peer review process. During the peer review process, we run tests on the code to determine changes that need to be made. After that is an approval process and a subsequent process for deploying the code to various environments. Once deployed, it gets checked again. This entire cycle is known as the Continuous Integration / Continuous Delivery (CI/CD) performance cycle.

Imagine making one feature that accelerated this feedback loop, like building a better local Python virtual environment. This is precisely one of those “in between” issues that’s not part of building a feature for a customer, but may not ever rise to “high priority level” for a DevOps Pod.

We could address this problem in a few ways:

• Give it to the DevOps Pod anyway!!
  This resolves the “between lanes” problem, but as mentioned, has the potential to become a second or third-tier priority on that Pod’s to-do list. Continuing to drop problems like this on the DevOps Pod also does little to break down (and in fact potentially reinforces) any mental separations or informal boundaries that may exist between Pods.
• Have a Pod pause their customer-facing work to work on it.
  This could be a refreshing change of pace for that Pod, unless they don’t actually want to work on this problem, in which case it becomes an onerous and potentially demoralizing assignment. It is also potentially highly problematic for customers (and therefor for the business) if a Pod that is usually focused on shipping customer features simply…stops.
• Create a “guild” or “working group.”
  This would allow people from various Pods to decide to come together to solve these between-lane problems. But how do we determine how to distribute the split time for individuals contributing to their Pod and individuals contributing to their “guild”? Also, how do we establish “guild accountability”?

Enter the “Dev Productivity Pod”

Unlike the rest of our Pods, the Dev Productivity Pod is an opt-in Pod and rotational by design. Engineers step out of their usual Pod, work on an engineer-life-improving project (without splitting their focus) for a limited period of time, then return to their regular Pod (or interview for a new Pod assignment!) Some advantages offered by this structure are:

• Engineers without previous leadership experience can take on a Tech Lead role.
• Engineers can work on projects outside of their usual focus area and develop new skills to take back to their regular Pod.
• The rotational structure democratizes the focus of the Pod. Instead of having a top-down dictation of project priorities, engineers who see an opportunity to make an improvement can make it happen.
• Engineers who don’t usually work together get a chance to work together, potentially in a completely different work formation, which in the long run significantly increases the potential for cultural and technical cross-pollination.
• Pod Managers are compelled to adopt a longer horizon line and think about things like succession planning on projects as they might be rotating individuals on and off of projects every quarter.
• It offers a potential “ramp-up” space for new grads to acclimate to Datavant culture and learn the business from the inside.
• It improves our overall onboarding habits by creating a “desirable churn” between Pods.
• It offers a chance for veteran Datavanters to take on a new “Day 1 Project”.
• It can be a tool to combat burnout.
• The entire Engineering Group begins to regard themselves as their own customers.

The importance of this last item cannot be overstated. One of Datavant’s core values is that we are “Customer Obsessed.” That’s a great value for any business to have, but how do we accomplish it? How does it play out in real life? One way to be “customer obsessed” could be to engage in obsessive finger pointing when something goes wrong for a customer (as things do!) But if we turn the mirror back on ourselves and see our own team as our customers, then the narrative begins to shift from, “Why hasn’t your team fixed this?” to, “I want to help fix this.”

Thinking about serving the needs of our own team cultivates empathy. It destroys “entrenched-lane thinking.” It builds a team-cohesion that can easily get lost if we only ever work in product-optimized formations.

As an Engineering Group, it’s critical that we align on a north star while also understanding the boundaries of ownership along our path towards that north star. A set of values are a great starting point for creating this alignment, and can even act as tie breakers in moments of difficult decision making, but a set of values stops being useful the moment it starts to degrade into a set of thought-eliminating cliches. We see the DevProductivity Pod as just one out-of-the-box interpretation of one of our Core Values that also makes life better on the inside.

By Dave Chen and Nicholas DeMaison.

About the authors

Dave Chen joined Datavant as an Engineering Manager in February 2023, and is currently Manager of the Pipelines Pod. Connect with Dave via LinkedIn.

Nicholas DeMaison writes for Datavant, where he works on the Strategic Communications team and leads talent branding initiatives. Connect with Nick via LinkedIn.

We’re hiring remotely across teams. Check out our open positions.

Cultivating Developer Productivity (and happiness) at Datavant was originally published in Datavant Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Guiding a partnership strategy on Day 1

New Datavanters are given Day 1 Projects as a way to accelerate their forward motion in their new role. Lauren Hisiger joined Datavant as a Product Manager in January 2023. We spoke with Lauren about her Day 1 Project: steering Datavant’s first Big Tech integration, a partnership with AWS to integrate Datavant’s de-identification technologies to accelerate adoption of the new AWS Clean Room offering. Want to work somewhere that offers meaningful charters from the moment you join? Check out our open positions.

Datavant recently announced a new partnership with AWS bringing together Datavant’s de-identification technology with the new AWS Clean Rooms. This is a major partnership undertaking; driving it forward was your Day 1 Project. Tell us about the experience of taking on such a significant charter the moment you joined.

I typically like having a foundation on a topic before starting to engage in conversations about it, but in this case I joined Datavant on Jan. 17 and was in meetings with cloud providers one week later. Our Emerging Business team did an incredible job paving the way for this partnership, so everyone involved was very eager to get things moving. I was simultaneously building my foundation with the technology, with the business, and with the product and its capabilities while having conversations with potential partners who wanted to draft press releases about it yesterday.

Also, my new manager joined Datavant a week before I did, so we were essentially onboarding together. The last product I owned at my previous job was internal only, so I was balancing learning a new product and learning a new company while working with 3rd parties. To get up to speed together, my manager and I kept a heavy schedule of one-on-one meetings in the beginning, and rather than discuss getting-oriented-to-the-company topics, we focused heavily on how we were going to approach the integration project. Sometimes these meetings were totally overwhelming, and sometimes they would be votes of encouragement — a pretty regular oscillation of confusion and confidence.

Did you come to Datavant with experience in cloud computing?

Prior to joining Datavant, I was a Product Manager for Bioinformatics data pipelines which heavily leveraged various cloud products. One of my projects was to manage a cloud migration from AWS to GCP, so I had a foundation with multiple cloud providers, various products within those clouds, and what it means for a business to be multi-cloud, but this was a different level of ramping up.

Why did we decide to partner with AWS?

AWS is the largest cloud provider by market share:

In my final interview with Bob Borek (now GM of our Provider business) before joining Datavant, Bob opened with: “How would you approach integrating Datavant with a major cloud provider?” It was 6pm Eastern Time on a Friday and I felt like I rambled my way to an answer, not fully realizing that he was probing me to figure out if I could manage being thrown into the deep end on my first project. Eventually I offered a venn diagram that looked something like this:

Basically, this effort isn’t going to succeed if we try to bring our customers to a specific cloud provider — but we can bring our technology to the cloud provider and make it available to their customers. Part of our goal in building a partnership, then, was to work with the cloud provider with the most customers.

A Clean Room isn’t a physical space. You can think of it as a logical boundary.

Tell us more about the project itself. What’s a “Clean Room”?

Clean Rooms are a hot trend in the data collaboration space right now.

First, it’s important to understand that many organizations store their data in the cloud, not locally on premise. “Clean Rooms” are a product AWS has built to enable multiple users to collaborate on data analysis between datasets already hosted on the AWS cloud without having to share their underlying raw data.

A Clean Room isn’t a physical space. You can think of it as a logical boundary. Each party can control what aspects of their data are visible and how the data can be used (i.e., what functions are permitted on each column of data). It’s somewhat analogous to read-only access in G-Suite — it’s a sophisticated level of permissioning on data.

Why is this important in the health data space?

Healthcare data is very highly regulated and protecting patient privacy is critical. We’ve found that some customers are understandably hesitant to share their data externally, given that when you move any data, it increases risk for leakage or misuse. We often see linking strategies out there that are at odds with the privacy mechanisms a data holder might have in place, so being able to connect data without sharing all of it is very useful.

A Clean Room reduces the privacy risk involved in linking data because the data doesn’t have to travel out of the customer’s cloud space in order to be linked to other datasets. This facilitates customers working with Datavant and AWS on projects involving multiple external partners. But we should note that Clean Rooms are not a HIPAA compliant service, they are HIPAA eligible. There is a shared responsibility between Datavant, AWS, and our customers to determine that specific usages are HIPAA compliant.

It felt a little crazy that I’d only been here for 3 months and I was strategizing about up-leveling our token process.

How does Datavant’s technology fit into the Clean Room environment?

That was one of our main questions, actually. What’s the best scenario for our customers, for security, and for our technology? We discovered that we had to build a new type of link to work inside the Clean Room. We currently have a 2-step transformation process, but data isn’t shared in the Clean Room, so it doesn’t go through a 2-step transformation process. So then what does it mean to get data into a space where you can use the token to link data from different providers?

These are really big questions, and at one point I was discussing this with Datavant’s Chief of Staff, Mark Ungerer, and mentioned that it felt a little crazy that I’d only been here for 3 months and I was strategizing about up-leveling our token process. His response was something like, “You’re not insane — this is hard, and you’re getting it fast and figuring out how to shape the future of the system.” This felt like a turning point for me in my ability to lead within the project.

At a critical moment in developing the partnership with AWS, we organized an in-person session in March (…around 2 months after I joined…) with lots of key players. There was incredible excitement on both sides. Sales teams love to sell the room, but product teams need to be the adult voice in the room about what’s actually possible, so we spent a lot of time brainstorming what the partnership could look like, worked through from problem identification to use cases to product development to imagining buyers vs. users. It was a very inspiring day during which a lot of preliminary work seemed to come together.

What was one of the major questions you focused on in these sessions?

Every software developer will tell you how they struggle to get customers to install updated versions of their applications. One of our biggest questions was simply, “Will customers adopt a brand new technology?” That is, will customers recognize the difference between what we’re offering here and the current product they use? But it turned out that several customers wanted to be beta testers. That’s exciting, because it means we’re not just taking this on because we think it will work.

Being in product gave me a seat at the table.

Tell us a bit about your background. How did you get into Product Management?

I started in analytics but didn’t love being a data analyst. I discovered I liked being in product because it allowed me to leverage my analysis skills — not just look at data, but also offer solutions based on it. Being in product gave me a seat at the table that I didn’t have in analytics to help set a direction.

In my previous position, I became super familiar with that company’s products, but my role wasn’t very technically oriented. Datavant balances these things well for me: I work closely with an engineering team on a technical product while also taking on a broader product management scope. I like having an external-facing role, owning things end-to-end, working cross functionally and thinking strategically, while also staying grounded in the technology.

Have you picked up any crucial insights in your first few months at Datavant?

There are some pieces of domain-specific knowledge that may not appear significant, but are actually critical to your success. For example, you can easily search the internet for data storage costs with different cloud providers, but having this information at your fingertips is huge when you’re in conversations with customers. And along those lines, it’s important to know when you need to know things and when the best answer is to say that you don’t know something and will figure it out.

If you’re not ready to get thrown into the deep end, this may not be the right place for you.

What would you want somebody thinking about applying here to know?

If you’re not ready to get thrown into the deep end, this may not be the right place for you. But Datavant was very transparent about what I would be getting into: I knew there wouldn’t be a nice warm period of ramping up to bigger and bigger challenges. Of course, there is a big difference between knowing the path and walking the path!

About the authors

Lauren Hisiger has a background in Economics and Data Analysis and is a Product Manager with Datavant’s Apps Pod. Connect with Lauren on LinkedIn.

Nicholas DeMaison writes for Datavant where he leads talent branding initiatives. Connect with Nick on LinkedIn.

We’re hiring remotely across teams and love to speak with potential Datavanters who are eager to shape the future of health data exchange starting on Day 1!

Lauren Hisiger discussers her Day 1 project at DatavantLauren Hisiger: Building Datavant’s… was originally published in Datavant Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the first two articles in this series, I discussed managing interview processes and unpacked my experience with Datavant’s virtual onsite interview. Here, I’m going to put a microscope on my first week at Datavant and discuss a bit of my Day 1 Project.

Want to join us? We’re hiring.

But first, “Day 0”

New Datavanters officially start on Tuesdays. I knew about Datavant’s “Day 1 Projects” from early conversations with my new manager, so I expected my first day to be an explosion of “Day 1 intensity.” Even though we want new Datavanters to hit the ground running, your actual first Tuesday isn’t really “Day 1,” it’s more like a “Day 0” — the day to get oriented, get access everywhere you need it, set up your platforms, put up internal profiles, and have a 1:1 with your manager. Obviously you can’t start working on a project without access, but this easing-in nevertheless caught me somewhat off-guard. I kept wondering, “But where’s all the work??” This designed “admin day” is Datavant’s way of setting folks up for success on “the work” as quickly as possible by avoiding as much access-stumbling as possible once into a project.

Datavant is intensely committed to internal transparency. “Access” doesn’t just mean access to your specific corner of Github and your specific team’s working drive. Salaried employees with shared drive access can comb through financial reports, org charts, vision docs, Board presentations, product demos, and retrospectives diagnosing issues and responses. And because we are an async-first culture, it’s also possible, in many cases, to follow archived discussions through the comment threads within these documents:

When you join a new company, it can be difficult to understand how macro priorities relate to your personal mandate. The “process archive” held in doc comment threads is incredibly valuable for orienting to different perspectives, layers of priorities, and what many different teams are working on. Once I had access everywhere I needed it, I took delight during my first week in simply exploring (and having the time to explore) this vast archive.

Moving into a health tech company from a fin tech company, I also had to get up to speed on healthcare-specific jargon. Who is a “payor”? What’s an “HIS”? “FHIR”? I did some preliminary research, but the healthcare industry is incredibly vast and the jargon expansive. My shared drive exploration also helped pinpoint key jargon areas to focus on.

Onboarding Buddies and personal connection

Lots of people wonder how easy it is to create personal connections in a remote-first workplace. Onboarding buddies are more than just a point person to help you learn your new job. Many people around the Engineering group took time to help me ramp up quickly on things like our precision and recall metrics in Match, the areas our data scientists focus on, and issues in our security posture. Ideally, the Onboarding Buddy (who is often from a different team) goes a step further, making themselves available for all of the “other” questions (eg. “What does personal growth really mean at Datavant?”), and passing on local knowledge (highlighting relevant Slack channels and mailing lists). In my case, my onboarding buddy had managed one of our core products (Switchboard) and in a very Datavant-y twist after deciding to become an individual contributor again, actually moved onto my team when I became a manager.

Co-working Days and offsites are another major opportunity for personal connection. I can only speak from my experience living in New York City, but I can say that New York-based Datavanters organize Co-working Days as often as once a week. The Engineering team holds several offsites each year, alternating gatherings of the full team with gatherings of pods or sub-teams. Therefore, it is highly likely that new hires will have an offsite within the first three or four months of being hired. My first offsite happened to fall two weeks into my tenure at Datavant, which was amazing timing for hitting the ground running with personal connections.

#RealDay1

Part of Datavant’s unique culture is our “more responsibility, fewer rules” approach. To instill this mindset right from the outset, Datavanters are given significant Day 1 Projects as soon as they join. You can find snapshots of Day 1 Projects peppered around Datavant’s online world: Anjali built out a “Configurator;” Aleah and Isa helped stand up the COVID-19 Research Database; Nick put together the Tech Blog you’re reading now.

My first project was to set up a model inference Python service in lieu of the in-process Java implementations that historically demanded manual translation from the Python code the modelers (data scientists) wrote to Java. This project decoupled the models from Java so that no translation would be needed, which had the added benefit of being able to update the models dynamically and seamlessly.

After the initial design and some work on it, I became a manager for the De-identified Match Pod so there was less time to code directly on the project, but I wanted to offer opportunities for the team to get more involved in it for their own growth. The team was still working on the project by the time I moved on to my next stage at Datavant, so “my first project” became my first team’s project.

NHOs

I’ve been at companies where you spend your first couple weeks entirely in new hire orientations. Datavant’s new hire orientations are structured so as to give you the time you need to get into your Day 1 Project. They unfold gradually over the course of the first month, and range in topics from HIPAA Certification (which I knew about but couldn’t appreciate fully until I was actually working with our data) to overviews of the company vision, core products, and the ecosystem in which we operate. The fact that I was actively working on my team while doing the NHOs made it much easier to connect the dots on what I was learning, as I could directly apply what I learned in the NHOs to my work and vision for the team’s product.

Searching for weak links

In my discussion of the Datavant Onsite interview, I mentioned looking for red flags and weak links — any sign that the actual culture inside the company did not live up to the way it was being described. I continued my probing even after officially joining. I requested meetings with every leader whose name came up repeatedly in conversations. Everybody met with me and took my questions seriously. I dropped a ridiculously lengthy question about the philosophical and business implications of our “neutral & ubiquitous” stance in the CEO’s #AskMeAnything Slack channel. He responded with an impressively articulate response about how he understands both “neutral” and “ubiquitous” and how he sees these ideas playing out in day-to-day operations.

Travis has since shifted from his position as CEO to Board President, but Pete McCabe continues the practice of an #AskMeAnything channel, offering both weekly roundups and responses to Datavanter questions:

“If you are growing fast, you have a different company every 6–12 months.”

Elad Gil made this observation about Google and Twitter, but it is equally true for Datavant. Almost 300 salaried employees have joined Datavant since I started less than a year ago. The merged entities of Datavant and Ciox have taken several major steps toward one unified org structure, meaning that the full Datavant workforce is close to 10,000 people. We’ve had several reorganizations as a result. Engineers have become managers. Managers have returned to IC roles. And we continue to look for the best structures to offer the best opportunities for product development. People are still eager to cultivate personal connection, but that feeling of “I know who everybody is and what they do” is admittedly less accessible than when the company was smaller. This is an invariable tradeoff as a company grows, but what continues to impress me is the broad commitment to the “smart, nice, get things done” culture that I observe even as we scale.

Still true

Almost a year into my Datavant journey, I stand by the assertions I made in my very first Datavant Tech Blog post: the intentionality behind this culture continues to amaze me, and I continue to want to build this culture. As Datavant transitions into the next version of itself, I couldn’t be more excited to help drive our future. Does this sound interesting? Check out our open roles and be in touch.

By Carlos Guzman and Nicholas DeMaison with input from Alicia Loewenthal.

About the authors

Carlos Guzman started as an IC Engineer at Datavant in May 2022, became an Engineering Manager in July 2022, had a stint as Engineering Chief of Staff and is now Engineering Head of Identified Switchboard. Read more about his journey here, and connect with Carlos via LinkedIn.

Nicholas DeMaison writes for Datavant, where he leads talent branding initiatives. Connect with Nick via LinkedIn.

We’re hiring remotely across teams. Check out our open positions.

Unlocking the Datavant Engineering Interview Process: Part 3 was originally published in Datavant Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Referential data as a source of truth

Datavant recently announced the incorporation of referential data into Datavant Match, an end-to-end, research-grade privacy technology designed to open new use cases within deidentified record matching. Here, we will explore how referential data sets contribute to this new standard for precision and recall in patient matching.

Referential data is exactly what it sounds like: a large body of data to which we can refer in the process of matching, a bridge between otherwise disjointed datasets. Referring to this data allows us to match with very high confidence medical records belonging to a single individual but containing different pieces of personally identifying information (PII). This means that records that would otherwise be difficult or impossible to match using other techniques can successfully be matched. In this respect, referential data acts as a source of truth for our machine learning models.

Datavant’s referential data source of truth is a curated dataset of public records, online data, and proprietary sources assembled with rigorous data hygiene practices covering the entire US population across 30 years. The scope of this data allows us to track changes in personal identifiers for individuals across time, allowing us to make more matches with higher accuracy.

You vs. your data

Despite how fixed you may feel your own identity to be, your personally identifying data is actually a series of isolated snapshots of interactions with the healthcare system. Observed at scale, the PII of a population appears messy and in constant flux. How many addresses have you had? Phone numbers? Ever changed your name? Do you sometimes (but not always) use a nickname or shortening of your name? All of these changes make it more difficult to say with certainty that data in Location A and data in Location B should both be attached to you.

Real world data

To those outside of the healthcare industry, “real world data” may sound like a fixed body of information, but it is neither fixed, nor is it a single, uniform body of data waiting to be opened for exploration. A large variety of players within the healthcare ecosystem hold small slices of the real world data pie. Within several slices is the personal identifying information of any one patient as it was recorded at a specific moment in time, along with some (but likely not all) information about a patient’s health history. Our goal is to connect the latter without exposing the former. This is one of the ways we are working to break down the many data silos across the healthcare ecosystem.

There is enormous value in being able to study real world data, from accelerating pharmaceutical research to monitoring a complete patient journey. But there is little value in trying to study segmented bits of data that we cannot meaningfully connect. With Datavant Match, we can locate individuals’ records across fragmented datasets and know with very high certainty that a set of records belongs to a single patient without compromising patient privacy.

Connecting patient records across data silos

How PII is stored, shared, and linked is regulated by HIPAA. Unlike, for example, a social media platform that can link the identifying data of its users to other platforms and datasets relatively freely (think: targeted ads based on search activity or social posts), our platform must connect data freely enough to be useful across the industry (i.e. to a variety of researchers, healthcare providers, insurance companies, etc.), but also continue to protect the identifying information of patients.

Elsewhere in the Datavant Tech Blog, we’ve discussed some of Datavant’s strategies for connecting the dots of patient data across fragmented datasets, including Datavant’s tokenization, and some approaches for estimating record overlap between datasets. Both of these approaches are part of the larger puzzle that make up our comprehensive matching strategy.

Tokens

Tokens are the first step in how we match patient data while keeping PII secure. A token is an irreversibly hashed and encrypted string based on certain PII elements. Tokens allow for secure storage and exchange of data outside the data owner’s data warehouse. In the case of a security breach with one data owner, the PII contained in other linked datasets remains protected.

A token could be generated off of:

or

For every dataset, we generate many tokens through different combinations of PII. At a basic level, we can make pairwise comparisons between records to determine if they match. We then measure performance by accuracy on pairs of records:

• TP = True positive = correctly predicted match
• FP = False positive = incorrectly predicted match
• FN = False negative = incorrectly predicted non-match

The key metrics we look for are precision and recall.

• Precision = TP/(TP+FP)
• Recall = TP/(TP+FN)

For example:

Record 2 is missing information in the Phone # field and because of that we’re also missing a token that uses Phone # in its definition. Here, 2 token pairings match, 1 token pairing does not, and 1 token pairing is unknowable. There is an upper limit to how certain we can be that these two records match based on comparing these tokens. Better quality tokens would offer more certainty.

Street vs. St.

When you perform Captcha tasks to access websites, you are helping to develop an AI somewhere to perform better at recognizing things humans recognize instantly regardless of the angle at which they are viewed, their relative positioning to other objects, or the way sunlight glances off of them. Similarly, humans recognize common abbreviations of words as equivalent to the word they abbreviate, but a matching algorithm must learn to recognize “Street” and “St.” as equivalent. At the machine learning level, there are many such factors that confound accurate matching, including:

• Formatting inconsistencies: “Main St.” vs. “Main Street” or “1/12/04” vs. “01–12–2004”
• Variations in data content: “Mary” vs. “Maryanne” vs. “M.”
• Changes to identifying data that occur when patients move, marry, divorce, etc.
• Missing data: absence of phone numbers or first names, or any other field of information not deemed relevant at the time of a particular interaction with the healthcare system
• Filler data: using “123–45–6789” in place of a real SSN or “11/22/3333” in place of a DOB

Bad data = bad tokens

Data quality is critical for quality matching. If the above issues are not addressed, then we have large silos full of bad data. But Datavant is not analyzing the original dataset for inconsistencies, missing data, or the presence of filler data; we only analyze the tokenized version of the dataset. Therefore, tokens must be optimized for matching performance. If we see, for example, a single column throughout a dataset with an unusually high frequency of one token, it probably means this token contains some kind of filler data.

We use several other mitigation and standardization processes to address “bad data” issues in token generation. These include phonetic algorithms like Soundex and Metaphone. Soundex was developed in the early 1900’s to better analyze census data. It’s a “sounds-like” algorithm that helps standardize name spelling variations (e.g. “Steven” and “Stephen”). Metaphone is an algorithm designed in 1990 that was intended to be an improvement on Soundex. It takes into consideration the many variations and inconsistencies in English spelling and pronunciation. These and several other standardization and mitigation strategies help “improve” the quality of the data we have available to us.

Below, you can see how these mitigations might play out while generating a set of tokens. Highlighted fields are understood to be accurate. Parenthetical fields have undergone mitigation:

There are several other steps in our machine learning process we won’t go into here. Once we have determined a match, we assign a Datavant ID (DVID) to deidentified patient records. DVIDs are consistent across datasets within a use case-specific, and exist as an appended column within each dataset:

As we mentioned, each dataset captures the data of an individual at a specific point in time, but DVIDs are designed to be stable across time and account for changing addresses, names, phone numbers, and emails.

Training the model

We train our machine learning model on billions of records, looking for patterns between records. Our training data is representative of the US population — drawn from real world data and electronic health record data. This means we see the highest accuracy matches on a very large scale, taking into account the tokens available, their fill rates, and the use case of the data. This allows us to make highly accurate matches regardless of the data provenance or context in which it was collected.

As a result, we have the ability to dial-in the desired balance of precision and recall based on the specific needs of the customer. If we increase the precision of our matching (detect high-confidence matches only), this may come at the cost of recall. If we increase recall (allow the inclusion of lower quality matches), this similarly may come at the cost of precision. With referential data in the mix, these tradeoffs are significantly smaller.

How do we know if we’re getting it right? Referential data as data bridge and source of truth

Finally, in order to verify the success of our machine training, we need to reference our predictions against a source of truth. With regard to the Captcha example given above, human engagement across millions of Captcha interactions help train the AI, and also act as a source of truth for future training. For us, this is where the referential data layer comes in. It allows us to both check our predictions and find additional matches that may have otherwise been missed.

As we mentioned above, precision and recall are often tradeoffs for one another, with higher precision often equating to lower recall and vice versa. By using a referential dataset as a source of truth and bridge among datasets, we are able to boost match accuracy to over 99% precision at 95% recall.

More positive outcomes, fewer negative outcomes

We’re working to boost the positive outcomes afforded by studying well-connected real world data, and we’re also working to reduce the negative consequences of inadequate or poor matching. Missed matches (i.e. your x-ray history not connected to your pharmacy history) limit the possibility for gathering information on patients with chronic conditions. This could result in duplicate tests, missed diagnoses and delayed care. False positive matches (i.e. connecting your x-ray history to somebody else’s pharmacy history) result in inaccurate patient tracking and can jeopardize the quality of research studies. Achieving the combination of high precision and high recall afforded by incorporating referential data means we can sacrifice less in the quest for more higher quality matches.

About the authors

Authored by Varun Lahoti and Nicholas DeMaison with input from Aneesh Kulkarni, Jonah Leshin and Vera Mucaj.

Varun Lahoti is a Product Manager at Datavant. He has a background in biomedical engineering, computer science and analytics. Connect with Varun on LinkedIn.

Nicholas DeMaison writes for Datavant where he leads talent branding initiatives. Connect with Nick on LinkedIn.

We’re hiring remotely across teams. Check out our open positions.

Referential Data in Datavant Match was originally published in Datavant Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Datavant is building an enterprise SaaS product, so our business model is unlike that of consumer applications. How do we facilitate collaboration, define ownership and remain customer-obsessed given that we serve several highly differentiated groups of customers who use our products in radically different ways?

Broadly speaking, Datavant currently serves 4 different customer verticals:

• Life Sciences/Ecosystem/Public Sector (ie: pharmaceuticals and government)
• Payers (ie: insurance companies and Medicare/Medicaid)
• Providers (ie: hospitals and clinics, etc.)
• Attorneys and Life Insurance

Across those 4 verticals, we offer 3 core products:

• Privacy-Preserving Record Linkage (aka Tokenization)
• Release of Information
• Medical Record Retrieval

All of our products are built on the cornerstones of data privacy, security, and compliance, but some of these products exist in a landscape of de-identified data and some exist in a landscape of identified data. To complicate the scenario a little further, customers and products do not exist in a 1:1 relationship. Within each vertical are customers interested in more than one of our core products.

Given the complexity of our product:customer matrix, which exists within a rapidly growing business, and given that our business exists within a rapidly growing health tech ecosystem, how do we ensure that we:

1. build products customers need,
2. build high quality products that customers continue to want to use,
3. have fun building products?

This last point is quite important and not necessarily a given unless we decide to prioritize it. We want the [Engineering-Product-Design] group to have fun, be happy, and be inspired by each other; happy teams lead to better business outcomes, and people are…happier.

The [EM-PM-PD] Group

The relationship between Engineering Manager (EM), Product Manager (PM) and Product Designer (PD) sits at the nexus of our product development. There’s a healthy and to-be-expected tension between these three areas as we move from techno-theater to viable products:

• “That idea sounds super cool…” (-EM)
• “…but no one will pay for it.” (-PM)
• “That idea sounds super cool…” (-PM)
• “…but we can never build it.” (-EM)
• “That idea sounds super cool...” (-PM)
• “…but what is the problem space we are solving for?” (-PD)

How do we keep this group and the associated Engineering Pods (Datavant’s term for the smallest size engineering team) working as impactfully as possible?

Cultivating ownership

One of Datavant’s core values is for Datvanters to “Operate Like Owners.” One interpretation of that could be to set up highly delineated roles, in which each owner exercises full decision-making rights:

This could work well for individuals with certain skill sets at certain stages of product development. An EM who is highly focused on the issues arising in the engineering domain might be very eager to take on difficult technical challenges with their Pod, and to figure out the most scalable solution that can be shipped as quickly as possible. They might be deeply focused on code quality and coaching their team to write better tests, design better systems, get faster at on-call, and become top-notch debuggers.

If an EM’s interests skew toward the Product domain, though, they might become interested in understanding how their Pod’s work impacts a specific business outcome. They might want to understand why X is priority #1 and not priority #2. They might even want to talk to customers to listen for nuance in how the customer describes their needs. If an EM’s interests skew toward the Design domain, they may want a deeper understanding of user research insights and the entire problem space in which a project sits. Such a set of interests could rupture the idea of ownership as defined by “clear lanes.”

Organisms, not lanes

Rather than determine fixed lanes as a means to cultivating ownership, we seek to set up the [EM-PM-PD] group as a singular organism. The more each person in the trifecta is able to empathize with the demands of the others’ domains, the better they will be able to figure out the right balance of decision making rights. Individual decision making rights still exist. The goal is not to establish a decision-by-committee system, but to clearly articulate the balance of decisions to be made.

The ultimate goal is for individuals to make engineering, product, and design decisions in parallel.

In consultation with their Pod, they can also then determine how to operate together. Is this particular PM an outstanding planner and highly detail oriented? Maybe they’ll own the sprint board. Is this PD particularly business minded? Maybe they’ll take over a pricing study. Does the group use a project management tool? Do they conduct standups? Do they write Product Requirements Documents (PRDs)? Do they communicate via Jira tickets and iterate quickly?

Again, the balance and form of each “organism” is also relative to the given stage of product development. During discovery, the PD might lead research while the PM observes and synthesizes. Inviting in an EM can dramatically shift the discussion if the EM has deep empathy with a technical user. Engineers embed certain assumptions about use cases in the technical architecture: the closer they are to the customers’ needs, the better our products and the better they scale. This works in the other direction for decisions about technical architecture: a PD with a holistic view of all the products can advise on how different products should interact together.

With all of this in mind, the group must determine the best operating model for their Pod to impact the business outcome they are working to impact at their given stage of product development.

The ultimate goal is for individuals to make engineering, product, and design decisions in parallel, as we believe this empowers the greatest sense of ownership within the managing organism and within the Pod.

Pod collaboration and accountability

As we mentioned above, our customer-product matrix does not exist in a clean 1:1 relationship. Sometimes multiple Pods need to build the same thing to meet the demands of different customer verticals; sometimes a Pod wants to build on top of a core component that a different Pod built.

How do we organize collaborative efforts between Pods? Another of Datavant’s core values is that “We Value Time as Our Most Prized Asset.” Whatever form collaboration takes between Pods, it should be one that facilitates moving quickly.

So:

• If there are two Pods working on similar products where collaborating could make both products better, then they should collaborate.
• On the other hand, if there are two Pods working on products that depend upon one another and one team is held accountable to deliver a business outcome but is blocked by another team, we should find ways to adjust ownership so that one Pod is not blocking the other (…or figure out how to collaborate differently…) as this scenario diminishes autonomy and ownership.

In the diagram on the left, both Pods can hit their business goal independently of the other Pod. If both Pods succeed while also encouraging a fluid exchange between them, then the end product will be better.

In the diagram on the right, neither Pod A nor Pod B is empowered to hit the business goal. Pod B might receive something from Pod A and sit on it, or Pod B might be unable to advance while waiting for something from Pod A. In this case it’s nonsensical to hold either Pod accountable for hitting the business outcome. Not only does this structure slow us down, it also destroys real ownership.

Two types of dependencies, two types of ownership

Whereas we want to eliminate blocking dependencies in Pod collaboration to encourage greater accountability and ownership, we want to encourage dependencies within the [EM-PM-PD] organism, even if it makes the process slower because it reinforces working with intentionality.

In the long run, this saves time by reducing the number of things that get built that do not hit the mark for customers.

It’s not just about products, it’s also about growth

Datavant has never been a static entity, and a third of our core values is to “Prioritize Growth Over Comfort.” As we continue to grow, our goal is to set up organizational structures and working paradigms that allow for the possibility of deep ownership, and which can thrive across team expansion. In tying these structural decisions to our core values, we think we are proposing a durable way of thinking about organizing that can flex according to the realities of business needs and the varied interests of the individual Datavanters working within these structures.

About the authors

Authored by Matt Vail and Nicholas DeMaison with input from Aneesh Kulkarni, Varun Lahoti, Gracie Chen, Annie Powers and Alicia Loewenthal.

Matt Vail is an engineering leader at Datavant. He has over 10 years of experience in designing and building software products, recruiting and leading engineering teams, serving as a board member and angel investing. Connect with Matt on LinkedIn.

Nicholas DeMaison writes for Datavant where he leads talent branding initiatives. Connect with Nick on LinkedIn.

We’re hiring remotely across teams. Check out our open positions.

The [Engineering-Product-Design] Organism was originally published in Datavant Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

“How do I get my medical records?”

This is one of the most common requests in healthcare. With Datavant’s Switchboard, we are reducing the time and number of steps involved for patients to get their medical records. But patients are not the only requesters of medical records — a significant number of requests for medical records come, for example, from insurance companies making Medicare risk adjustments. In order to demonstrate that an insured population meets certain risk criteria, insurance companies must pull medical records for these patients in large numbers. Datavant only routes requests that have proper authorization and are allowable under HIPAA guidelines, a quantity which currently amounts to around 50 million record requests per year from a variety of requesters.

How are large-volume record requests fulfilled and how can we make the process faster and more reliable?

Two routes to the record: providers and patients

We need a minimum amount of information to locate a patient’s medical record. Historically, our Chart Requester product used a provider-based flow to route searches for medical records, which requires the following information to locate a medical record:

1. Provider information — We have information sufficient to know where to look for a record (Dr.’s office / hospital / clinic etc.), and we can either:

a.) retrieve the record manually (via fax, by sending a person to a physical location, etc.) or,

b.) retrieve the record digitally (via API call, through a 3rd-party EMR vendor, etc.).

2. Patient information — We know whose record we’re looking for.

3. Encounter date — Among the various records for a given patient at a given provider, we identify the correct record via the date the service was provided (an “Encounter”).

In a world of paper medical records, starting with the physical location of the provider and moving by steps toward the specific record would be the only way to proceed. (That is, you wouldn’t send somebody to Florida to find a record in Oregon.) Recreating a digital version of this path — “provider-based flow” — was a necessary first step in building a retrieval system at scale because even though provider “file cabinets” are increasingly digital, they are not necessarily connected in highly useful ways.

When there isn’t enough information

Datavant often receives requests, however, for which we don’t have information sufficient to carry out the provider-based flow route. If the record requester only gives us a patient name and an encounter date, we wouldn’t know where to start looking for the record. We’ve described this problem elsewhere as the “finding a needle in an invisible haystack” problem. In order to locate a record under these circumstances, Datavant has developed a route for person-based flow.

Person-based flow is already in use in our Convenet product in England, something made possible because of England’s centralized health system and Convenet’s integration with the NHS-Spine. The problem in the US is much more challenging because of the extreme fragmentation and siloing of our healthcare landscape. To continue the above metaphor, there are many, many “invisible haystacks’’ across the American healthcare ecosystem where records could be stored.

Setting the parameters for person-based flow

Because requests may have varying levels of patient data included in them, the actual routing component of the service should be able to operate on a minimum amount of information, which we have determined to be the patient’s name and zip code as registered with their insurance company.

We can think of building person-based flow as creating a superset of provider-based flow:

Because we need to make API calls to several providers to locate a record, our routing mechanism must downselect from hundreds of connected clinics to only those most likely to contain the patient’s medical record. Obviously we can’t simply flood every provider in our network with all 50 million record requests, but more than that, we want to go as far as possible toward reducing our load on client API services. In fulfilling our mission to connect health data and improve patient outcomes, we want to keep our request loads on healthcare provider systems as light as possible.

Finding a haystack in a field of haystacks

For the rest of this article, we’ll use “clinic” to refer to any location where a patient may have received medical care and a medical record might be found.

Our person-based flow routing uses an approach that combines Thompson Sampling (TS) with k-nearest neighbors (KNN).

In our case, our “casino” is the size of the entire United States.

Thompson Sampling

Thompson Sampling is a Bayesian decision-making heuristic where actions are taken sequentially in a manner that must balance between exploiting what is known to maximize immediate performance and investing to accumulate new information that may improve future performance (balancing exploitation vs. exploration). This is also known as an algorithm for choosing the actions that address the exploration-exploitation dilemma in the multi-armed bandit problem.

Instead of deciding which arm to pull next on a group of slot machines, here we balance exploiting popular clinics that have a high probability of containing a patient’s medical record with exploring other clinics that have a yet to be determined or high variance probability of containing a patient’s medical record. And in our case, our “casino” is the size of the entire United States.

To our advantage, however, there is a geo-spatial relationship between our players (patients) and the expected reward of the slot machines (the likelihood of a clinic having a chart). We use KNN to exploit this fact and build priors intelligently (beginning distributions that model a clinic having a chart given a patient postal code).

K-nearest-neighbors

K-nearest neighbors is a supervised learning method to select a rank-ordered list based on a distance metric. In this case, our distance metric is the cartesian “as-the-crow-flies” distance between postal codes. This allows us to cast a wider net of historical information when profiling the care habits of patients living within a postal code. Put another way, KNN allows the algorithm to leverage nearby postal code information when current postal code information is scarce, and does so by assuming that patients living in adjacent or nearby postal codes will have similar care habits.

Benchmarking with DS algorithm

We tested the performance of two algorithms: modified-TS, described in detail below, and a simple Distance Heuristic (DS) to be used as a benchmark. The default setting for the DS algorithm was to return any clinic within 100 miles of the patient zip code:

Designing our modified-TS approach

Our “modified-TS” approach can be summarized in four steps.
After receiving the patient postal code as an input, we:

1. Create a bucket of 100 closest postal codes to the patient (KNN).

2. Model Probability Distribution Functions (PDFs*) for clinic-postal code pairs (TS).

3. Sample patient-clinic PDFs then weight average and rank order clinic scores (TS).

4. Send clinics above 3% probability to our Dispatcher tool (the routing service responsible for coordinating jobs).

*not to be confused with Portable Document Format

Let’s break that down.

Step 1: Create a bucket of 100 nearest postal codes to the patient

The first step of the modified-TS algorithm is to form a group of 100* nearest postal codes to the patient’s postal code, referred to as a “bucket.” The bucket leverages similarities in clinic visit behavior between patients who live near one another. It also allows the algorithm to model a probability for a patient living in a postal code for which there is little to no information. The bucket weights are uniform, meaning the historical data taken from every postal code in the bucket has equal voting rights.

*We tested variable distances for a hard mileage-based cutoff, as well as various numbers of k-nearest neighbors; K=100 was found to be optimal.

Step 2: Model Probability Distribution Functions (PDFs) for clinic-postal code pairs

The second step of the modified-TS algorithm is to model PDFs of each clinic-postal pair. The chosen PDF for this was the beta distribution, which models probability based on the success and failure of every chart request received by a clinic for a given patient postal code. Typically, historical information can be leveraged via simulation whereby distribution parameters are updated according to Bayes’ rule. This simulation however, is computationally expensive, as Datavant processes many years’ worth of record retrieval data (hundreds of millions of records).

Instead, the following analytical approach was employed to solve for the parameters of the respective beta distributions for every clinic-postal pair:

• Success (alpha) was taken as the count of total charts retrieved from the clinic from its paired postal code.
• Failure (beta) was taken as the total number of charts found for the paired postal code, minus alpha.

Step 3: Sample patient-clinic PDFs, then weight average and rank order clinic scores

The sampling of the PDFs is what allows for the exploration-exploitation tradeoff in the traditional TS approach. The rank order step ensures that priority is given to clinics with a high expected value, but that clinics with a lower expected value and high variance are occasionally selected as well. After sampling from the PDFs, an equally weighted (flat) average is taken for clinics represented by multiple postal codes.

Step 4: Send clinics above 3% probability to Dispatcher

In the final step, the highest probability clinics (those above a 3% minimum cutoff) are sent to Dispatcher. Keep in mind that the algorithm is not limited to returning clinics within 100 miles of the patient: we can return clinics anywhere within the U.S. as long as there is historical data of patients traveling from the bucket to the respective clinic.

Fine tuning the model: adding hyperparameters

Four hyperparameters were selected for the modified-TS algorithm: K in KNN (the bucket size), starting_context_scale (the weight given to surrounding postal codes), max_returns (the hard number of top clinics to return), and prob_min (the minimum probability by which a clinic is selected).

We won’t go into all of the details of those here, but an extensive primary gridsearch was performed to give 54 unique combinations of hyperparameters. Upon selection of max_distance, starting_context_scale, and max_returns, a more selective, secondary gridsearch was performed to optimize prob_min. The results of the secondary gridsearch are shown below.

API Requests and Success Rate are plotted against one another. The “elbow” indicated by the green circle, indicates that at a prob_min setting of 3%, the relationship between success rate and API requests begins to degrade, requiring many more API calls to achieve a very modest increase in success.

The final selected values for the hyperparameters correspond to a 95% success rate and 7.2 average API calls on a 10K test dataset.

Avoiding bias: contextualizing bucket weights

When grouping patients into buckets, KNN by itself does not take into account transit obstructions like waterways and large highways, nor does it consider the availability of public transit, income demographics or other variables that might affect the likelihood of proximal patients having similar care habits. To circumvent this, we ran an additional experiment.

In simulations limited to individual cities in the database, the modified-TS algorithm was allowed to store and update the weights between postal codes stored in the bucket (see Step 1, above) in a gradient descent-like fashion. This demonstrated dramatic improvement over the standard Bayes’ rule approach:

In other words, by pairing KNN with a learned weighting strategy the algorithm rewards nearby postals that return correct predictions and discounts those that don’t. So regardless of the underlying reason for different care habits, the model learns these effects at the granularity level of postal code. This experiment was performed for the cities of Saint Louis, Pittsburg, Milwaukee, NYC, Louisville, and Lexington, all with similar results. Mathematical details of this approach are available in the appendix.

Results

Results of our comparison test are shown below. The 10K test dataset was identical for both algorithms (none of which was used in training for the modified-TS algorithm). Success was determined as whether the actual clinic in the test dataset was returned in the clinic list produced by the algorithm.

• The success rate is the average of this binary output.
• The API calls is taken as the number of clinics produced in the clinic list by the algorithm — it is an indication of the downstream resources required to fulfill the request (lower is better).
• The performance is the computational time required for each algorithm to produce one clinic list for a patient postal code on an M1 laptop.

There was a decent lift in success rate, from 91% to 95%, and an enormous reduction in API calls, from 27.98 down to 7.18. Our modified-TS approach will likely lead to a slight increase in more patient charts retrieved but at a substantially lower resource cost.

Conclusion

Our expansion from provider-based flow to person-based flow allows us to find more medical records with less information. Combined with our recent API retrieval optimization, our combined-algorithm approach expedites record retrieval at scale, and allows us to do so in a way that minimizes the burden placed on the care providers receiving our requests. In the end, this allows us to improve patient outcomes directly for the patients trying to get their records in the course of care, and indirectly by allowing providers to allocate limited resources (computing power) where it is most needed, at the location of treatment.

Appendix

Mathematical Details

Glossary

𝑋 : the context coefficient matrix (referred to as a bucket in the main document)
𝜃 : estimated success probabilities
𝑡 : current time step
𝑝 : available regions (postal codes)
𝑘 : available targets/actions (facilities)
𝑥𝑡 : the target selected/action taken
𝑦𝑡 : the current region
𝑟𝑡 : the reward of selected target (0 or 1)
𝛼 : alpha parameter of the beta distribution
𝛽 : beta parameter of the beta distribution
𝜂 : context learning rate

Theta, the PDFs

The update criteria for 𝜃, the object that stores the weights of the beta distributions:

X, the postal-postal buckets

The update criteria for X, the object that stores the postal postal buckets:

About the Authors

Authored by Wesley Beckner and Nicholas DeMaison, with input from Ryan Ma, Jonah Leshin, Arjun Sanghvi, Aneesh Kulkarni, and Shannon West.

Wesley Beckner holds a PhD in Chemical Engineering Data Science from the University of Washington College of Engineering and is a Data Scientist for Datavant. Connect with Wesley on LinkedIn.

Ryan Ma has a background in Computer Science and Molecular and Cell Biology. He is a Software Engineer for Datavant. Connect with Ryan on LinkedIn.

Nicholas DeMaison writes for Datavant where he leads talent branding initiatives. Connect with Nick on LinkedIn.

We’re hiring remotely across teams. Check out our open positions.

How We Find Records When We Don’t Know Where To Look was originally published in Datavant Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Russell Kirmayer joined Datavant as an engineer in October 2022 and has since become the manager of the Requester Experience Pod, working on building out a platform for retrieving medical records and connecting health data for patients. In his previous role, he worked on a variety of engineering teams at small, early-stage startups. Despite his move into engineering management, he acknowledges that the [engineer → manager] trajectory is not for everyone.
Are you an engineer looking to grow your career (with or without becoming an engineering manager)? We’re hiring.

Datavant prioritizes growth over comfort. Keeping ourselves in the steep part of the learning curve is one of our core values. We’ve shared several articles on the Datavant Tech Blog describing the career paths of some of our engineers, like these about Anjali, Leon, and Carlos.

These stories all have a common narrative:

This narrative seems to be a common one for engineers generally. If you’re trying to remain in a permanent state of professional growth, what do you do after becoming whatever it is your company determines to be a “senior” engineer? Answering that question earlier can help keep you on a path doing the kind of work you want to be doing.

The [engineer → manager] path is not the only path available to you. In this article, we’re going to explore some options to keep growing without becoming a manager, but first, let’s talk about managers.

What exactly is a manager, anyway?

There are more articles (…and webcomics, memes, movies, and tv shows) about good and bad management than there are bits of data on the entire internet.* In The Making of a Manager, Julie Zhuo describes the role of the manager as: “to get better outcomes from a group of people working together.” The manager is responsible for the output, not necessarily the specific activity or inputs.

*This is an unverified statistic.

According to Zhuo, getting better outputs happens across three areas of focus:

• Purpose (the why): helping engineers understand why they are doing what they’re doing.
• People (the who): helping engineers improve their own skills via training, coaching, feedback, and mentoring.
• Process (the how): helping a team work together better to achieve greater than the sum of the individuals.

Managing includes a significant amount of administrative tasks (hiring and firing, handling compensation, team organization, etc.), the tradeoff for which is writing less code. We might summarize this tradeoff as transitioning from building/making to facilitating.

“I don’t need a manager anymore!”

There are common misconceptions out there about the relationship of engineers to managers, ideas like, “I don’t need a manager — I know what I’m doing, am good at my job, am fully autonomous, and don’t need feedback or advice!” or simply, “I don’t need to work with others, I just write my code.”

In addition to motivating a team, a great manager provides context and surfaces blind spots, which can help even experienced engineers increase the impact of their work. In a synergistic engineer / manager relationship, this becomes a positive feedback loop, with the engineer consistently seeking more context and feedback and the manager providing the right feedback at the right time to fill in whatever gaps are decreasing impact.

This cycle can occur no matter how senior the engineer is.

Maybe you’re a great engineer who contributes impactful work and your goal isn’t to manage, but to become a really great engineer who contributes really impactful work.

You don’t have to want to change careers in order to grow

There is significant incentive for companies to promote from within their own ranks, and Datavant is no exception in its focus on cultivating leadership from within, but as an engineer, it’s important to keep in mind that becoming a manager is tantamount to a career change.

Administrating, organizing teams, and bringing out the best work in people are particular skill sets that also demand commitment and development. This work is buttressed by your technical knowledge and experience building stuff, but it is no longer as much technical work. Some people are inclined toward managerial kinds of work and some are not. Maybe you’re a great engineer who contributes impactful work and your goal isn’t to manage, but to become a really great engineer who contributes really impactful work.

You are needed too. It’s important to remember that management and leadership are not the same thing. Managing is a specific set of tasks, but ICs can develop an impactful leadership profile without taking on the specific tasks of managing. A great engineer can use their knowledge and experience to lead from within their ranks and raise the skill and craft of their team just by interacting with the group in day-to-day functions.

If a company is sensitive to this, they will cultivate ways (possibly even independent of a title change) for engineers to increase the scope and complexity of problems they work on to keep them challenged and excited about their work.

Considering the options

Maybe you’re not entirely clear on the best non-manager path for you. Thinking holistically about the engineering organiztional structure and the priorities of each layer can help you define your own path.

• A great Engineering Director focuses on building the team that coaches the teams, and excels at hiring great coaches who create winning teams.
• A great Engineering Manager focuses on their team, and excels at building a team of IC’s and coaching individuals at their craft.
• A great Engineer focuses on their craft, and excels at finding all possible ways to improve their skills while acting as a source of expertise for more junior engineers.

Breaking this down further, Will Larson describes several archetypes of non-managing engineers above the Senior level. These include the Tech Lead, Solver, Architect, and Right Hand. None of these are managerial roles, but they have significantly different profiles and specialities, and the structure of their week looks quite different.

In addition to thinking about what you’re good at, what kind of work excites you, and how you want to spend your time, you can continue to refine your ambitions with some further healthy introspection:

• Do you enjoy focusing and becoming expert on a particular area like front end or React?
• Do you enjoy hopping around different projects and moving things from 0–1?
• Do you enjoy thinking about big picture and scale?
• Do you enjoy “rallying the troops” or shipping big code yourself?
• Do you enjoy specializing (depth) or being a generalist (breadth)?

On the last point, a useful way to think about the depth vs. breadth question is to think about the tradeoffs of each.

In the pursuit of depth, you invariably limit your field of study and so may have large areas you simply don’t know anything about. In the future, it may take longer to ramp up in one of these areas if you decide to move into it.

In going for breadth, you may know a little about a lot of things, but you may find yourself running into the limits of your skills more often. In the future, it may take longer to level up your entire skillset, because you can’t expand in all directions at once.

Defining, and then re-defining “impact”

Because you can only write so much code, non-manager engineers must redefine “impact” as they grow. How do you create an outsized influence and drive technical outcomes that are bigger than the code you write? For the increasingly senior IC engineer, this might be the fundamental question they must always be asking themselves. Some ways to do this might include:

• Learn new design patterns / programming languages / frameworks
• Look for ways to scale the team (eg. tools to multiply leverage)
• Take on the hardest problems, learn a new domain (eg. SQL expert)
• Look across pods, find common problems, create cross-pod learning
• Read tech blogs / books / online class and bring back knowledge to share

Datavant currently has 6 levels for engineers, ranging from P0 (new grads making short code changes and fixing known bugs) to P6 (org-level engineers working on multi-month projects). To help the members of our team continue to move up that ladder, we have an “unlimited learning” policy, which means supporting educational opportunities, including but not limited to:

• Online courses
• Tech conference
• Books
• Anything you think will expand your skill set

Why it matters

Most people will spend 1/3rd of their adult life at work (~90,000 hours). Feeling like you are good at your job, feeling satisfied with the challenges you face, feeling like you contribute to your team, feeling a sense of progress, and owning your own growth aren’t just about being an impactful worker for your employer. These are fundamental questions about your life and how you use the time you have. Why not spend some time considering the possibilities and approaching this third of your life with the same intentionality you approach the other two thirds?

About the authors

Russell Kirmayer has a background in mechanical and software engineering and is the manager of the Requester Experience Pod. Connect with Russell via Linkedin.

Nicholas DeMaison writes for Datavant where he leads talent branding initiatives. Connect with Nick on LinkedIn.

Datavant’s engineering team is growing. Check out our open positions.

Growing your Engineering Career was originally published in Datavant Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.