Bulk Data Access
The Oracle Cerner Ignite APIs for Millennium with Bulk Data Access allows system applications to access large volumes of core clinical data for a group of individuals in alignment with standards cited in 21st Century Cures Act regulations.
FHIR bulk data requests are run against an organization's database asynchronously. When implementing an interface between a Millennium Platform domain and a bulk data application, ensure that the queries inherent in the bulk data request capture only the data necessary for the application.
Several factors affect the amount of time required to complete a bulk API export, such as the following examples:
- The size of the population for which data is requested
- The number of requested resource types
- The time range of the requested activity
- The inherent latency due to network issues and effects from concurrent requests to the system
Example Use Cases
- Creation of an internal clinical data warehouse for study purposes
- Machine learning applications that obtain training data from the electronic health record (EHR)
- Integration of population health system with an EHR system
- Data transfer to payer database for care quality assessment
- Submission to reportable disease (or other) registries
Implemented Exports
Oracle Cerner supports the Group Export operation and the Patient Export operation (for more information, see Bulk Export.
Note:
- For the Group Export operation, Oracle Cerner supports v1.0.1 of the FHIR Bulk Data Access (Flat FHIR) Implementation Guide and supports several experimental parameters from v2.0.0.
- For the Patient Export operation, Oracle Cerner supports v2.0.0 of the FHIR Bulk Data Access (Flat FHIR) Implementation Guide.
- The Patient Export operation does not support an export of all patients. A list of patients IDs must be provided in the request.
Service Root URL
The FHIR Bulk Data server uses the FHIR base URL as the service root URL (for more information, see the Service Root URL topic in FHIR R4 APIs for Oracle Health Millennium Platform).
Media Types
For file retrievals, application/fhir+ndjson
is supported. All other
requests support application/fhir+json
.
Authorization
The bulk data endpoints are secured with OAuth 2.0 with support for SMART
applications. See the extensions on the Conformance.rest.security
element in our server metadata.
See the Authorization Framework documentation for details on how to authorize with our server.
Registering Client Applications
To be granted access to the Bulk Data Access API, you must register a Millennium Bulk Data SMART application through code Console (for more information, see the SMART documentation on Oracle Help Center). See the Authorization Framework documentation for additional details on registering client applications and authorizing with the server.
In the case of Group Export, client application developers must work with healthcare organizations to identify the available groups to be exported. Organizations can manage groups in Ignite Management Tooling.
Note:
- Authentication is required. Open endpoints do not support bulk export workflows.
- Consider the performance impact because bulk data runs against an organization's database and uses the same services running other applications. Bulk data exports large amounts of data for large groups of patients, and the time to complete the export increases with larger data sets or patient populations.
Sandbox
Testing can be done in sandbox for applications that have authorization (for more information, see the Authorization Framework documentation).
https://fhir-ehr.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d
Client Errors
The following client errors can be received for API requests:
- Failing to send a required search parameter or sending a parameter with an invalid value
returns a
400 (Bad Request)
status code.HTTP/1.1 400 Bad Request
- Making a request without valid credentials returns a
401 (Unauthorized)
status code.HTTP/1.1 401 Unauthorized
- Requesting data from an unknown instance or an instance where the application is not
authorized returns a
403 (Forbidden)
status code.HTTP/1.1 403 Forbidden
- Requesting a resource that does not exist returns a
404 (Not Found)
status code.HTTP/1.1 404 Not Found
- Requesting a media type other than JSON returns a
406 (Not Acceptable)
status code.HTTP/1.1 406 Not Acceptable Content-Length: 0
- Providing a media type other than JSON in the
Content-Type
parameter for patient exports returns a415 (Unsupported Media Type)
status code.HTTP/1.1 415 Unsupported Media Type
- Performing an export kick-off using unsupported search parameter values returns a
422 (Unprocessable Entity)
status code.HTTP/1.1 422 Unprocessable Entity
Lenient Workflow
When the optional header of Prefer: handling=lenient
is passed to the
export kick-off request, any unknown or unsupported parameters are ignored as specified in
the v.2.0.0 FHIR Bulk Data Access (Flat FHIR) Implementation Guide,
and the request is processed instead of returning an error.
Operation Outcomes
An operation outcome may be returned to provide additional context for an error.
The following table describes common operation outcomes and their causes:
HTTP Status | Cause | Severity | Code |
---|---|---|---|
400 |
The request has an invalid search parameter or a parameter with an invalid value |
error |
invalid |
401 |
Invalid credentials were sent in the request |
error |
login, expired |
403 |
The client is not authorized to access the information |
error |
forbidden |
404 |
The resource being requested cannot be found |
error |
not-found |
406 |
The value supplied to the Accept header is not supported |
error |
invalid |
415 |
The value supplied to the Content-Type header is not supported |
error |
invalid |
429 |
Too many requests have been sent |
error |
throttled |
500 |
An internal error occurred |
fatal |
exception |