Clinical Document Collector API v1

Summary API Attachments FAQ CHANGE LOG     


Help Improve Operations and Payment Accuracy

Make medical record retrieval easy with our API. Real-time access to clinical documents helps you: better manage risk adjustment; improve interventions, HEDIS scores, and plan designs; reduce wasteful spending; and ensure accurate payments with faster adjudication.

You can access seven document types, including:

  • Continuity of care
  • Consultation notes
  • Discharge summary
  • History and physical
  • Operative notes
  • Progress notes
  • Procedure notes

Our network consists of more than 90 million individuals and it is expanding at a rate of three-to-five million monthly┬╣.

Features and Benefits:

  • An industry-standard API interface integrates our platform into the native workflows of your analytics and risk-management platforms and into your care-coordination and quality-management systems.
  • Our plug-and-play API minimizes your technical investment and expedites use of our service.
  • Accessing and collecting clinical documents electronically (vs. manually) helps enhance the security of PHI.

┬╣Change Healthcare internal statistics


The Clinical Document Collector provides access to patient clinical documents from remote, authoritative data repositories.

To support this functionality, this service implements a profiled Task resource that provides the vehicle for submitting a request for document retrieval, as well as the patient information and provider information necessary to locate documents. The Task itself serves to communicate progress information to the data requestor, including the location of the retrieved documents once the Task is completed.

Access Control via Web Tokens

All Change Healthcare Enterprise APIs on this platform are secured using JSON Web Tokens (JWT).

Security via TLS

All calls to Change Healthcare APIs are encrypted over HTTPS. Our APIs support connections using TLS version 1.2 or higher.

Authorization via OAuth2

Access to Change Healthcare APIs is controlled via OAuth2 using the client credentials grant. This is a secure authorization workflow that allows consumers to obtain a short-lived (one hour) access token that must be transmitted with subsequent API requests.

To obtain a token, consumers first need a client_id and client_secret, credentials provided during the customer onboarding process. To request access credentials, please complete a sandbox access request for Clinical Network, contact or use the 'Contact Us' link to contact the Product Manager of a specific API.

Obtaining an access token

The following documentation describes how to get an access token in a particular environment. Note that Your-ClientId and Your-ClientSecret should be replaced with a valid set of credentials. Also note that the URL is environment-specific and may need to be modified according to the target environment.

curl -X POST \
  https://${EDGE_HOSTNAME}/apip/auth/v2/token \
  -H 'Content-Type: application/json' \ 
  -d '{ "client_id": "<Your-ClientId>", "client_secret": "<Your-ClientSecret>", "grant_type": "client_credentials" }'

A successful call to this API will return a new access_token, which can be used to authorize subsequent calls to other APIs on the platform. By default, the access_token will be valid for one hour from the time of its issuance.

Example response:

    "access_token": "eyJraWQiOiIxIiwidHlwIjoiSldUIiwiYW...",
    "token_type": "bearer",
    "expires_in": 3600

The access token returned in the above response can be used to access APIs on this platform that are secured via the standard Authorization implementation. Calls to these APIs must include the following headers:

Content-Type: application/json
Authorization: Bearer <Your-Access-Token>

Is this API FHIR R4 compliant?

Yes. The implementation is documented in the Capability Statement available at the /metadata endpoint.

Do I need an authorization token to retrieve the Capability Statement?

No. Per the FHIR specification, the /metadata endpoint does NOT require authorization.

Is HTTPS required for all transaction?

Yes, all transactions with the service MUST use TLS.

Are any of the resources based on profiles?

Yes, the Task resource is profiled to constrain the intent property and to require a contained Patient resource holding the demographic data for patient matching.

Does the FHIR server use particular coding systems?

The input and output property types of the Task resource are described using value sets defined for this implementation.

What types of clinical data is returned by Clinical Document Collector?

This depends on the capabilities of the data providers, but the documents will typically be Consolidated CDA documents in XML format.

Change Log

API Name API Version Date Introduced Available Until
Clinical Document Collector v1 08/01/2020 Current

Release Notes:


  • Initial offering of the Clinical Document Collector FHIR server.
  • Documentation includes instructions for new and legacy implementations.