[Provider Request][Charm]

[dwradcliffe]

Contact Details

[email protected]

Provider/Institution Name

Charm PHR

Provider/Institution Website

https://phr2.charmtracker.com/

Patient Portal Login Website

https://phr2.charmtracker.com/login.sas

Provider EHR Platform

Charm PHR

Anything else we should know?

This is the backend system for many health providers, but they don't have branded or unique logins so this should be "easier" to implement once for anyone using this system.

https://www.charmhealth.com/resources/ehr-api-program.html
https://www.charmhealth.com/resources/fhir/index.html

In my case, the actual provider is Center for Fully Functional Health (https://fullyfunctional.com) but I don't think that part is relevant.

[AnalogJ]

I actually had a conversation with Charm earlier this year, but they had pushed back on providing me a customer list and had demanded fees for accessing their developer environment. Since then I've done a closer read of the Cures Act and parts of HTI-1, so I just sent them the following email:

---

Hey,

I just wanted to follow up on this conversation.
Regarding your fees, this seems like it would potentially qualify as information blocking:

https://www.federalregister.gov/d/2020-07419/p-1315

As discussed in the Proposed Rule in 84 FR 7481 and finalized in § 170.404(a)(3)(i)(A), any API-related fee imposed by a Certified API Developer that is not expressly permitted is prohibited.
..

(3) Any fee in connection with any services that would be essential to a developer or other person's ability to develop and commercially distribute production-ready applications that use certified API technology. These services could include, for example, access to “test environments” and other resources that an application developer would need to efficiently design and develop apps. The services could also include access to distribution channels if they are necessary to deploy production-ready software and to production resources, such as the information needed to connect to certified API technology ( e.g., service base URLs) or the ability to dynamically register with an authorization server.

https://www.federalregister.gov/d/2020-07419/p-1352

We have finalized an approach that permits Certified API Developers to recover incremental usage costs reasonably incurred during the process of hosting certified API technology on behalf of an API Information Source, which could include fees to the API Information Source for providing and supporting patient access. However, the Certified API Developers and API Information Sources cannot recover these costs from patients or the developers of applications that facilitate access to and receipt of patients' EHI. Patients have already effectively paid for their EHI, either directly or through their employers, health plans, and other entities that negotiate and purchase health care items and services on their behalf.

https://www.federalregister.gov/d/2020-07419/p-2660

For example, a health care provider that charges individuals a fee in order for the individuals to receive access to their EHI via the health care provider's patient portal or another internet-based method, would not be able to benefit from this exception. Similarly, where an individual authorizes (approves) a consumer-facing app to receive EHI on the individual's behalf, the exception would not apply to practices where an actor charges the app or its developer a fee to access or use APIs that enable an individual's access to the individual's EHI.

Are you certain that Charm charges developers fees as described in our previous emails?

Regarding your inability to share your customer list/endpoint list: Do you have an estimated date when you'll be compliant with HTI-1? Specifically

https://www.ecfr.gov/current/title-45/part-170#p-170.404(b)(2)

(2) Service base URL publication. For all Health IT Modules certified to § 170.315(g)(10), a Certified API Developer must publish, at no charge, the service base URLs and related organization details that can be used by patients to access their electronic health information, by December 31, 2024. This includes all customers regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source. These service base URLs and organization details must conform to the following:
(i) Service base URLs must be publicly published in Endpoint resource format according to the standard adopted in § 170.215(a).
(ii) Organization details for each service base URL must be publicly published in Organization resource format according to the standard adopted in § 170.215(a). Each Organization resource must contain:
    (A) A reference, in the Organization.endpoint element, to the Endpoint resources containing service base URLs managed by this organization.
    (B) The organization's name, location, and facility identifier.
(iii) Endpoint and Organization resources must be:
    (A) Collected into a Bundle resource formatted according to the standard adopted in § 170.215(a) for publication; and
    (B) Reviewed quarterly and, as necessary, updated.

Thanks!

[AnalogJ]

related fastenhealth/fasten-sources#64