Answer Carequality requests without the Redox responder

This guide is for legacy users that respond to incoming Carequality requests on their own. Learn more about Redox Access™ if you're establishing a new connection with Carequality.

Review the details about event and document types to get oriented.

Redox Access customers use the PatientPush or VisitPush event types of the ClinicalSummary data model to prepare Redox to respond to requests from Carequality participants.

As your own responder, you'll use these ClinicalSummary event types instead:

• DocumentQuery
• DocumentGet
• DocumentQueryResponse
• DocumentGetResponse

The most common and valuable document type for Carequality participants is the Continuity of Care Document (CCD), which has a LOINC code of 34133-9. We recommend making CCDs available to respond to document requests.

You can respond with different document types, but talk to a Redoxer about alternatives first.

1. Submit a connection request to Redox to create a connection directly with Carequality.
2. Go through the steps outlined for setting up Redox Access, but skip the steps for pushing clinical summary documents.
3. Create and verify an endpoint in your system so that you can receive synchronous requests from the Carequality Framework.

   Learn more

   Learn about synchronous queries for background context to complete this step.

4. Create and authenticate an API key so that you can send synchronous queries to Carequality, or plan to use an existing API key.
5. Make sure that you can support these fields for receiving and processing DocumentQuery: (a) the Patient.Identifiers array; (b) all of the Visit fields; and (c) the Document.Types array. The patient identifier and identifier type should persist to your system as you push patient demographics. The rest of the fields are optional for you to implement as you choose for your system.
6. Make sure that you can support these fields for responding with DocumentQueryResponse: (a) the Documents[].ID string. The requester uses the network document ID for the DocumentGet query so be sure to persist and cache document IDs in your system. If you choose to dynamically generate documents, be sure to persist and cache the document ID for a reasonable amount of time (e.g., 24 hours) so that you don't have to rebuild the document if the requester asks for the document multiple times within a short amount of time. The network document ID must be globally unique, so please use a UUID or your [documentOID].[documentID] (e.g., 2.16.840.1.113883.3.6147.458...^1234).
7. Plan for how to respond with DocumentGetResponse (see step 9 or 10 depending on document type).
8. If you plan to respond with non-CCD documents, you must be able to populate these fields for DocumentGetResponse: (a) Meta.DataModel and Meta.EventType; (b) Document.ID; (c) FileType; and (d) Data. The rest of the fields are optional for you to implement as you choose for your system.
9. If you plan to respond with CCDs, you can choose to respond either in the traditional format (i.e., XML) or in an alternative format. For the traditional format, you must be able to populate the same fields noted in step 9. For the alternative format, you can use the DocumentGetResponse required Meta fields and include the body fields from either VisitPush or PatientPush event types instead.

   Example: DocumentGetResponse for alternative documents

   json

   Copy

   1
   {
   2
       "Meta": {
   3
           "DataModel": "Clinical Summary",
   4
           "EventType": "DocumentGetResponse"
   5
       },
   6
       "Header": {
   7
           "DirectAddressFrom": null,
   8
           "DirectAddressTo": null,
   9
           "Document": { 
   10
               "Author": {
   11
                   "ID": "4356789876",
   12
                   "IDType": "2.16.840.1.113883.4.6",
   13
                   "FirstName": "Pat",
   14
                   "LastName": "Granite",
   15
                   "Credentials": [
   16
                       "MD"
   17
                   ],
   18
                   "Address": {
   19
                       "StreetAddress": "123 Main St.",
   20
                       "City": "Madison",
   21
                       "State": "WI",
   22
                       "ZIP": "53703",
   23
                       "County": "Dane",
   24
                       "Country": "USA"
   25
                   },
   26
                   "EmailAddresses": [],
   27
                   "PhoneNumber": {
   28
                       "Office": "+16085551234"
   29
                   },
   30
                   "Type": null,
   31
                   "Location": {
   32
                       "Type": null,
   33
                       "Facility": null,
   34
                       "Department": null,
   35
                       "Room": null
   36
                   }
   37
               },
   38
               "ID": "75cb4ad4-e5f9-4cd3-8750-eb5050521e0d",
   39
               "Locale": "US",
   40
               "Title": "Community Health and Hospitals: Annual Physical",
   41
               "DateTime": "2012-09-12T00:00:00.000Z",
   42
               "Type": "Progress Note",
   43
               "TypeCode": { ...
   44
               },
   45
               "Visit": {
   46
                   "StartDateTime": "2022-05-20T18:11:48.972Z",
   47
                   "EndDateTime": "2022-05-20T18:11:48.972Z",
   48
                   "Reason": "Annual Physical",
   49
                   "VisitNumber": "30311442",
   50
                   "Type": {
   51
                       "Code": "99202",
   52
                       "CodeSystem": "2.16.840.1.113883.6.12",
   53
                       "CodeSystemName": "CPT",
   54
                       "Name": "Office visit",
   55
                       "AltCodes": []
   56
                   },
   57
                   "Location": {
   58
                       "Type": "Outpatient Clinic",
   59
                       "Facility": "RHS Vista Oaks Clinic",
   60
                       "Department": "Vista Oaks Clinic",
   61
                       "Room": null
   62
                   }
   63
               }
   64
           },
   65
           "Patient": {
   66
               "Identifiers": [
   67
                   {
   68
                       "ID": "1234",
   69
                       "IDType": "2.16.840.1.113883.4.6",
   70
                       "Type": null
   71
                   }
   72
               ],
   73
               "Demographics": {
   74
                   "FirstName": "Myra",
   75
                   "MiddleName": null,
   76
                   "LastName": "Jones",
   77
                   "DOB": "1947-05-01",
   78
                   "SSN": "123-101-1234",
   79
                   "Sex": "Female",
   80
                   "Address": {
   81
                       "StreetAddress": "1357 Amber Drive",
   82
                       "City": "Beaverton",
   83
                       "State": "OR",
   84
                       "County": null,
   85
                       "Country": "US",
   86
                       "ZIP": "97006"
   87
                   },
   88
                   "PhoneNumber": {
   89
                       "Home": "+18162766909",
   90
                       "Mobile": null
   91
                   },
   92
                   "EmailAddresses": [
   93
                       {
   94
                           "Address": "12313124@fake.com"
   95
                       }
   96
                   ],
   97
                   "Language": null,
   98
                   "Race": "White",
   99
                   "Ethnicity": "Not Hispanic or Latino",
   100
                   "Religion": "Christian (non-Catholic, non-specific)",
   101
                   "MaritalStatus": "Married"
   102
               }
   103
           }
   104
       },
   105
       "AllergyText": ...,
   106
       "Allergies": [
   107
           { ...
   108
           }
   109
       ]
   110
   }

You must decide how you want to manage and provide documents when Carequality participants request them. You can generate documents in your database either:

1. (Recommended) Dynamically, at the time of the query. For this option, you must generate the document in a performant manner. We also recommend caching the document for a reasonable amount of time for your system (e.g., 24 hours). That way, if the requester asks for it again within a short amount of time, you don't have to rebuild it. The benefit of generating documents dynamically is that the requester doesn't have to locate one document in a large list. Instead, the specific document they want is generated when they want it.
2. Immediately, upon completing a patient visit and retaining the document indefinitely. Immediately doesn't have to be real-time. For example, you could choose to generate documents as part of a nightly batch job.

1. Talk to a Redoxer to get the Postman collection and staging environment so that you can send test requests to validate your system. When you test, you're essentially acting as an external Carequality participant querying yourself. You're free to validate in production too, but it's not required since you already have the data.
2. Send a ClinicalSummary.DocumentQuery with the network patient ID for a test patient to the Redox gateway: 2.16.840.1.113883.3.6147.458.2.
3. We resolve it to your local patient ID and forward the request to your configured endpoint.
4. After receiving a DocumentQuery, perform these steps with a Redoxer to validate that you respond successfully. For each of the responses, you include the local document ID, which Redox translates to the network document ID.
   1. Confirm that you can respond with a list of all documents that you have available for the patient with no specific search parameters.
   2. Confirm that you can respond with a list of documents filtered down to a specific document type.
   3. Confirm that you can respond with a list of documents filtered down to a specific visit date range. Make sure that you can support both start/end dates, only start date, and only end date.
   4. Test whether you can respond for a patient that has no related documents. This helps you define how to handle the interim state between locating a patient and preparing a document.
5. Once you complete step 4, you have successfully validated DocumentQueryResponse.
6. Now, you must validate DocumentGet. Send a ClinicalSummary.DocumentGet with the network document ID to the Redox gateway: 2.16.840.1.113883.3.6147.458.2.
7. Redox resolves it to the local document ID and forwards the request to your configured endpoint.
8. After receiving the DocumentGet, perform these steps with a Redoxer to validate that you respond successfully.
   1. Confirm that you can find a document and return it in the right format—and that you receive it back in response to your query.
   2. Confirm that you can handle responding with the appropriate error code when you fail to locate a document.

If your system experiences errors while you're processing incoming requests, you can respond with any of these errors in the body.XDSErrors.code field:

• XDSRepositoryOutOfResources
• XDSRepositoryBusy
• XDSRepositoryError
• XDSUnknownPatientId

Include any extra information you want to relay back to the sender about the error in the body.XDSErrors.message field.

1
{
2
"body": {
3
    "XDSErrors": [
4
	{
5
	    "code": "XDSUnknownPatientId",
6
	    "message": "Patient Not Found."
7
	}
8
     ]
9
  }
10
}