Stream: bulk data
Topic: capabilities,operation.reference.definition
Richard Braman (Jul 28 2020 at 18:38):
I have seen different values for for the bulk data operations definition reference in 3 different reference servers:
In SMART ref implementation:
{
"name": "group-export",
"definition": {
"reference": "OperationDefinition/group-export"
}
}
in CMS BCDA
{
"name": "group-export",
"definition": {
"reference": "https://sandbox.bcda.cms.gov/api/v1/Group/[id]/$export"
}
}
in CMS DPC
{
"name": "export",
"definition": {
"reference": "http://build.fhir.org/ig/HL7/bulk-data/OperationDefinition-group-export"
}
},
They all look wrong based on what I have read in the spec it should look like this:
"name": "group-export",
"definition": {
"reference": "http://hl7.org/fhir/uv/bulkdata/OperationDefinition/group-export"
}
with "reference": "http://build.fhir.org/ig/HL7/bulk-data/OperationDefinition-group-export" for systems before bulk fhir 1.0
Correct?
Dan Gottlieb (Jul 28 2020 at 19:12):
The IG defines the canonical url as "http://hl7.org/fhir/uv/bulkdata/OperationDefinition/group-export", which look like it matches the format used by other operations. You could also add a version so it would be something like: "http://hl7.org/fhir/uv/bulkdata/OperationDefinition/group-export|1.0.0".
Dan Gottlieb (Jul 28 2020 at 19:13):
@Vladimir Ignatov - it would be great to update the SMART bulk data reference server to use full urls in the CapabilityStatement
Richard Braman (Jul 28 2020 at 19:42):
@Vladimir Ignatov is the short hand url allowed because the Cap stmt "instantiates" http://hl7.org/fhir/uv/bulkdata/CapabilityStatement/bulk-data?
Vladimir Ignatov (Jul 29 2020 at 13:37):
I'm afraid this part is very confusing. I remember there were some errors in the IG and I wonder if there is a real-life example of CapabilityStatement that we could look at?
The relative URLs we are talking about here are CapabilityStatement.rest[0].operation[n].definition.reference and not the canonical urls of specific OperationDefinition. I will update mine to use the full URLs, but Isn't it also valid to point to local OperationDefinition (in case you have one)?
Robert Scanlon (Jul 29 2020 at 19:26):
Was the intent @Vladimir Ignatov to serve those OperationDefinition resources from the smart bulk data server? It looks like those specific OperationDefinition resources aren't available. I thought it was an interesting approach and saw the server supports OperationDefinition reads, but those three definitions aren't on the server.
Robert Scanlon (Jul 29 2020 at 19:29):
Something that tripped me up is that the type of CapabilityStatement.rest[0].operation[n].definition changed from Reference(OperationDefinition) to Canonical(OperationDefinition) from STU3 to R4. So depending on if you are a R4 server or a STU3 server, your capabilitystatement will look a little different, right?
Robert Scanlon (Jul 29 2020 at 19:32):
Also, I think you need to be careful that group-export and patient-export are at CapabilityStatement.rest.resource.operation.definition (note resource) because they are instance and resource level operations.
Vladimir Ignatov (Jul 29 2020 at 19:35):
Yes, some of OperationDefinition resources are missing. That is because this is in fact not a FHIR server and resources like these are served as static files. When I did that I only wanted to have a CapabilityStatement that looks right and I didn't expect that anybody would have to resolve that. It doesn't matter now because I just switched to full URLs. You may be right about the rest though. Let me investigate...
Vladimir Ignatov (Jul 29 2020 at 20:11):
Yes, It looks like I will have to modify the structure of the CapabilityStatement to reflect the FHIR version.
I'm not sure for the other matter though. What you are suggesting makes perfect sense but I wonder if that is a strict requirement or a matter of choice. For example, consider this:
- Only global operations (CapabilityStatement.rest.operation.definition) are used in the official example - http://hl7.org/fhir/uv/bulkdata/STU1/CapabilityStatement-bulk-data.json.html
- If I don't really have a FHIR server with resources and operations on them I should still be able to define those exports as global operations (I guess)
I think I might be OK with such CapabilityStatement on this particular server, but I do need to know what the required approach is in order to test for it properly in BDT. Does anybody here know for sure how those operation definitions should be defined? @Dan Gottlieb or @Josh Mandel maybe?
Robert Scanlon (Jul 29 2020 at 20:14):
I believe the issue in the capability statement was addressed in a errata fix that never officially published: https://github.com/HL7/bulk-data/blob/master/resources/capabilitystatement-bulk-data.json
Robert Scanlon (Jul 29 2020 at 20:15):
One thing to remember is that isn't really an 'example', per-se, because it is of kind 'requirements'
Robert Scanlon (Jul 29 2020 at 20:18):
(I am inferring that updated capabilitystatement in the github repo is an unpublished errata update based on this comment from Josh: https://chat.fhir.org/#narrow/stream/179250-bulk-data/topic/Canonical.20URI.20for.20the.20Bulk.20Data.20CapabilityStatement/near/193061682)
Robert Scanlon (Jul 29 2020 at 20:26):
If I don't really have a FHIR server with resources and operations on them I should still be able to define those exports as global operations (I guess)
Why do you say you don't have a FHIR server? A bulk data server conforming to this spec must be a FHIR server, correct? You could only support the capability interaction, the bulk data operations and nothing else, but it still is a FHIR server which means you must have a valid capability statement.
Dan Gottlieb (Jul 29 2020 at 20:39):
@Robert Scanlon @Vladimir Ignatov yup, unfortunately, the currently CapabilityStatement in the IG is incorrect. The fixed version is at http://build.fhir.org/ig/HL7/bulk-data/branches/tech-correct/ (diff at https://github.com/HL7/bulk-data/compare/v1.0.0...tech-correct). We're working on getting this published to the main site (the FHIR-I WG approved publication earlier this month).
Vladimir Ignatov (Jul 29 2020 at 20:47):
Well, that is a separate topic. The reference server was probably the first Bulk Data server out there, created back when the spec was just an early draft. It wasn't published and it wasn't that FHIR-specific. This server had nothing to do with FHIR. It just implemented the API and exported some resources as if they are coming from a FHIR server. Over time, other "FHIR" futures like system-level export and capability statement were added and I had to do some patchwork to support them. I even used to think that Bulk Data can be used to export arbitrary JSON data and not only FHIR resources, but by now it seems that this is no longer the case. Anyway, my point is that I am just pretending to be a FHIR server by trying to behave like one wherever that is possible.
Robert Scanlon (Jul 29 2020 at 20:58):
Ah, thanks for the background. It's a wonderful developer tool. Sorry for sidetracking a bit. But I do think it makes sense to have the capability statement be correct because it is one of the few references out there, and the placement of the OperationDefinition within the CapabilityStatement is unambiguous in the spec because the system/type/instance elements in the OperationDefinition defines that.
Uday Kiran (Aug 13 2020 at 04:44):
@Dan Gottlieb As indicated earlier that the current CapabilityStatement in the IG is incorrect. Was curious when would the correct version of the CapabilityStatement in the IG will be published ? Any tentative estimate on the timeline ?
Dan Gottlieb (Aug 13 2020 at 14:31):
The corrected version is at http://build.fhir.org/ig/HL7/bulk-data/branches/tech-correct/CapabilityStatement-bulk-data.json.html . It's waiting on @Grahame Grieve's availability to push it to the main FHIR website.
Grahame Grieve (Aug 13 2020 at 22:05):
getting to it
Uday Kiran (Aug 14 2020 at 08:34):
Thank you @Dan Gottlieb and @Grahame Grieve for the response.
Lee Surprenant (Oct 01 2020 at 18:40):
Dan Gottlieb said:
Robert Scanlon Vladimir Ignatov yup, unfortunately, the currently CapabilityStatement in the IG is incorrect. The fixed version is at http://build.fhir.org/ig/HL7/bulk-data/branches/tech-correct/ (diff at https://github.com/HL7/bulk-data/compare/v1.0.0...tech-correct). We're working on getting this published to the main site (the FHIR-I WG approved publication earlier this month).
I noticed that this url is still wrong at https://hl7.org/fhir/uv/bulkdata/operations/index.html
Wasn't that tech-correct version supposed to have been published by now?
Josh Mandel (Oct 01 2020 at 22:08):
It was not (the footer at https://hl7.org/fhir/uv/bulkdata/operations/index.html shows "Generated 23/08/2019"). @Grahame Grieve I know this is somewhere on your formidable TODO list.
Grahame Grieve (Oct 01 2020 at 22:55):
is this approved by the TSC? It's not come through on the formal publishing to do list?
Josh Mandel (Oct 02 2020 at 00:16):
I'm not sure. On Aug 4 Dan asked you:
Hi Grahame, checking back on the bulk data IG technical correction publication. Anything else I need to do on my end?
And you answered "No, it's in my queue". If there's a missing approval, can you let us know how to track this down?
Grahame Grieve (Oct 02 2020 at 01:00):
well, you haev to get the committee that owns it to ask TSC to approve a technical correction. My apologies for being lax here - I assumed that this process would be happening in parallel
Dan Gottlieb (Oct 02 2020 at 16:03):
@Lloyd McKenzie - FHIR-I approved the publication of the bulk data technical correction on July 13th. Per @Grahame Grieve's comment, it sounds like the TSC also has to approve it before it goes on the website. Do you know how we move this forward? Thanks!
Lloyd McKenzie (Oct 02 2020 at 16:43):
@Anne Wizauer Do you know where this is at?
Anne Wizauer (Oct 02 2020 at 16:47):
TSC doesn't approve technical corrections - those go straight to Wayne/Lynn. @Lynn Laakso do you know if this came through?
Troy Biesterfeld (Oct 06 2020 at 16:49):
I noticed that the resource types (Patient, Group) listed in the CapabilityStatement [.rest.resources.type] at http://build.fhir.org/ig/HL7/bulk-data/branches/tech-correct/CapabilityStatement-bulk-data.json.html are not in camelcase, but instead are in lowercase, so they do not match the required valueset for that field. This can cause strict parsing of the CapabilityStatement to fail.
Josh Mandel (Oct 06 2020 at 18:49):
Good catch!
Dan Gottlieb (Oct 14 2020 at 13:35):
Thanks @Troy Biesterfeld ! FHIR-I approved the fix on Monday and I just merged it.
Dan Gottlieb (Oct 14 2020 at 13:43):
@Lloyd McKenzie @Lynn Laakso checking back on this. FHIR-I approved publication of the technical correction to the Bulk Data IG on July 13th - how do we get it published? Thanks!
Lynn Laakso (Oct 14 2020 at 14:02):
Was there a publication request submitted @Dan Gottlieb ? On there it would be ticked as an errata and also requires a http://www.hl7.org/permalink/?CTOErrataLetter. In addition you may want to tick the boxes for STU extension as the STU period ended 2020-08-20. Errata needs CTO approval, STU extension needs TSC approval.
Dan Gottlieb (Oct 14 2020 at 14:30):
Thanks @Lynn Laakso . I don't believe a publication request was submitted - how do I do that? What's the process for getting CTO and TSC approval?
Lynn Laakso (Oct 14 2020 at 14:34):
@Dan Gottlieb please see the HL7 Confluence main page under Documentation & Help on "How to Create a Publication Request from Template at https://confluence.hl7.org/display/HDH/How+to+Create+a+Publication+Request+from+Template
Dan Gottlieb (Oct 14 2020 at 14:38):
Thanks - I'll take a look
Dan Gottlieb (Oct 27 2020 at 17:56):
@Grahame Grieve Wayne approved the technical corrections and signed the errata letter on Friday. Are we ready to move ahead with posting the Bulk Data TC branch to the FHIR site?
Grahame Grieve (Oct 28 2020 at 05:33):
I expect so but I haven't heard. I'll check
Grahame Grieve (Oct 28 2020 at 19:56):
ok. it's in progress, but you need to update the title to say what it's status is, and also, you need to fill out an entry for the new version in package-list.json. Typically we would call this 1.1.0, but you have called it 1.2.0 - is there any thinking behind that?
Dan Gottlieb (Oct 28 2020 at 20:05):
Thanks! The tech-correct branch with the technical corrections should have a version number of 1.0.1, though the master branch has the Argonaut version which was initially called v1.2, and is now v1.5 (but not yet changed in the IG).
Dan Gottlieb (Nov 01 2020 at 18:23):
@Grahame Grieve I updated the package-list.json for the IG to reflect the technical correction version (1.0.1) and at Lynn's request, updated the HL7 logo in the header. The branch to be deployed is at https://github.com/HL7/bulk-data/tree/tech-correct (http://build.fhir.org/ig/HL7/bulk-data/branches/tech-correct/) . I think the version numbers in this branch should be correct, but let me know if you spot anything that's off. Thanks!
Lynn Laakso (Nov 11 2020 at 02:21):
@Dan Gottlieb the package should be 1.1.0 not 1.0.1 can you update the tech-correct branch?
Dan Gottlieb (Nov 11 2020 at 14:15):
@Lynn Laakso - can you clarify why this change is needed? The FHIR spec, and other IGs like US Core seem to use a version number of x.x.1 for errata releases which aligns with the semantic versioning spec. If we make the version for the IG 1.1.0, won't people assume that the changes are material? Why have a three segment version at all if non-substantive error corrections don't use the third segment?
Lynn Laakso (Nov 11 2020 at 15:29):
@Grahame Grieve ?
Grahame Grieve (Nov 12 2020 at 20:09):
I agree that this one should be 1.0.1
Lynn Laakso (Nov 12 2020 at 20:10):
and subdirectory STU1.0.1?
Grahame Grieve (Nov 12 2020 at 20:11):
yes
Dan Gottlieb (Nov 13 2020 at 15:46):
@Lynn Laakso do you have a sense of when you'll be able to post the IG to the FHIR website (it would be great to have the corrected version up prior to Dev Days)?
Lynn Laakso (Nov 13 2020 at 15:51):
just hit a snag with publishing where the publisher had ERROR @ parameters: canonical URL of http://hl7.org/fhir/uv/bulkdata does not match the required canonical of http://hl7.org/fhir/us/bulkdata (src = Publisher)
Lynn Laakso (Nov 13 2020 at 15:52):
other cross-realm publications have needed his personal touch
Dan Gottlieb (Nov 13 2020 at 16:02):
Ah, ok - can you circle with Grahame on this?
Lynn Laakso (Nov 13 2020 at 16:07):
I PM'ed him directly but it's wee hours of Saturday morning for him
Grahame Grieve (Nov 13 2020 at 19:43):
hm. I might have to publish this one
Brett Marquard (Nov 17 2020 at 19:12):
Did it publish?
Brett Marquard (Nov 19 2020 at 13:25):
Sorry, I forgot how crazy devdays can be...
Brett Marquard (Nov 24 2020 at 15:04):
@Lynn Laakso and @Grahame Grieve - Is there anything @Dan Gottlieb can do to help?
Lynn Laakso (Nov 24 2020 at 15:39):
The IG has crossed realms between initial ballot and publication which makes it messy and a Grahame-only job I'm afraid.
Brett Marquard (Nov 24 2020 at 15:45):
Sounds extra fun, thanks Lynn.
Dan Gottlieb (Nov 30 2020 at 15:21):
@Grahame Grieve since @Lynn Laakso isn't able to post the bulk data technical correction to the website, is getting it posted on your to do list? Thanks!
Brett Marquard (Dec 01 2020 at 15:02):
@Lynn Laakso Is there someone other than Grahame that could take a look? I fear with ballot deadline looming GG is going to be slammed for a while...
Lynn Laakso (Dec 01 2020 at 15:05):
sadly no. I would help but the tooling now checks for cross-realm anomalies and will not proceed.
Grahame Grieve (Dec 06 2020 at 10:13):
I have did this
Last updated: Apr 12 2022 at 19:14 UTC
