Skip to first unread message
Justin Stauffer
May 28, 2019, 10:12:18 AM5/28/19
to bc-...@googlegroups.com
The FHIR Bulk Data Spec defines the valid elements in a Complete Status Response:
Since the KeyMap and JobID elements are not defined in the spec, you should be putting those elements under an extension as the spec states:
The response body and any file item MAY optionally contain the following field:
extension - To support extensions, this implementation guide reserves the name extension and will never define a field with that name, allowing server implementations to use it to provide custom behavior and information. For example, a server may choose to provide a custom extension that contains a decryption key for encrypted ndjson files. The value of an extension element MUST be a pre-coordinated JSON object.
It seems to me you could then eliminate the KeyMap element and simply add a decryptionKey element (or something like that) along with each file. For example, I think this would satisfy the spec rules and simplify the response message a bit:
{
"transactionTime": "2018-12-11T06:29:56.723792Z",
"request": "http://localhost:3000/api/v1/ExplanationOfBenefit/$export",
"requiresAccessToken": true,
"output": [
{
"type": "ExplanationOfBenefit",
"url": "http://localhost:3000/data/1/0c527d2e-2e8a-4808-b11d-0fa06baf8254.ndjson",
"extension": {
"decryptionKey": "6c498a997001592ac05ace691fcf4a81724936c78937e24f90242c4f3081759f5365bef70a79eb0a6e145d22190b1178acf9f819399d27a4261efedf027642ca37d3f50cc0b941b105e35fc5b21cc785b171acb0ed299be16ff86fb457ff00d6855fefc9d403efdecbaca81ebffc85f8dbf1574d791640d392c5523482578ed232f7554880fa52d3471a4d919ab1ae8687e0442697cad7326aeb6ad0ddecaaeccaf61f952ef0cde2a3f15167b8854f8620440d8f1d9e09a0a39f1d04a3acf8178e5b6b28d9a062f09ff5fece3d16d9aacf7d43f4b94932d4f3268d1029f2874f3542ba71c858586393a80f45cb92b0cff9d2857b960045d733183d15c3599377"
}
}
],
"error": [
{
"type": "OperationOutcome",
"url": "http://localhost:3000/data/1/0c527d2e-2e8a-4808-b11d-0fa06baf8254-error.ndjson",
"extension": {
"decryptionKey": "4fd09523856ff24b9505c921973847fd4b1daf02753b3979373e8be8ea7da5418faa091535003a097ba8013582707535d0f5ea60380036c8be318094092c1936d0a80981ee2465009871c2fe56312e65239fea3785753684de19599d3219c545c24ad12018be4b86a39e742035e2559dcbe6169b6a3354f34bd2fbd569f88b70d3d1d13f62521693e779d3d2479d36515e086518bfd1140655d3b6100b05377b3ccacdfc10772c6a58178fae70b3a6a6ef897f64ae4a60045247b02331930ee6f15db45271afb2a432a8084170469458eef87c3a96ff6c4664c53b4867842b8650b3105860d29e87f43aad2c528d635f0eb02dc2bc905bf43bb1d1dd7f2cad3d"
}
}
],
"extension": {
"JobID": 1
}
}---
Alex Hovancik
May 28, 2019, 12:57:51 PM5/28/19
to Justin Stauffer, Developer Group - Beneficiary Claims Data API
Hi Justin,
Thanks for bringing this to our attention! We’ve created a ticket internally to look into satisfying the FHIR spec as per your suggestion. Feel free to return with any additional feedback you have in the future as well.
Cheers,
Alex
BCDA Engineer
On May 28, 2019, at 9:12 AM, Justin Stauffer <jus...@epic.com> wrote:
The FHIR Bulk Data Spec defines the valid elements in a Complete Status Response:Since the KeyMap and JobID elements are not defined in the spec, you should be putting those elements under an extension as the spec states:The response body and any file item MAY optionally contain the following field:
extension - To support extensions, this implementation guide reserves the name extension and will never define a field with that name, allowing server implementations to use it to provide custom behavior and information. For example, a server may choose to provide a custom extension that contains a decryption key for encrypted ndjson files. The value of an extension element MUST be a pre-coordinated JSON object.
It seems to me you could then eliminate the KeyMap element and simply add an decryptionKey element (or something like that) along with each file. For example, I think this would satisfy the spec rules:
"transactionTime": "2018-12-11T06:29:56.723792Z",
"request": "http://localhost:3000/api/v1/ExplanationOfBenefit/$export",
"requiresAccessToken": true,
"output": [
{
"type": "ExplanationOfBenefit",
"url": "http://localhost:3000/data/1/0c527d2e-2e8a-4808-b11d-0fa06baf8254.ndjson",
"extension": {
"decryptionKey": "6c498a997001592ac05ace691fcf4a81724936c78937e24f90242c4f3081759f5365bef70a79eb0a6e145d22190b1178acf9f819399d27a4261efedf027642ca37d3f50cc0b941b105e35fc5b21cc785b171acb0ed299be16ff86fb457ff00d6855fefc9d403efdecbaca81ebffc85f8dbf1574d791640d392c5523482578ed232f7554880fa52d3471a4d919ab1ae8687e0442697cad7326aeb6ad0ddecaaeccaf61f952ef0cde2a3f15167b8854f8620440d8f1d9e09a0a39f1d04a3acf8178e5b6b28d9a062f09ff5fece3d16d9aacf7d43f4b94932d4f3268d1029f2874f3542ba71c858586393a80f45cb92b0cff9d2857b960045d733183d15c3599377"
}
}
],
"error": [
{
"type": "OperationOutcome",
"url": "http://localhost:3000/data/1/0c527d2e-2e8a-4808-b11d-0fa06baf8254-error.ndjson",
"extension": {
"decryptionKey": "4fd09523856ff24b9505c921973847fd4b1daf02753b3979373e8be8ea7da5418faa091535003a097ba8013582707535d0f5ea60380036c8be318094092c1936d0a80981ee2465009871c2fe56312e65239fea3785753684de19599d3219c545c24ad12018be4b86a39e742035e2559dcbe6169b6a3354f34bd2fbd569f88b70d3d1d13f62521693e779d3d2479d36515e086518bfd1140655d3b6100b05377b3ccacdfc10772c6a58178fae70b3a6a6ef897f64ae4a60045247b02331930ee6f15db45271afb2a432a8084170469458eef87c3a96ff6c4664c53b4867842b8650b3105860d29e87f43aad2c528d635f0eb02dc2bc905bf43bb1d1dd7f2cad3d"
}
}
],
"extension": {
"JobID": 1
}
}---
--
You received this message because you are subscribed to the Google Groups "Developer Group - Beneficiary Claims Data API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bc-api+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bc-api/179c478a-6594-4a05-b804-7b2d98db5289%40googlegroups.com.
Ankur Garg
Jun 6, 2019, 1:45:24 PM6/6/19
to Developer Group - Beneficiary Claims Data API
I agree. It also makes it easier for us to parse the data.
Reply all
Reply to author
Forward
0 new messages