The Interoperability and Patient Access rule (CMS-0115-F) defines requirements for free and secure data flow that allows patients access to their health information.  Group Health Cooperative of South Central Wisconsin, working with our partners, has created service endpoints to meet these requirements through the Patient Access API and Provider Directory API described below.


Patient Access API

The Patient Access API is an HL7 FHIR-based API.  To begin developing applications that leverage this API start by reviewing the standards used to make the data available:
GHC-SCW allows patients to access their clinical and claims data via industry standard FHIR APIs.   This data is available via the set of FHIR API servers listed below: 

Data Type​​​​
​FHIR Server Base URL
​API Documentation
​Clinical Data, Medical Claims
(ExplanationOfBenefits.Search & ExplanationOfBenefits.Read)

Pharmacy Claims​ ​​​See above

Access to these APIs servers is managed by a single OAuth 2.0 authorization server.  This allows a patient to authorize your application once for all data managed by GHC-SCW, regardless of which API server contains the data.  In OAuth 2.0 terms, this is using a single access token for two “audiences”.   

As an app developer, you have two options for connecting your app to these API servers:  

[Preferred] Support one-time authorization for all data managed by GHC-SCW:

This option provides for an improved patient experience, as the patient only needs to authorize your app once to allow your app to download data from both API servers.  However, this does require your app to specifically support multiple API servers associated with a single authorization server. 

To implement this option, your app should use the SMART on FHIR Standalone Launch sequence.  The patient can authorize your app to access their data managed by GHC-SCW.  Your app will be issued an access token granting access to the data authorized by the patient.  Your app can use that access token to perform API calls against all API servers associated with GHC-SCW. 

App Development Steps 
  1. Register your application on
    1. This registration will apply to all API servers.​
    2. Register scopes for all APIs you want to access from any API server. For purposes of Interoperability and Patient Access, the scopes would be ExplanationOfBenefit.Read and ExplanationOfBenefit.Search.
  2. Implement the SMART on FHIR Standalone Launch flow in your app. 
  3. Load the API server endpoints you intend to connect to.  You can select from the endpoints listed on and the non-Epic endpoints listed above. 
Note: For the convenience of the patient, you may want to group endpoints from the same organization in to one UI selection element.  For example, the patient would see a UI element to connect to GHC-SCW, but your app would have a behind-the-scenes relationship between the patient-visible to GHC-SCW and the list of API endpoints you will query for data. 

Run-time Data Access Steps 
  1. Present the patient with the endpoints or organization they want to download their data from. 
  2. Initiate the SMART on FHIR Standalone Launch flow with the OAuth2 authorization server associated with the endpoint. 
  3. Perform API requests against each API server associated with the organization. 
    1. ​Use the same access token issued during the Standalone Launch flow for both API servers. 
    2. Use the same patient FHIR ID communicated during the Standalone Launch flow for both API servers.  

[Discouraged] Require per-API server authorization. 

This option provides a suboptimal user experience, as the patient must authorize your app for each API server independently.   
To implement this option, your app would initiate the SMART on FHIR Standalone Launch flow once for each API server.  

Provider Directory API

The Provider Directory API is publicly available and does not require application registration or authentication.  The endpoint for this API is:


The following FHIR Resources are available through that endpoint:
  • ​Location
  • Organization
  • Practitioner
  • PractitionerRole

Machine readable files - transparency in coverage

Visit to access publicly available machine-readable files as required by the Transparency in Coverage Final Rule.