Stream: bulk data
Topic: CMS Data at the Point of Care
Josh Mandel (Aug 11 2019 at 17:33):
Reading through https://dpc.cms.gov/docs#attribution, I love the use of FHIR built-ins for this use case @Nick Robison . A few quick notes...
Josh Mandel (Aug 11 2019 at 17:35):
In the example of POST /api/v1/Group, the body should be a Group rather than a bundle entry object (with a "resource" property pointing to a group).
Josh Mandel (Aug 11 2019 at 17:36):
Membership changes submitted to an existing attribution Group are always merged with the existing group state.
Are these changed submitted via POST /api/v1/Group (I didn't see the URL in this section, so I'm inferring)? If so, "merge" behavior is not consistent with the FHIR core spec (which would always create a new group and not merged into an existing group here). You might want to think about PATCH for issuing small changes to an existing resource, or define a custom operation to merge a set of changes in; thought I would avoid overloading the FHIR "create" operation as "merge".
Brian Postlethwaite (Aug 11 2019 at 22:49):
For things like this I would prefer a custom operation, as patch requires you to know the entire previous state to apply it.
Nick Robison (Aug 12 2019 at 12:02):
@Josh Mandel Thanks for the feedback! We'll be improving the documentation as we go along, and I agree it's pretty unclear regarding the issues you've mentioned. I'll get that fixed quickly.
Regarding the /Group POST, you're seeing a copy/paste bug in the documentation, the actual endpoint takes an actual resource and not a pointer, I'll get that updated.
In terms of updating the membership Group, we're currently using PUT to update the group (though I doesn't actually say this in the docs!), so the actual command would be PUT Group/{group.id} {body}. Does that make sense?
One question I had for the group, was in our use of code able concepts for attributing to a given provider NPI, in the SMART on FHIR docs, the R4 resource has a valueReference type, which makes things really easy, this is our attempt at back porting the functionality to STU3, but it doesn't feel right. Any thoughts or suggestions?
Thanks for the feedback, we're actively working to refine our implementation and will definitely be making changes to the docs and interaction model as we go along.
Michele Mottini (Aug 12 2019 at 15:11):
There is already a proposal for operations to add / remove individual elements from a group: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=21650&start=25
Michele Mottini (Aug 12 2019 at 15:13):
A standard PUT would replace the entire group content, not add new members
Josh Mandel (Aug 12 2019 at 15:58):
In terms of updating the membership Group, we're currently using PUT to update the group (though I doesn't actually say this in the docs!), so the actual command would be
PUT Group/{group.id} {body}. Does that make sense?
go along.
Seconding Michele's point, FHIR PUT doesn't have merge semantics; you'd want PATCH or a custom operation.
Josh Mandel (Aug 12 2019 at 16:30):
Re: back-port, I think what's mission is Group.characteristic.valueReference. There's a convention for back-porting new elements to older versions via extensions; maybe @Grahame Grieve can spell out what extension would be used to back-port Group.characteristic.valueReference to STU3?
Nick Robison (Aug 12 2019 at 17:07):
@Michele Mottini Good to know about that proposal, we'll look forward to implementing it once it's finalized.
@Josh Mandel Thanks for the clarification, we'll look at updating our endpoints to use PATCH, I think the mistake came from misreading the HAPI FHIR client (which we use for TDD) which as an update() operation, which generates a PUT.
Michele Mottini (Aug 12 2019 at 18:07):
You might find much easier to implement the operations instead of PATCH
Nick Robison (Aug 12 2019 at 18:42):
@Michele Mottini You're probably right, we should connect at the WG meeting and talk through this, I want to make sure we implement it correctly, to avoid another embarrassing PUT/PATCH situation! Thank you for the feedback.
Grahame Grieve (Aug 12 2019 at 18:53):
@Josh Mandel you are referring to http://hl7.org/fhir/versions.html#extensions. Using the extension to backport an additional choice in a data type... hmm...
Grahame Grieve (Aug 12 2019 at 18:54):
I guess it doesn't make any difference
Josh Mandel (Aug 12 2019 at 19:01):
Thanks! Yeah, http://hl7.org/fhir/4.0/StructureDefinition/extension-Group.characteristic.valueReference would be the extension URL then. Thanks! (We might consider linking to http://hl7.org/fhir/versions.html#extensions from https://www.hl7.org/fhir/extensibility-registry.html ; I'll add a GForge issue)
Josh Mandel (Aug 12 2019 at 19:07):
Added GF#23562
Nick Robison (Aug 12 2019 at 19:47):
@Josh Mandel @Grahame Grieve Thanks for the feedback, we'll look at implementing the extension, that seems to make the most sense.
Michele Mottini (Aug 12 2019 at 22:14):
@Nick Robison I'll be at the connectathon in Atlanta - working on this stuff - not for the whole work group meeting
Nick Robison (Aug 13 2019 at 16:16):
@Michele Mottini Great, let's connect then!
@Josh Mandel We've updated the documentation to fix the issues you mentioned, let me know if you run into anything else. Thanks!
Josh Mandel (Aug 13 2019 at 19:34):
@Nick Robison looking at "Attributing Patients to Providers", I see an example of
An organization must first create a Practitioner resource, which represents a healthcare provider that is associated with the organization. This is accomplished by executing a POST request against the Practitioner resource, with the body containing a FHIR Practitioner resource.
POST /api/v1/Practitioner
where the body is a Parameters resource. The body for a Practitioner create interaction should only ever be a Practitioner, not a Parameters.
Josh Mandel (Aug 13 2019 at 19:35):
And when I see:
The Practitioner endpoint also supports a $submit operation, which allows the user to upload a Bundle of resources for registration in a single batch operation.
This sounds like behavior you should be able to get out of the standard FHIR batch (or transaction) semantics, e.g. via POST / with a Bundle of type batch, where each entry is a Practitioner. What is the motivation for a custom $submit operation?
Nick Robison (Aug 13 2019 at 20:28):
@Josh Mandel The documentation has been updated, it will be available after our next build (tonight or tomorrow).
Regarding the submission operation, we settled on a custom operator for a couple of reasons.
One was simplicity of implementation, we could define a new operator and avoid issues with colliding with existing FHIR semantics. The other reason is we like coupling operations to the resources which they're performed against, rather than mixing specific operation semantics with more generic resource types (like Bundle).
One of the thing we really like about the DPC project is that it's open source, so you and your team are more than welcome to contribute some of these changes. We're also really interested in hearing about your experiences integrating your existing clients and workflows with our backend.
Last updated: Apr 12 2022 at 19:14 UTC
