Particle

Today, we’re discussing Particle and how it’s being used in your company. Could you briefly outline your company and your role?

We are a value-based primary care company, comparable to Oak Street Health. I work in data and product management.

What drove the need for a solution like Particle?

The need arose from a gap in understanding a patient’s comprehensive medical history, which is critical to effective value-based care. Given our acquisition-based model, it was challenging to acquire a new clinic and also maintain an inclusive history of patient care, so we were looking for a vendor that would enable us to access health information networks to retrieve that information.

During the procurement process, what were your requirements when assessing different competitors?

Coverage was a significant factor for us due to our unique geography, so we needed to ensure the vendor’s networks spanned our service areas. Ease of integration and pricing models were also important given our small size, both budget-wise and in terms of tech team capacity.

How did you assess whether a vendor could adequately cover the areas important to you?

First, we evaluated which networks they were part of, both nationally and regionally. Both the vendors and some public sites like CommonWell and Carequality list their provider groups, so we assessed those.

We also considered the hit rate. If our patients are using the healthcare system less, we’re less likely to get a hit rate that’s comparable to those in urban environments, so we compared average hit rates specifically for the counties we service.

Did you have the opportunity to run any test queries to understand coverage, or did you have to rely on more static information?

We didn’t run test queries during the vendor evaluation phase, although we were offered the opportunity to pull a small dataset of patients to check the hit rate. However, before fully launching with Particle, we conducted a test round.

Which other vendors did you consider, and how did they compare to Particle?

We evaluated Health Gorilla, Zus, and Pluto. We also considered Bamboo and Collective Medical, but their use cases differed from our needs, so we dismissed them early on.

Most of them are connected to the three major health information networks. However, Zus wasn’t directly connected to eHealth Exchange at the time.

We considered pricing, and Particle came out ahead in terms of pricing for our specific needs.

We also considered integration capabilities and timelines. Two critical factors were the potential for direct EMR integration and assistance with the transition process. Athena has its own connections to CommonWell and Carequality, and you can only be subscribed through one vendor, so we evaluated the customer service process for assisting us in the switch to a new vendor.

We also considered the potential for growth and expansion. Some of the services we evaluated included ADT for push notifications versus pull notifications, and pharmacy data accessibility. Particle offered both, thanks to their Bamboo partnership on the ADT side and their Cureatr partnership for pharmacy data.

At the time, Health Gorilla didn’t offer either, although they may have ADT data now. Zus had access to Collective rather than Bamboo, and they were working with Surescripts. So it came down to evaluating what made the most sense for us.

What made Particle stand out?

The key factor that made Particle stand out was the pricing model they offered, which was best suited to scaling. Other vendors’ per-member-per-month (PMPM) models would have become expensive very quickly because we were growing through acquisition.

Particle also offered the best integration and technical support, which was important to us because of our small team.

Did the emergence of QHINs, given your interest in state-level HIEs, impact your decision?

Somewhat – Health Gorilla’s early involvement with those networks was a draw for us, but pricing was the main factor that swayed our decision. It will be interesting to see how this evolves as we expand into new states in the coming years.

How was your experience with the sales process?

The sales process was relatively painless. They were flexible and worked with us to provide a pilot test, which might not typically be offered. They also worked with us to develop a pricing structure that met our needs.

Given our small size, we were able to sign the contracts fairly quickly, and they didn’t complicate that process.

What was the onboarding and setup process like for you?

We had weekly meetings within the first 30 days, and we worked with an implementation team. They had a project management tool intended to guide us through the onboarding process, but we didn’t use that very much. We also had a Slack channel with their team, which proved extremely helpful for quickly addressing questions.

Are you actively using the Particle integration in your workflow?

Yes, we’re in production with Particle. Some use cases such as diagnosis, suspecting, revalidation, and quality perspectives are not yet fully live. But we’re actively using it to query and retrieve medical history data for our patients.

Can you explain your two main use cases for Particle in a bit more detail?

The first use case relates to achieving complete and accurate diagnoses. We’re searching for chronic conditions diagnosed over the past 36 months, which we present to our providers for review, re-diagnosis, or dismissal as appropriate.

The second use case revolves around quality gap closure and management. For the minimum viable product, we’re focusing on preventative screenings. We sift through the procedure history retrieved from Particle’s queries to find tests like mammograms or colonoscopies to ensure they’re recorded in our EMR to close those gaps for our patients.

Could you describe the data flow for these use cases?

There are three ways to interact with Particle queries: C-CDA extracts; FHIR, which is now the standard; and a recently released Flat API. We use their Flat API.

On a regular basis, we query for patients who have upcoming appointments. We then receive and parse the JSON response data, store it, and then sort it based on our use cases before using Athena’s APIs to push the data into the EMR. We manage all of the coordination between Particle and Athena; as far as I’m aware, there are no direct connections between Particle and Athena.

Do you need to deduplicate, summarize, filter or extract data before pushing data into Athena?

There is some data cleaning involved. The Flat API essentially provides a relational data set, which requires us to merge with other data sets for additional information such as facility details. The data we receive sometimes lacks certain fields or isn’t particularly useful; this isn’t necessarily a comment on Particle but might just reflect the current state of healthcare data in general.

How did you decide between using Athena’s built-in features for clinical data interoperability versus developing your own code to integrate data from Particle?

The main hurdle with using Athena’s built-in interoperability feature was that the data wasn’t stored in a useful format. Although our providers could access discharge summaries and similar information on the front end, that information is not stored in a usable format in the backend.

Athena does store the data, but the information fields have a character limit, which results in unusable, truncated data. We tried to work with Athena to leverage the data we were already receiving, but they were less than helpful.

Which other features of Particle have you found significant?

We’re primarily using Particle’s Flat API feature. We’ve just discovered that some responses still store XML or HTML data, which is helpful to us. That offers us the best of both worlds, rather than having to parse all the data from the C-CDA format, which can be challenging. This was a pleasant surprise and will be highly beneficial for our specific use cases.

How would you assess Particle’s strengths and weaknesses?

One of Particle’s key strengths lies in its ease of implementation. They offer a straightforward API for setting up an integration, and they’re rapidly evolving, consistently releasing new features and actively listening to clients.

As for weaknesses, this could be more of a byproduct of the sector: dealing with the data can be challenging. For instance, one of our use cases was focused on ADT data. We wanted to evaluate the level of inpatient and emergency service utilization for the populations we were acquiring. The data is very incomplete, which limits our ability to gain a clear understanding.

I don’t know how much improvement is feasible, but I’d love to see them invest more time into data cleaning and improving the quality of the data they deliver, rather than just simplifying or “flattening” it.

Has the platform proven reliable?

Yes, overall it’s been reliable. We’ve only encountered one instance of a bug causing downtime. My only qualm is that the situation could have been communicated more effectively.

What has your experience with the developer documentation and the general usability of the flat API been like?

Their documentation is well laid out and was very useful during both vendor evaluation and implementation. Any missing information could be addressed directly through our technical contact from the onboarding team. We haven’t come across any outdated documentation; they’re pretty good at keeping it up to date.

Do you have any advice for those considering using Particle and their API for their own integrations between the API and their EHRs?

I think most of the issues we’ve encountered were related to our tech stack rather than Particle. If you make good use of Particle’s implementation team and follow the implementation documentation to the letter, I believe you’ll likely be in a good place.

How has your experience been with account management and support at Particle?

Overall, the account management and support at Particle have been good. They’ve made themselves available, even though we might not have made as much use of them as we could have. They’ve been helpful in addressing our inquiries.

One area for improvement could be from the reporting perspective: they were insistent on us using a Looker dashboard intended to showcase different use cases. They assured us that it would be very helpful, but it turned out to be somewhat time-consuming without clear benefits. Clearer communication about its intended use and benefits might have been useful.

Aside from that, they’ve been great. We still have regular check-ins with them, though we’re well into our implementation process.

Do you think you made the right decision to proceed with Particle?

I believe choosing Particle was the right decision overall. The only other vendor I might have reconsidered would be Zus. We were primarily concerned about their pricing, but it would be interesting to see their progress and evolution since we last engaged with them in Q1.

Do you have any recommendations or advice for the product strategy or management team at Particle?

I’d recommend focusing on two main areas. The most valuable one would be to spend more time on cleaning the data and enhancing its usability. The other suggestion is that they expand their reach to regional or state-level health information networks. Given that they promote themselves as a “network of networks,” broadening their scope beyond national networks – which do not cover 100% of regions – would be very valuable.

Do you have any advice for potential buyers considering their interoperability stack options?

I’d definitely suggest leveraging test queries earlier in the process. It would have been useful during our evaluation process to understand what the data and hit rates would look like.

Given how significantly pricing varies among these services, I’d also recommend considering your organization’s maturity level and growth phase. Depending on whether you’re in a maintenance or rapid growth phase, your choice may differ, so consider what makes sense for your organization’s current status and future trajectory.