This document described the GetPatientRecords onboarding activities for API customers.
Use Case, Roles, and Flows
The GetPatientRecord Use Case queries national network members for patient clinical information. There are two key roles in this use case:
- The Query Initiator conducts queries to retrieve information from members of associated national networks.
- The Query Responder provide patient clinical information in response to Query Initiator queries.
In the Query Responder Flow, the customer will receive a request from a Query Initiator seeking patient information based on demographics. After comparing the provided demographics with its known patients, it returns a response with any matching patient(s). Subsequently, in response to the Query Initiator's request to find documents, the customer will provide a list of document metadata it holds for the patient. Finally, upon receiving the Query Initiator's request for documents, the customer will send the requested document(s) in response.
As for the Query Initiator Flow, it's noteworthy for its streamlined process, comprising only two steps instead of three. It commences with the customer requesting a list of available patient documents from either a named query responder or all query responders within a specific geographic region. Following this, the customer proceeds to request specific documents from the provided list of available documents.
The table below indicates whether use case roles need to be implemented. In additional, the table identifies the required evidence to claim specific purposes of use. Refer to this article for a description of Carequality Permitted Purpose.
| Permitted Purpose | Initiator Role | Responder Role | Required Evidence |
|---|---|---|---|
| TREATMENT | Optional | MUST | (1) HIPAA Covered Entity, Business Associate and Type 1 or Type 2 NPI |
| PAYMENT | MUST | N/A | ?? |
| OPERATIONS | MUST | N/A | (1) HIPAA Covered Entity or Business Associate or (2) IAL2/AAL2 via Kantara Initiative CSP |
| PUBLICHEALTH | MUST | N/A | |
| REQUEST | MUST | N/A | (1) IAL2/AAL2 via Kantara Initiative CSP |
| COVERAGE | MUST | N/A | (1) HIPAA Covered Entity or Business Associate or (2) IAL2/AAL2 via Kantara Initiative CSP |
| CARECOORDINATION | MUST | N/A | (1) HIPAA Covered Entity or Business Associate or (2) IAL2/AAL2 via Kantara Initiative CSP |
Onboarding Pre-conditions
Before onboarding can commence, the following must be completed
- Customers BAA with RosettaHealth is signed and executed.
- RosettaHealth Terms and Conditions are signed and executed.
- Carequality Connections Terms, if separate, are signed and executed.
Onboarding
APIs and test accounts
RosettaHealth will, via email, provide the client with this document, links API documentation, and provide test accounts. This information is needed for the client to develop and test interfaces with RosettaHealth to access the national networks (eg. CareQuality). For reference, the APIs are
- Query Responder API
- Customer needs to implement these APIs and provide RosettaHealth with urls
- Query Initiator API
Customer Integration, Test, and Verification
Customer, using the provided APIs, will need to develop and test capability for both the Query Responder (Treatment only) and Query Initiator in our sandbox environment. Once the customers implementation is verified, we will need to test and verify it in the national network test environment. When these two validation are complete, we are ready to enable production access.
Promote to production
In order to reach the national networks, the directory must be updated with customer information. This requires collecting the needed information about customer and evidence of compliance. We will
- gather this information,
- create customer directory entry(s),
- provide customer with query initiator url