Introduction

The Paragon.Open.API Server API documentation provides information for searching and fetching patient data from the Common Clinical Data Set as defined by the Meaningful Use 3 2015 regulations. Data search and read are the only interactions currently supported. The search criteria are intended to meet the 2015 Edition ONC Certification criterion Patient Selection 170.315(g)(7), Category Search 170.315(g)(8) and All Category Search 170.315(g)(9). Access is based on the HL7 FHIR® Data Access Framework (DAF) profile and draws requirements from DSTU2. Generally, only required DSTU2 data elements are provided.

Systems Requesting Information from Paragon.Open.API Servers

Paragon.Open.API Server service uses the Restful based service architecture which allows seamless integration over the HTTPS protocol. This means that any client that can communicate over HTTPS can easily communicate with the Paragon.Open.API Server service. Such communication across physical and logical barriers such as firewalls, etc. is much easier to facilitate and manage. Most companies already have ports open for such communication which facilitates easier configuration for Paragon®. It is straightforward for any client request to communicate with a Paragon.Open.API service as the call to the operation essentially entails the building of a URL string to call an operation in the service. Data passed to the operation can be in JSON or XML. A requestor can use the Paragon.Open.API endpoint to request a response. https://openapiargonaut.paragoncloudservices.net/dstu2/.

Paragon.Open.API Server

Paragon.Open.API servers are capable of returning all the resources that make up the Common Clinical Data Set defined in the 2015 Edition ONC Certification criterion.

The data can be retrieved for each resource using search by patient id or search by a patient identifier token comprised of a facility OID and EPN for the patient.

  • GET https://[base_url]/ResourceName?patient/PATV01-123456
  • GET https://[base_url]/ResourceName?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|PATV01-123456

The server returns valid Paragon.Open.API resources according to the Data Access Framework (DAF) Patient Profile.
The server returns the must support elements defined in the DAF profile version DSTU2 when available.
The server ensures that every API request includes a valid Authorization token, supplied via the Authorization header.

Return Codes Supported by the Paragon.Open.API Server

Status 200 – Valid response
Status 400 – Invalid parameter
Status 401 – Unauthorized request
Status 404 – Resource not found

Patient Authorization

Paragon® Patients who want to access their Common Clinical Data Set records through Paragon’s Open API Service can initiate a request by following a few easy steps. Patients need to create a user name and password that the OpenAPI Service can use to authenticate requests for their data.

Patients can contact their hospital’s Medical Records Department or they may be asked at the end of a current visit if they would like to sign up. Patients will be sent an email to the email address on file at their hospital.

Patients click on the link sent in the email which will open a sign on screen allowing them to set a user name and password as well as reset passwords that have been forgotten. The user name will be in the domain for the hospital that they are associated with. For Example: JohnSmith123@paragon.hospital.com

SMART APP Authorization

Hospitals that want to employ a SMART APP may register the applications as authorized applications for hospital use. The McKesson Services organization will manage that registration once the application has been vetted and licensed per normal hospital policy and processes. Contact your local hospital to get details and schedule that work.

Hospital Registration

Hospitals must register their domain name in the registry for the Paragon.Open.API Service to know where to route requests for data and authenticate requests for data. The McKesson Services team assigned to the hospital will work with each hospital to register their domain in the customer registry. Please contact your local hospital for more details.

Patient Access outside of the EHR Workflow

Coming Soon! This workflow is currently being tested.

Patients may access their data from a Paragon® Hospital without registering the application with their hospital as long as the patient is registered with the hospital. A SMART APP installed on their phone or PC can be used to retrieve their Common Clinical Data Set records by following these steps.

Patients must be known to the hospital by following the patient authorization workflow described above in order to employ this implicit application authentication workflow.

Use a Smart App to contact the Paragon.Open.Api server at the following URL: https://openapiargonaut.paragoncloudservices.net/dstu2/

The Smart App first requests the Paragon.Open.Api conformance statement using the published endpoint URL from this document. Next, the Smart App reads the conformance statement and gets the Paragon.Open.Api Authorization Server endpoint and the token endpoint. Then the Smart App uses the Authorization Server endpoint to request ‘Implicit’ code grant work flow privileges from Paragon.Open.Api. When the Smart App Client sets the grant type request to ‘Implicit’, Paragon.Open.Api bypasses checking if the client (application) is authorized and only authorizes patient. Paragon.Open.API then presents the Patient Authorization Login Screen.

Patient enters their user name and password which exists in the patient Active Directory. User name will be comprised of a name selected by the user followed by their hospital domain name.

The domain name portion of the user name directs Paragon.Open.Api to the Paragon® hospital where the patient Active Directory data resides. Once authenticated, the grant screen is presented indicating to the patient which grants are available to them for data access. Currently patient/*. read is supported and only returns data that is part of the Common Clinical Data Set. Update, Write and Delete are not supported.

Patient clicks on grant button and then the app can send requests for the patient data following our supported specifications outlined in the conformance statement.

More to Come! Paragon.Open.API plans to provide a developer sandbox so that developing applications can test against our data. This is planned for a future release of Paragon® sometime after 14.1

Patient Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/Patient/[id]

Examples:

  • GET https://[base_url]/Patient/PATV01-123456

Supported Interaction: SearchType

Implementation Notes: Demographic searches require at least two criteria that are not redundant variables such as name and address or family and gender and birthdate. Redundant searches such as family with name and given with name are not supported.

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The id is the EPN of the person. Example of supported search syntax for a patient is GET https://[base-url]/patient?_id=PATV01-123456. A successful search will return a single patient resource in a bundle valued with the available must support elements of the DAF DSTU2 FHIR® specification.

Supported Search: identifier

  • Supported DataType: Token
  • Implementation Notes: The identifier for the patient resource is a token comprised of an OID and the EPN of the person. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. An example of a supported search syntax for a patient using identifier is GET https://[base-url]/patient?identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-123456

Supported Search: name

  • Supported DataType: String
  • Implementation Notes: A portion of either family or given name of the patient.

Supported Search: family

  • Supported DataType: String
  • Implementation Notes: A portion of the family name of the patient. When the exact modifier is used only records matching the 'exact' characters and text case are returned. When the 'exact' modifier is not used, records starting with the search value (in any text case) in the query are returned. Paragon OPEN API requires a minimum of 4 demographic search parameters to match explicitly in order to return patient ids. Those search parameters are given, family, birthday and gender to return patient ids from demographic searches.
  • Supported Search Modifiers: Exact

Supported Search: given

  • Supported DataType: String
  • Implementation Notes: A portion of the given name of the patient. When the exact modifier is used only records matching the 'exact' characters and text case are returned. When the 'exact' modifier is not used, records starting with the search value (in any text case) in the query are returned. Paragon OPEN API requires a minimum of 4 demographic search parameters to match explicitly in order to return patient ids. Those search parameters are given, family, birthday and gender to return patient ids from demographic searches.
  • Supported Search Modifiers: Exact

Supported Search: gender

  • Supported DataType: Token
  • Implementation Notes: Gender of the patient. Values male, M, female, F, unknown and U (from http://hl7.org/fhir/administrative-gender) are supported. Paragon OPEN API requires a minimum of 4 demographic search parameters to match explicitly in order to return patient ids. Those search parameters are given, family, birthday and gender to return patient ids from demographic searches.
  • Supported Search Modifiers: In

Supported Search: birthdate

  • Supported DataType: Date
  • Implementation Notes: The patient's date of birth. The date format of YYYY-MM-DD is the format supported for birthdate searches. Time based birthdate searches are not supported. The prefix of eq is supported for exact birthday searches. An absence of a prefix implies eq search per FHIR rules. Paragon OPEN API requires a minimum of 4 demographic search parameters to match explicitly in order to return patient ids. Those search parameters are given, family, birthday and gender to return patient ids from demographic searches.

Supported Search: _count

  • Supported DataType: Number
  • Implementation Notes: The parameter _count is defined as a hint to the server regarding how many resources should be returned in a single page. Servers SHALL NOT return more resources than requested, even if they don't support paging, but are allowed to return less than the client requested. Paragon® may return less than the number of resources specified in the _count when there are less responses than requested in the database or the web config max response setting is set to a value less than the _count requested. Paragon® supports a default web configuration for the max number of resources to return. The Paragon.Open.API server will never return more resources than what is defined in that configuration regardless of what is sent in the _count or if _count is not present.

Supported Search: _lastUpdated

  • Supported DataType: Date
  • Implementation Notes: The lastUpdated search parameter searches for the date the Patient was last modified. The lastUpdated parameter is supported in the Patient resource for date, datetime and instant date formats, including the standard XML format of yyyy-mm-ddThh:mm:ss[Z|(+|-)hh:mm]. The prefixes of lt, gt, le, ge and eq are all supported for date search. The only prefixes supported in date range search are the combination of ge and le. Both dates in the combination must be of the same format. Search by date without a prefix will default to ‘eq’ prefix behavior.

Supported Search: address-city

  • Supported DataType: Token
  • Implementation Notes: A city specified in an address.

Supported Search: address-postalcode

  • Supported DataType: Token
  • Implementation Notes: A postalCode specified in an address.

Supported Search: address-state

  • Supported DataType: Token
  • Implementation Notes: A state specified in an address.

Supported Search: telecom

  • Supported DataType: Token
  • Implementation Notes: The value in any kind of telecom details of the patient. Only System types 'phone', 'fax' and 'email' are supported.

URL Syntax:

  • GET [base_url]/Patient?identifier=[system OID]|[id]
  • GET [base_url]/Patient?_id=[id]

Examples:

  • GET https://[base_url]/Patient?identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456
  • GET https://[base_url]/Patient?_id=PATV01-123456

MedicationOrder Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/MedicationOrder/[id]

Examples:

  • GET https://[base_url]/MedicationOrder/MEDO01-123456
  • GET https://[base_url]/MedicationOrder/MEDO02-123456

Supported Interaction: SearchType

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The _id is the primary key of the medication order. Some prescriptions have multiple primary keys and others do not. One example of a supported search syntax for a medication order is GET https://[base-url]/medicationorder?_id=MEDO01-123456 and another example is https://[base-url]/medicationorder?_id=MEDO02-468241-876541. A successful search will return a single medication order resource in a bundle valued with the available must support elements of the DAF DSTU2 FHIR® specification.

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958

Supported Search: status

  • Supported DataType: String
  • Implementation Notes: Currently the only MedicationOrder status filter being supported by our product is = ‘active’.

Supported Search: _lastUpdated

  • Supported DataType: Date
  • Implementation Notes: The lastUpdated search parameter searches for the date the MedicationOrder was last modified. This parameter only supports the use of prefix gt (greater than).

Supported Search: datewritten

  • Supported DataType: Date
  • Implementation Notes: The date written search parameter is supported in the MedicationOrder resource for date datatypes only. The prefixes of lt, gt, le, ge and eq are all supported for datewritten searches. The only prefixes supported in date range searches are the combination of ge and le. Search by date without a prefix will default to ‘eq’ prefix behavior. If no prefix is provided it will be considered to be eq. Date only format (ex. 2016-06-20) is accepted.

URL Syntax:

  • GET [base_url]/MedicationOrder?patient.identifier=[system OID]|[id]
  • GET [base_url]/MedicationOrder?patient=[id]
  • GET [base_url]/MedicationOrder?_id=[id]

Examples:

  • GET https://[base_url]/MedicationOrder?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456
  • GET https://[base_url]/MedicationOrder?patient=PATV01-123456>
  • GET https://[base_url]/MedicationOrder?_id=MEDO01-123456
  • GET https://[base_url]/MedicationOrder?_id=MEDO02-123456

Condition Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/Condition/[id]

Examples:

  • GET https://[base_url]/Condition/COND01-123456

Supported Interaction: SearchType

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The _id is the primary key of the condition. Some resources have multiple data sources and use unique prefixes to differentiate them. One example of a supported search syntax for a condition resource is GET https://[base-url]/condition?_id=COND01-123456. Another example of a supported search is GET https://[base-url]/condition?_id=COND02-123457. A successful search will return a single condition resource in a bundle valued with the available must support elements of the DAF DSTU2 FHIR® specification.

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958

Supported Search: _lastUpdated

  • Supported DataType: Date
  • Implementation Notes: The lastUpdated search parameter searches for the date the Condition was last modified. This parameter only supports the use of prefix gt (greater than).

Supported Search: date-recorded

  • Supported DataType: Date
  • Implementation Notes: The date-recorded search parameter is the date when the condition statement was documented. This date search parameter is supported in date, datetime, instant date formats in compliance with FHIR® date search rules. For example partial date searches are supported. The prefixes of lt, gt, le, ge and eq are all supported for date searches. The only prefixes supported in date range searches are the combination of ge and le. Both dates in the combination must be of the same format. Search by date without a prefix will default to ‘eq’ prefix behavior. This date search parameter cannot be called in the same query as the lastUpdated search parameter. They are mutually exclusive searches.

Supported Search: category

  • Supported DataType: Token
  • Implementation Notes: The Condition resource can be queried by condition.category where the token code is either 'health-concern' or 'problem'

Supported Search: clinicalstatus

  • Supported DataType: String
  • Implementation Notes: The clinical status search parameter is supported in Condition resource for status of active, resolved and relapse only. Multiple clinical statuses can be searched at the same time by separating the statuses with a comma (Example: &clinicalstatus=relapse,active).

URL Syntax:

  • GET [base_url]/Condition?patient.identifier=[system OID]|[id]
  • GET [base_url]/Condition?_id=[id]

Examples:

  • GET https://[base_url]/Condition?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456
  • GET https://[base_url]/Condition?_id=COND01-123456

AllergyIntolerance Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/AllergyIntolerance/[id]

Examples:

  • GET https://[base_url]/AllergyIntolerance/ALG01-123456

Supported Interaction: SearchType

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958

Supported Search: _lastUpdated

  • Supported DataType: Date
  • Implementation Notes: The lastUpdated search parameter searches for the date the AllergyIntolerance was last modified. This parameter only supports the use of prefix gt (greater than).

Supported Search: date

  • Supported DataType: Date
  • Implementation Notes: The date represents when the Allergy was recorded. The date search parameter is supported in the AllergyIntolerance resource for date, datetime, instant date formats in compliance with FHIR® date search rules. For example partial date searches are supported. The prefixes of lt, gt, le, ge and eq are all supported for date searches. The only prefixes supported in date range searches are the combination of ge and le. Both dates in the combination must be of the same format. Search by date without a prefix will default to ‘eq’ prefix behavior. This date search parameter cannot be called in the same query as the lastUpdated search parameter. They are mutually exclusive searches.

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The _id is the primary key of the allergy. Some resources have multiple data sources and use unique prefixes to differentiate them. One example of a supported search syntax for an AllergyIntolerance resource is GET https://[base-url]/allergyIntolerance?_id=ALGO01-76543. A successful search will return a single allergy resource in a bundle valued with the available must support elements of the DAF DSTU2 FHIR® specification.

Supported Search: status

  • Supported DataType: Token
  • Implementation Notes: The status search parameter is supported in AllergyIntolerance resource for status of active and inactive only. Multiple statuses can be searched at the same time by separating the statuses with a comma (Example: &clinicalstatus=active,inactive). If no status parameter is specified, only active allergies will be returned.

URL Syntax:

  • GET [base_url]/AllergyIntolerance?patient.identifier=[system OID]|[id]
  • GET [base_url]/AllergyIntolerance?patient=[id]
  • GET [base_url]/AllergyIntolerance?_id=[id]

Examples:

  • GET https://[base_url]/AllergyIntolerance?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456
  • GET https://[base_url]/AllergyIntolerance?patient=PATV01-123456
  • GET https://[base_url]/AllergyIntolerance?_id=ALG01-123456

FamilyMemberHistory Resource

Supported Interaction: SearchType

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958

URL Syntax:

  • GET [base_url]/FamilyMemberHistory?patient.identifier=[system OID]|[id]

Examples:

  • GET https://[base_url]/FamilyMemberHistory?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456

MedicationStatement Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/MedicationStatement/[id]

Examples:

  • GET https://[base_url]/MedicationStatement/MEDS01-123456
  • GET https://[base_url]/MedicationStatement/MEDS02-123456
  • GET https://[base_url]/MedicationStatement/MEDS03-123456

Supported Interaction: SearchType

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The _id is the primary key of the MedicationStatement Resource. There are three types of medication statements in Paragon®, those for home meds, those for prearrival meds and those for recreational drugs. Each has a unique prefix to differentiate them. Recreational drugs id prefix is MEDS01-, home meds prefix is MEDS02- and pre arrival drugs prefix is MEDS03-. One example of a supported search syntax for a medication statement resource is GET https://[base-url]/medicationstatement?_id=MEDS01-491. A successful search will return a single medication statement resource in a bundle valued with the available must support elements of the DAF DSTU2 FHIR® specification. The medication statement resource supports a resource id (_id) search modifier of 'contains' but only for the MEDS02 prefixed id records.
  • Supported Search Modifiers: Contains

Supported Search: date

  • Supported DataType: Date
  • Implementation Notes: The date a medication/drug was started (the start date portion of the effective date period). Valid prefixes are eq,gt,lt,ge,le. If no prefix is provided it will be considered to be eq. Date only format (ex. 2016-06-20) is accepted. The combination of ge/le is the only supported combination of prefixes. ( ex. dstu2/MedicationStatement?patient=PATV01-486238&date=le2016-04-13&date=ge2016-04-11). Both dates in the combination must be of the same format. This parameter is not supported with the _lastUpdated.

Supported Search: _lastUpdated

  • Supported DataType: Date
  • Implementation Notes: The lastUpdated search parameter searches for the date the Medication Statement was last modified. The search is by date, datetime and instant data types. Date in format of yyyy-mm-dd or datetime in format of yyyy-mm-ddThh:mm:ss or an instant in format of yyyy-mm-ddThh:mm:ss[Z|(+|-)hh:mm]. This parameter only supports the use of prefix gt (greater than).

URL Syntax:

  • GET [base_url]/MedicationStatement?patient.identifier=[system OID]|[id]
  • GET [base_url]/MedicationStatement?patient=[id]
  • GET [base_url]/MedicationStatement?_id=[id]

Examples:

  • GET https://[base_url]/MedicationStatement?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456
  • GET https://[base_url]/MedicationStatement?patient=PATV01-123456
  • GET https://[base_url]/MedicationStatement?_id=MEDS01-123456
  • GET https://[base_url]/MedicationStatement?_id=MEDS02-123456
  • GET https://[base_url]/MedicationStatement?_id=MEDS03-123456

Observation Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/Observation/[id]

Examples:

  • GET https://[base_url]/Observation/VITL01-123456
  • GET https://[base_url]/Observation/VITL02-123456
  • GET https://[base_url]/Observation/VITL03-123456

Supported Interaction: SearchType

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958

Supported Search: category

  • Supported DataType: String
  • Implementation Notes: category = vital-sign

Supported Search: _lastUpdated

  • Supported DataType: Date
  • Implementation Notes: The lastUpdated search parameter searches for the date the Observation was last modified. The search is by date, datetime and instant data types. Date in format of yyyy-mm-dd or datetime in format of yyyy-mm-ddThh:mm:ss or an instant in the format of yyyy-mm-ddThh:mm:ss[Z|(+|-)hh:mm]. This parameter only supports the use of prefix gt (greater than).

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The _id is the primary key of the vital signs. One example of a supported search syntax for a observation resource is GET https://[base-url]/observation?_id=VITL01-123456. A successful search will return a single observation resource in a bundle valued with the available must support elements of the DAF DSTU2 FHIR® specification.

Supported Search: date

  • Supported DataType: Date
  • Implementation Notes: The date search in the Observation correlates to the effective date and time which, for the vital signs, is the date that the vital signs was observed or charted. Valid prefixes are eq, gt, lt, ge, le. If no prefix is provided it will be considered to be eq. The combination of ge/le is the only supported combination of prefixes. (ex.&date=le2016-07-22&date=ge2016-07-19). Both dates in the combination must be of the same format. The Observation resource for vital signs supports search by issued date in the format of a date data type of yyyy-mm-dd. Any date search query sent with a different data type or invalid date values will result in an operation outcome.

Supported Search: code

  • Supported DataType: String
  • Implementation Notes: The system supports search by LOINC® code for observations in the categories of vital-signs, labResults and social-history. When using the code parameter in the Observation resource, a category parameter is also required. Multiple codes can be searched at the same time by separating codes with a comma (Example:&code=12345-6, 345-9, 887-1&category=vital-signs).

URL Syntax:

  • GET [base_url]/Observation?patient.identifier=[system OID]|[id]
  • GET [base_url]/Observation?patient=[id]
  • GET [base_url]/Observation?_id=[id]

Examples:

  • GET https://[base_url]/Observation?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456
  • GET https://[base_url]/Observation?patient=PATV01-123456
  • GET https://[base_url]/Observation?_id=VITL01-123456
  • GET https://[base_url]/Observation?_id=VITL02-123456
  • GET https://[base_url]/Observation?_id=VITL03-123456

Observation Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/Observation/[id]

Examples:

  • GET https://[base_url]/Observation/LABS01-123456

Supported Interaction: SearchType

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958

Supported Search: category

  • Supported DataType: String
  • Implementation Notes: category = laboratory, which includes laboratory and microbiology

Supported Search: _lastUpdated

  • Supported DataType: Date
  • Implementation Notes: The lastUpdated search parameter searches for the date the Observation was last modified. The search is by date, datetime and instant data types. Date in format of yyyy-mm-dd or datetime in format of yyyy-mm-ddThh:mm:ss or an instant in the format of yyyy-mm-ddThh:mm:ss[Z|(+|-)hh:mm]. This parameter only supports the use of prefix gt (greater than).

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The _id is the primary key of the LabResults. One example of a supported search syntax for a observation resource is GET https://[base-url]/observation?_id=LABS01-123456. Another example is GET https://[base-url]/observation?_id=LABS02-56789>. A successful search will return a single observation resource in a bundle valued with the available must support elements of the DAF DSTU2 FHIR® specification.

Supported Search: date

  • Supported DataType: Date
  • Implementation Notes: The date the resource was originally collected. The date search parameter is supported in the Observation-Lab Results resource for date datatypes only. The prefixes of lt, gt, le, ge and eq are all supported for date searches. The only prefixes supported in date range searches are the combination of ge and le. Search by date without a prefix will default to ‘eq’ prefix behavior.

Supported Search: code

  • Supported DataType: String
  • Implementation Notes: The system supports search by LOINC® code for observations in the categories of vital-signs, labResults and social-history. When using the code parameter in the Observation resource, a category parameter is also required. Multiple codes can be searched at the same time by separating codes with a comma (Example:&code=12345-6, 345-9, 887-1&category=laboratory).

Supported Search: status

  • Supported DataType: Token
  • Implementation Notes: The search status parameter is supported for Laboratory Observations for FHIR® statuses of final, amended, registered, canceled, and preliminary. Entered in error status and unknown status are not supported. Multiple statuses can be searched at the same time by separating the statuses with a comma (Example: &status=final,amended). If no status parameter is included, only final and amended statuses will be returned.

URL Syntax:

  • GET [base_url]/Observation?patient.identifier=[system OID]|[id]
  • GET [base_url]/Observation?patient=[id]
  • GET [base_url]/Observation?_id=[id]

Examples:

  • GET https://[base_url]/Observation?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456
  • GET https://[base_url]/Observation?patient=PATV01-123456
  • GET https://[base_url]/Observation?_id=LABS01-123456

Observation Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/Observation/[id]

Examples:

  • GET https://[base_url]/Observation/SMOK01-123456>

Supported Interaction: SearchType

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958

Supported Search: category

  • Supported DataType: String
  • Implementation Notes: category = social-history

Supported Search: _lastUpdated

  • Supported DataType: Date
  • Implementation Notes: The lastUpdated search parameter searches for the date the Observation was last modified. The search is by date, datetime and instant data types. Date in format of yyyy-mm-dd or datetime in format of yyyy-mm-ddThh:mm:ss or an instant in the format of yyyy-mm-ddThh:mm:ss[Z|(+|-)hh:mm]. This parameter only supports the use of prefix gt (greater than).

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The _id is the primary key of the SocialHistory. One example of a supported search syntax for a observation resource is GET https://[base-url]/observation?_id=SMOK01-123456. A successful search will return a single observation resource in a bundle valued with the available must support elements of the DAF DSTU2 FHIR® specification.

Supported Search: code

  • Supported DataType: String
  • Implementation Notes: The system supports search by LOINC® code for observations in the categories of vital-signs, laboratory and social-history.

Supported Search: date

  • Supported DataType: Date
  • Implementation Notes: The date search in the Observation correlates to the effective date and time which, for the smoking status, is the date that the smoking status was observed or charted. Valid prefixes are eq, gt, lt, ge, le. If no prefix is provided it will be considered to be eq. The combination of ge/le is the only supported combination of prefixes. (ex.&date=le2016-07-22&date=ge2016-07-19). Both dates in the combination must be of the same format. The Observation resource for Smoking Status supports search by issued date in the format of a date data type of yyyy-mm-dd. Any date search query sent with a different data type or invalid date values will result in an operation outcome.

URL Syntax:

  • GET [base_url]/Observation?patient.identifier=[system OID]|[id]
  • GET [base_url]/Observation?patient=[id]
  • GET [base_url]/Observation?_id=[id]

Examples:

  • GET https://[base_url]/Observation?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456>
  • GET https://[base_url]/Observation?patient=PATV01-123456
  • GET https://[base_url]/Observation?_id=SMOK01-123456

Practitioner Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/Practitioner/[id]

Examples:

  • GET https://[base_url]/Practitioner/PRAC01-123456
  • GET https://[base_url]/Practitioner/PRAC02-123456

Supported Interaction: SearchType

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: Standard _id. It is the caregiver EPN.

URL Syntax:

  • GET [base_url]/Practitioner?_id=[id]

Examples:

  • GET https://[base_url]/Practitioner?_id=PRAC01-123456
  • GET https://[base_url]/Practitioner?_id=PRAC02-123456

Immunization Resource

Supported Interaction: SearchType

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958

Supported Search: _lastUpdated

  • Supported DataType: Date
  • Implementation Notes: The lastUpdated search parameter searches for the date the Immunization was last modified. This parameter only supports the use of prefix gt (greater than).

Supported Search: date

  • Supported DataType: Date
  • Implementation Notes: The date search for the Immunization resource is based on the date that the immunization was charted as administered or not administered. The date search parameter is supported in the Immunization resource for date datatypes only. Only the yyyy-mm-dd format is supported. Searches using the full XML standard format yyyy-mm-ddThh:mm:ss[Z|(+|-)hh:mm] are not supported. The prefixes of lt, gt, le, ge and eq are all supported for date searches. The only prefixes supported in date range searches are the combination of ge and le. Both dates in the combination must be of the same format. Search by date without a prefix will default to ‘eq’ prefix behavior. This date search parameter cannot be called in the same query as the lastUpdated search parameter. They are mutually exclusive searches.

Supported Search: status

  • Supported DataType: Token
  • Implementation Notes: The status search parameter is supported in the Immunization resource. Multiple statuses can be searched at the same time by separating the statuses with a comma (Example: &status=completed,stopped). Completed, stopped and entered-in-error status search parameters are supported and when no status search parameter is provided, only completed and stopped charted statuses will be returned.

URL Syntax:

  • GET [base_url]/Immunization?patient.identifier=[system OID]|[id]
  • GET [base_url]/Immunization?patient=[id]

Examples:

  • GET https://[base_url]/Immunization?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456>
  • GET https://[base_url]/Immunization?patient=PATV01-123456

Encounter Resource

Supported Interaction: SearchType

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958

URL Syntax:

  • GET [base_url]/Encounter?patient=[id]

Examples:

  • GET https://[base_url]/Encounter?patient=PATV01-123456

Location Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/Location/[id]

Examples:

  • GET https://[base_url]/Location/LOCN01-123456

Supported Interaction: SearchType

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The _id is the primary key of the location. Example of supported search syntax for a location is GET https://[base-url]/location?_id=LOCN01-123456. A successful search will return a single location resource in a bundle valued with the available must support elements of the DAF DSTU2 FHIR® specification.

URL Syntax:

  • GET [base_url]/Location?_id=[id]

Examples:

  • GET https://[base_url]/Location?_id=LOCN01-123456

Organization Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/Organization/[id]

Examples:

  • GET https://[base_url]/Organization/ORGN01-123456

Supported Interaction: SearchType

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The _id is the primary key of the organization. Example of supported search syntax for an organization is GET https://[base-url]/organization?_id=ORGN01-1234. A successful search will return a single organization resource in a bundle valued with the available must support elements of the DAF DSTU2 FHIR® specification.

URL Syntax:

  • GET [base_url]/Organization?_id=[id]

Examples:

  • GET https://[base_url]/Organization?_id=ORGN01-123456

DiagnosticReport Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/DiagnosticReport/[id]

Examples:

  • GET https://[base_url]/DiagnosticReport/DGRP01-123456

Supported Interaction: SearchType

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958

Supported Search: category

  • Supported DataType: Token
  • Implementation Notes: Diagnostic Report supports queries based on a search by parameter of category either LAB or MB or parameters of category either LAB or MB and code where the code is LOINC®, or just by parameter of code where the code is a LOINC® code.

Supported Search: code

  • Supported DataType: Token
  • Implementation Notes: Diagnostic Report supports queries based on a search by parameter of category either LAB or MB or parameters of category either LAB or MB and code where the code is LOINC®, or just by parameter of code where the code is a LOINC® code.

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The _id is the primary key of the DiagnosticReport Resource. There are two types of diagnostic reports in Paragon®, those for Microbiology and those for Lab. Each has a unique prefix to differentiate them. Microbiology id prefix is DGRP01- and Lab prefix is DGRP02-. One example of a supported search syntax for a diagnostic report resource is https://[base-url]/diagnosticreport?_id=DGRP01-491. A successful search will return a single Diagnostic Report resource in a bundle valued with the available must support elements of the DAF DSTU2 FHIR® specification.

Supported Search: date

  • Supported DataType: Date
  • Implementation Notes: The date the Diagnostic Report was originally released. Valid prefixes are eq, gt, lt, ge, le. If no prefix is provided it will be considered to be eq. The combination of ge/le is the only supported combination of prefixes. (ex.&date=le2016-07-22&date=ge2016-07-19). Both dates in the combination must be of the same format. The Diagnostic Report resource supports search by issued date (the date the report was released) in the format of a date data type of yyyy-mm-dd.

URL Syntax:

  • GET [base_url]/DiagnosticReport?patient.identifier=[system OID]|[id]
  • GET [base_url]/DiagnosticReport?patient=[id]
  • GET [base_url]/DiagnosticReport?_id=[id]

Examples:

  • GET https://[base_url]/DiagnosticReport?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456
  • GET https://[base_url]/DiagnosticReport?patient=PATV01-123456
  • GET https://[base_url]/DiagnosticReport?_id=DGRP01-123456

Procedure Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/Procedure/[id]

Examples:

  • GET https://[base_url]/Procedure/PROC01-123456

Supported Interaction: SearchType

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958. Procedure resources with entered-in-error status are not returned.

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958. Procedure resources with entered-in-error status are not returned.

Supported Search: _lastUpdated

  • Supported DataType: Date
  • Implementation Notes: The lastUpdated search parameter searches for the date the Procedure was last modified. This parameter only supports the use of prefix gt (greater than).

Supported Search: date

  • Supported DataType: Date
  • Implementation Notes: The date search for Procedure is for the date the procedure was performed if available. If the obtained element is a period, a date that falls in the period. Valid prefixes are eq, gt, lt, ge, le. If no prefix is provided it will be considered to be eq. Date only format (ex. 2016-06-20) is accepted. The combination of ge/le is the only supported combination of prefixes. (ex. &date=ge2016-06-20&date=le2016-07-01). Both dates in the combination must be of the same format. This date search parameter cannot be called in the same query as the lastUpdated search parameter. They are mutually exclusive searches.

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The _id is the primary key of the procedure. One example of a supported search syntax for a procedure resource is GET https://[base-url]/procedure?_id=PROC01-123456. A successful search will return a single procedure resource in a bundle valued with the available must support elements of the DAF DSTU2 FHIR® specification.

Supported Search: status

  • Supported DataType: String
  • Implementation Notes: The Procedure status filters that are supported are 'in-progress', 'completed', and 'aborted'. An example of a status filter is https://[base-url]/Procedure?PATV01-123456&status=in-progress. Multiple statuses can be searched at the same time by separating the statuses with a comma (example: &status=in-progress,completed). Procedure resources with status of entered-in-error are always excluded.

URL Syntax:

  • GET [base_url]/Procedure?patient.identifier=[system OID]|[id]
  • GET [base_url]/Procedure?patient=[id]
  • GET [base_url]/Procedure?_id=[id]

Examples:

  • GET https://[base_url]/Procedure?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456
  • GET https://[base_url]/Procedure?patient=PATV01-123456
  • GET https://[base_url]/Procedure?_id=PROC01-123456

Device Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/Device/[id]

Examples:

  • GET https://[base_url]/Device/DEVC01-123456

Supported Interaction: SearchType

Supported Search: _id

  • Supported DtaType: String
  • Implementation Notes: The _id is the primary key of the device. A successful search will return a single device resource in a bundle valued with the available must support elements of the DSTU2 FHIR® specification.

Supported Search: ;patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958

Supported Search: _lastUpdated

  • Supported DataType: Date
  • Implementation Notes: The Device lastUpdated search parameter is the date when the Device information was last updated. Valid prefixes are eq, gt, lt, ge, le. If no prefix is provided it will be considered to be eq. Date only (ex. 2016-06-20) is the only date format accepted. The combination of ge/le is the only supported combination of prefixes. (ex. &_lastUpdated=ge2016-06-20&_lastUpdated=le2016-07-01).

URL Syntax:

  • GET [base_url]/Device?patient.identifier=[system OID]|[id]
  • GET [base_url]/Device?patient=[id]
  • GET [base_url]/Device?_id=[id]

Examples:

  • GET https://[base_url]/Device?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456
  • GET https://[base_url]/Device?patient=PATV01-123456
  • GET https://[base_url]/Device?_id=DEVC01-123456

CarePlan Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/CarePlan/[id]

Examples:

  • GET https://[base_url]/CarePlan/CRPL01-123456
  • GET https://[base_url]/CarePlan/CRPL02-123456

Supported Interaction: SearchType

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The _id is the primary key of the CarePlan Resource. There are two types of care plan statements in Paragon®, those for care plan and those for care team. Each has a unique prefix to differentiate them. CarePlan id prefix is CRPL01- and CareTeam prefix is CRPL02-. One example of a supported search syntax for a care plan resource is https://[base-url]/careplan?_id=CRPL01-491. A successful search will return a single CarePlan resource in a bundle valued with the available must support elements of the DSTU2 FHIR® specification.

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958

Supported Search: category

  • Supported DataType: Token
  • Implementation Notes: Care plan supports queries based on a search by parameter of category either assess-plan or careteam or both

Supported Search: 0;_lastUpdated

  • Supported DataType: Date
  • Implementation Notes: The careplan resource can be queried by last updated date and date range. Only the date format of YYYY-MM-DD is supported. The prefixes of lt, gt, le, ge and eq are all supported for date search. The only prefixes supported in date range search are the combination of ge and le. Both dates in the combination must be of the same format.

URL Syntax:

  • GET [base_url]/CarePlan?patient.identifier=[system OID]|[id]
  • GET [base_url]/CarePlan?patient=[id]
  • GET [base_url]/CarePlan?_id=[id]

Examples:

  • GET https://[base_url]/CarePlan?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456
  • GET https://[base_url]/CarePlan?patient=PATV01-123456
  • GET https://[base_url]/CarePlan?_id=CRPL01-123456
  • GET https://[base_url]/CarePlan?_id=CRPL02-123456

Goal Resource

Supported Interaction: Read

URL Syntax:

  • GET [base_url]/Goal/[id]

Examples:

  • GET https://[base_url]/Goal/GOAL01-123456

Supported Interaction: SearchType

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958

Supported Search: _lastUpdated

  • Supported DataType: Date
  • Implementation Notes: The Goal date search parameter is the date when the Goal information was last updated. Valid prefixes are eq, gt, lt, ge, le. If no prefix is provided it will be considered to be eq. Date only (ex. 2016-06-20) is the only date format accepted. The combination of ge/le is the only supported combination of prefixes. (ex. &date=ge2016-06-20&date=le2016-07-01).

Supported Search: _id

  • Supported DataType: String
  • Implementation Notes: The _id is the primary key of the goal. Example of supported search syntax for a goal is GET https://[base-url]/goal?_id=GOAL01-1234. A successful search will return a single goal resource in a bundle valued with the available must support elements of the DAF DSTU2 FHIR® specification.

URL Syntax:

  • GET [base_url]/Goal?patient.identifier=[system OID]|[id]
  • GET [base_url]/Goal?patient=[id]
  • GET [base_url]/Goal?_id=[id]

Examples:

  • GET https://[base_url]/Goal?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456
  • GET https://[base_url]/Goal?patient=PATV01-123456
  • GET https://[base_url]/Goal?_id=GOAL01-123456

DocumentReference Resource

Supported Interaction: SearchType

Supported Search: patient.identifier

  • Supported DataType: Token
  • Implementation Notes: Standard patient identifier. The first part of the token is the assigning authority OID. The second part of the token is the patient EPN. For example, ?patient.identifier=urn:oid:2.16.40.1.11383.3.281.4359.1|PATV01-482958 Paragon® does not store CDA® documents, so CDA® documents will be generated upon request based on the most recent visit information. Also, documents will not be searchable based upon a unique document identifier.

Supported Search: patient

  • Supported DataType: String
  • Implementation Notes: Standard patient identifier. The parameter being passed is the patient EPN. For example, ?patient=PATV01-482958 Paragon® does not store CDA® documents, so CDA® documents will be generated upon request based on the most recent visit information. Also, documents will not be searchable based upon a unique document identifier.

Supported Search: type

  • Supported DataType: String
  • Implementation Notes: The type is the LOINC® code for a specific document type. A successful search will return a single Document Reference resource in a bundle valued with the available must-support elements of the FHIR® specification. At this time, we currently only support 34133-9 (Summary of episode note) document type. Example: https://[base-url]/DocumentReference?type=34133-9&patient=PATV01-486679 />.

Supported Search: period

  • Supported DataType: Date
  • Implementation Notes: The period (admission date only) search parameter is supported in the DocumentReference resource for date datatypes only. The prefixes of lt, gt, le, ge and eq are all supported for period searches. The only prefixes supported in date range searches are the combination of ge and le. If no prefix is provided it will be considered to be eq. Date only format (ex. 2016-06-20) is accepted.

Supported Search: created

  • Supported DataType: Date
  • Implementation Notes: The created search parameter is supported in the DocumentReference resource for date datatypes only and only for CDAs that had been generated and stored in the Paragon database. For CDAs generated on the fly the date search uses the Period Search Param. The only prefixes supported in date range searches are the combination of ge and le. If no prefix is provided it will be considered to be eq. Date only format (ex. 2016-06-20) is accepted.

URL Syntax:

  • GET [base_url]/DocumentReference?patient.identifier=[system OID]|[id]
  • GET [base_url]/DocumentReference?patient=[id]

Examples:

  • GET https://[base_url]/DocumentReference?patient.identifier=urn:oid:2.16.840.1.113883.3.271.4358|123456
  • GET https://[base_url]/DocumentReference?patient=PATV01-123456

Terms of Use

Introduction

The Office of the National Coordinator for Health Information Technology (ONC) set forth certain requirements, including requirements for interoperability, for electronic health record (EHR) software to meet in order to be certified EHR technology for the 2015 edition (the “2015 Edition”). One of the ONC requirements for the 2015 Edition is for an EHR to enable third party applications to retrieve patient information using application programming interfaces (APIs). McKesson has made available the Paragon® APIs and the Paragon® API
Sandbox via this site to enable retrieval of patient information from the Paragon® EHR. Third party application developers may access the Paragon® APIs as part of developing applications for use by patients of healthcare providers that use the 2015 Edition certified release of the Paragon® EHR. By using this website, you acknowledge and agree to the Paragon® API terms and conditions set forth below (the “Paragon® API Terms of Use”).

1. Definitions-

    “Paragon® API Sandbox” means the online site made available by McKesson for Paragon® API Developers to test applications during the application development process.

    “Paragon® API Developer” means a third party application developer who uses the Paragon® APIs for the purpose of developing applications that are interoperable with Paragon®.

    “Paragon® User” means a hospital or other healthcare provider that is a licensed user of the Paragon® EHR.

2. Terms of Use-

    Your use of this site, including, without limitation, accessing the Paragon® APIs and the Paragon® API Sandbox, is subject to these Paragon® API Terms of Use. McKesson may update and modify the Paragon® API Terms of Use at its sole discretion and without notice. Paragon® API Developers and other users of this site should regularly check this site for updates to the Paragon® API Terms of Use.

3. McKesson retains IP ownership-

    McKesson will retain ownership of McKesson property and reserves all of its applicable rights with respect to the content of this site, the Paragon® EHR and the Paragon® APIs. Nothing in the Paragon® API Terms of Use or any documentation associated with the Paragon® APIs is intended to convey any transfer of ownership of McKesson’s property.

4. No Access to Paragon® Code or Software-

    Paragon® API Developers may test applications by using the Paragon® API Sandbox or by collaborating with a Paragon® EHR; it is not necessary to access the Paragon® EHR to test applications. In connection with providing the Paragon® APIs, McKesson does not offer a license to use the Paragon® EHR, or access to the Paragon® EHR to any party that has not purchased a license to the Paragon® EHR. McKesson will not make any Paragon® EHR source code available to any party in connection with the Paragon® APIs.

5. Indemnity-

    By accessing the Paragon® APIs and the Paragon® API Sandbox, you assume the risk of liability for, and agree to indemnify and hold harmless McKesson and its affiliates, employees (collectively, the “McKesson Indemnitees”) and will defend the McKesson Indemnitees from and against any and all liabilities, losses, claims, damages, claims and expenses (including legal expenses of any kind and nature) arising out of, or relating to, directly or indirectly: (a) any action or omission related to (i) your use of the Paragon® APIs or (ii) the development, content, or performance of third party applications developed by you or (b) your failure to comply with any federal, state or local laws, rules or regulations in connection with your use of the Paragon® APIs.

6. Client identifier-

    For each application submitted for use of the Paragon® APIs, McKesson will issue a unique client identifier. If, in the sole determination of McKesson or a Paragon® User, an application causes performance, security or other material issues with the Paragon® EHR, McKesson or the Paragon® User may, each at its sole discretion, suspend the client identifier associated with that application.

7. Warranty Disclaimers-

    The Paragon® APIs and the Paragon® API Sandbox are provided on an “as-is” basis with all faults and defects, and without any warranty whatsoever. The entire risk as to the quality and performance of the Paragon® APIs is with the Paragon® API Developer. The Paragon® API Developer shall be responsible for the performance of, and any end-users’ use of third party applications created by Paragon® API Developers. McKesson does not provide any service level agreements or performance objectives for availability, response time or any other performance measurement associated with the Paragon® APIs or the Paragon® Sandbox.

    For any performance issues alleged to be caused solely by the Paragon® APIs or the Paragon® API Sandbox, Paragon® API Users may ;report such issues to McKesson using the contact information provided and McKesson will make reasonable efforts to investigate such issues. For any performance issues resulting, in McKesson’s sole determination, from the Paragon® APIs or the Paragon® API Sandbox, McKesson will make reasonable efforts to correct such issues in order for the Paragon® APIs to function as intended.

8. FTC Best Practices-

    McKesson recommends that all Paragon® API Developers adhere to the principles outlined in the Federal Trade Commission (FTC) Mobile Health App Developers: FTC Best Practices document, which may be viewed at the link below (“FTC Best Practices”): https://www.ftc.gov/tips-advice/business-center/guidance/mobile-health-app-developers-ftc-best-practices

    If, in McKesson’s sole discretion, a Paragon® API Developer or a third party application developed for use with Paragon® APIs fails to conform to any of the FTC Best Practices, McKesson may disable the applicable client identifier or disable the Paragon® API Developer’s access to the Paragon® APIs or the Paragon® API Sandbox until such time as McKesson, in its sole discretion, determines that such non-conformance is corrected.

Notices

Paragon is a registered trademark of McKesson Provider Technologies.
FHIR and CDA are the registered trademarks of Health Level Seven International.
LOINC is a registered trademark of Regenstrief Institute, Inc.

Created by Paragon® 
Contact the developer 
Paragon® Copyright