FHIR Bulk Data API spec compliance

125 views
Skip to first unread message

Branden Rauch (CareEvolution)

unread,
May 3, 2019, 10:18:24 AM5/3/19
to Developer Group - Beneficiary Claims Data API
Hello,

I've been working the BCDA test server and I have some concerns about the the server implementation not following the FHIR bulk data API specifications.

The bulk data API spec says that all support FHIR resource type data files should be generated through calling '/Patient/$export' but the BCDA test server only outputs provides Patient resources from '/Patient/$export'. To get ExplanationOfBenefit resources you have to make a separate call to '/ExplanationOfBenefit/$export'. Same with Coverage resources at '/Coverage/$export'. This forces the client implementation to be significantly more complex and does not align with other bulk data server implementations. Instead, why not provide all supported types through '/Patient/$export' like the bulk data API spec describes? If the client does not need all the supported types they could and use the '_type' query parameter filter, which was proposed by the bulk data API spec to limit the types to only those desired.

Also, the resource ndjson data files are currently not compliant the bulk data API spec. Each FHIR resource is wrapped inside of another object under its 'resource' property:

{"resource":{"address":[{"district":"999","postalCode":"99999","state":"34"}],"birthDate":"1999-06-01","extension":[{"url":"https://bluebutton.cms.gov/resources/variables/race","valueCoding":{"code":"1","display":"White","system":"https://bluebutton.cms.gov/resources/variables/race"}}],"gender":"unknown","id":"-19990000002901","identifier":[{"system":"https://bluebutton.cms.gov/resources/variables/bene_id","value":"-19990000002901"},{"system":"https://bluebutton.cms.gov/resources/identifier/hicn-hash","value":"ff8171ed25f7434378d985d060f87044c9588b88bcaf6e68b88a8294a44596b5"}],"name":[{"family":"Doe","given":["Jane","X"],"use":"usual"}],"resourceType":"Patient"}}
{"resource":{"address":[{"district":"999","postalCode":"99999","state":"42"}],"birthDate":"1999-06-01","extension":[{"url":"https://bluebutton.cms.gov/resources/variables/race","valueCoding":{"code":"1","display":"White","system":"https://bluebutton.cms.gov/resources/variables/race"}}],"gender":"unknown","id":"-19990000002902","identifier":[{"system":"https://bluebutton.cms.gov/resources/variables/bene_id","value":"-19990000002902"},{"system":"https://bluebutton.cms.gov/resources/identifier/hicn-hash","value":"b8d5ce7125a2c6de00b437b829707133024d3abe29bda7b8d0367ae9a88aae05"}],"name":[{"family":"Doe","given":["Jane","X"],"use":"usual"}],"resourceType":"Patient"}}

The resource objects should output directly, not wrapped inside of another object. The wrapper object is not necessary...it looks like it also provides a 'resourceType' property but we already know what resource type the file contains prior to downloading it (from the job output).

Thanks,
Branden Rauch

Terrance Bell

unread,
May 3, 2019, 12:52:46 PM5/3/19
to Branden Rauch (CareEvolution), Developer Group - Beneficiary Claims Data API
Thanks Branden for reaching out. I've shared your concerns with the rest of the development team and we'll be sure to follow up with you on this issue. Thanks for the feedback and keep it coming!!

Terrance Bell
Software Engineer

email tb...@fearless.tech
cell 410.271.4503
office 8 Market Place #304, Baltimore

fearless.tech   |   What we do   |   Join our team



--
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 post to this group, send email to bc-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bc-api/72a791fd-835e-4e85-a4cb-9521a35da8a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages