[adunsulag]

In your FHIR implementation, what version of USCDI do you support? I'm assuming you're following US Core profile's with your implementation guides? Have you implemented US Core STU 6.1.0? I know I'd be interested in using your converter and your exchange product if it could help facilitate what's required for ONC certification in 2026. I didn't see listed anywhere your capability statement URL that would give insight into what your doing.

I congratulate you on your launch and I'm interested in your converter. I'm surprised you didn't mention the TEFCA effort and wondering if you're planning on becoming your own QHIN (Qualified Health Information Network) or if you just plan on interfacing with all of the major QHIN's?

How are you handling interstate data exchange privacy requirements. Some states have restrictions on what data can be shared across state (thinking about this in terms of things like PDMP queries). I'm also wondering how you are handling the patient data access audit trail as well as information blocking filtering requirements. Perusing your documentation, it looks like you pass along the AuditEvent, does your system create additional audit trails for those who access the patient data? Or is that all being handled upstream w/ your QHINs?

[dgoncharov]

Thank you for the detailed questions - lots to dig into:

> In your FHIR implementation, what version of USCDI do you support? I'm assuming you're following US Core profile's with your implementation guides?

We will support USCDI v3 (which is the ONC requirement for 2026), and are following US Core as closely as possible with our FHIR converter.

We're working on improving our FHIR documentation across the board, and have the beginnings of a FHIR-specific IG here: https://docs.metriport.com/medical-api/fhir/overview

> I didn't see listed anywhere your capability statement URL that would give insight into what your doing.

Yes good point - raised an issue for this here: https://github.com/metriport/metriport/issues/2142

Please feel free to raise more issues on our repo if you'd like to see other improvements, and it would be great to get in touch about your use case!

> you didn't mention the TEFCA effort and wondering if you're planning on becoming your own QHIN (Qualified Health Information Network) or if you just plan on interfacing with all of the major QHIN's?

Haha this post was already close to exceeding maximum length, so we had to trim it down a bit - we thought no-one would know what TEFCA/QHINs are, but cool to see that you do.

(For anyone reading this, TEFCA is the the document driving changes for different permitted purposes of use, and general governance of the networks, by the ONC. QHINs are one of the outputs of TEFCA, and are a flavor of HIEs that promise to bring more use cases, such as patient access, to the table)

Unfortunately QHINs aren't very meaningful right now, since patient access queries are not mandated to be responded to by TEFCA. One of the HIEs we connect to, CommonWell, is already a QHIN, so we'll look at leveraging that, or becoming one ourselves, as we see fit.

> How are you handling interstate data exchange privacy requirements.

We handle this on a case-by-case basis based on: (1) what state our customers' patients' are located, (2) what kind of data they can/will be sharing, and (3) state requirements as you mention. For example, there is a new bill in California that will require special care of medical info as it pertains to abortion, contraception, and etc: https://trackbill.com/bill/california-assembly-bill-352-heal...

> also wondering how you are handling the patient data access audit trail

All transactions that interface with our system have audit logs attached to them by default (as per HIPAA/SOC2 requirements).

> Or is that all being handled upstream w/ your QHINs?

Nothing is handled upstream with the HIEs we connect to (note that QHINs are a different subject, and just enable future use cases outside of Treatment) - audit logging is up to each member of the network, including us. For example, Carequality only has a directory that implementers connect to, they don't store any data, and their only service is a directory of endpoints (it's more of a framework in that sense).

[nradov]

Is this intended for use by providers or consumers/patients? Authorized providers can use TEFCA through a QHIN to query for treatment purpose of use, which is supported by all participants.

How does your service differ in practice from existing networks of networks like Health Gorilla and Particle Health?

[dgoncharov]

> Is this intended for use by providers or consumers/patients?

This currently can only be used by providers, or healthcare IT vendors working with providers. Referring to the post: "using Metriport for patient data exchange today requires a Treatment purpose of use under HIPAA - which means that only Covered Entities, or Business Associates who work with Covered Entities, can use Metriport."

> Authorized providers can use TEFCA through a QHIN to query for treatment purpose of use, which is supported by all participants.

Yes you can query for Treatment, but you won't get meaningful coverage. QHINs do not have nearly enough adoption to be used for Treatment. Essentially the pool of providers using QHINs is insignificant, so you need to go through existing HIEs to get meaningful coverage.

The driving force behind QHINs is to open up new use-cases for accessing patient data, not necessarily to make the Treatment purpose of use better.

> How does your service differ in practice from existing networks of networks

We're the only vendor that's open source, where you can see and trust what's going on under the hood. Ask other vendors how they do record location, patient matching, or data mapping, and they'll just tell you "trust us, we're the best!".

Additionally, we're the only vendor that is confident enough in our solution to work with companies month-to-month, to show them that our product actually brings them value (and works as advertised) in production. Other vendors will lock you into $120k+ yearly contracts before even showing you production patient data. True story: a provider came to us recently after one of the vendors you mentioned locked them into a yearly contract, and only after the lengthly implementation period did they realize the product didn't work well at all - so a bunch of time/money wasted, and they need to migrate now anyways.

We have many advantages feature-wise as well, feel free to compare our dev docs!

[rqtwteye]

We are paying 60k for Health Gorilla and I am not sure it’s worth it. I think you can distinguish yourself by providing by excellent consulting services helping your customers to implement solutions. Without help the learning curve with health data is not enormous and everything is very complex and opaque.

[dgoncharov]

Feel free to get in touch with us - we've migrated others of HG, and they can vouch that they get better data density, coverage, quality, and speed with Metriport.

> distinguish yourself by providing by excellent consulting services

We actually work very closely with companies month to month during a pilot period to implement an MVP integration to show them the value of the product for both data pulls, and contribution - consultant-style.

We'd love to chat if you're up for it: https://calendly.com/colinelsinga/metriport-intro

[nradov]

Sounds good. Most traditional provider orgs don't care about open source and lack the IT resources to look under the hood. But some newer digital health companies do care and will see that as an advantage.

[dgoncharov]

> Most traditional provider orgs don't care about open source

Depends who you're talking to - from our experience CTOs of large provider orgs love the open source aspect (generally anyone with a tech team). Smaller orgs with no tech team don't care as much, you're right, but we also support them through a no-code provider dashboard.