FHIR Chat · Attachments workflow in practice · implementers

Stream: implementers

Topic: Attachments workflow in practice

---

Rowan Foster (Jun 02 2016 at 02:49):

Hi, it is not clear to me how attachments are supposed to work in practice when my application has collected the file to attach. The workflows that I can see seem either clunky or non-intuitive. Can anyone provide me with some clarity as to what the intended workflow/best-practice should be.

Given that I have a file/image locally that I have generated/captured and I wish to store it with a FHIR API eg DocumentReference, Observation. I have two options, base64 encode the file and pass that blob in the data field or upload that file/image somewhere and use that URL in the url field.

To me neither approach is particularly good for the following reasons.

base64 encode:

• Not really web/REST best practice
• Clients have to deal with decoding etc for display, they will already understand an image URL
• Makes responses heavy, particularly when retrieving a list of say DocumentReference and you don't actually want to display the content until a users selects an item

URL:

• Means you need to find somewhere suitable to upload the file which is not defined by FHIR
• I don't consider the Binary resource suitable as it does not seem to define sufficient standardized meta data which could be used to ensure that sensitive information cannot be accessed by inappropriate users eg which patient the image is for
• Spec seems to imply that the URL is fixed ie easily shareable (some health projects I've seen in the past have required session scoped URLs for such things)

The only solutions I can think of seem dubious or not to spec eg:

• Upload using base64 data, but have the resource convert this to a URL that applies the same security as the resource that contains the attachment (does the spec allow this?)
• Upload using base64 data, but have the resource convert this to a temporary/session scoped URL that for each appropriate retrieval of the resource holding the attachment (the spec implies to me that the URL is static?)
• Set custom meta tags when uploading the attachment to the binary resource so that it can apply appropriate security when the attachment is retrieved later

Thanks

John Moehrke (Jun 02 2016 at 12:26):

Rowan, Binary has just as much meta as any other resource, it can have the full security tags. What do you think is missing? Are you concerned with the absence of Patient identity? an access control infrastructure would look at these types of resources as different. Meaning that for resources that don't contain a patient identifier, there would be other rules to find a relationship such as through DocumentReference, or an Attachment. Once the relationship is found the Access Control decision can be patient specific. -- I expect use of Binary over base64 encoding; but sometimes it is right.

Rowan Foster (Jun 02 2016 at 20:14):

Yes, my primary privacy concern is that is no link to the subject Patient (if any) with the binary resource. A reverse lookup to discover the appropriate patient doesn't seem practical as there are 16 resources that refer to them, thus it is likely to be quite expensive to check them all. Also there will be a small window when the attachment is uploaded but it is not referred to in which there will be no patient found by the reverse lookup

Other meta data that may be useful for making access control decisions could be the type of an Observation/Document eg mental health report

Grahame Grieve (Jun 02 2016 at 21:03):

any rational server would pre-maintain the approvals. The concern isn't enforcing control, it's determining what the correct control to enforce is.

Grahame Grieve (Jun 02 2016 at 21:03):

If a binary was submitted as part of a transaction, I suppose that's an implicit thing.

Grahame Grieve (Jun 02 2016 at 21:05):

you could say that you'd only provide access to the binary if the user has access to a reference to it. In that window Rowan mentions, no one would have access to it. But the problem is that there might be binaries that anyone can access, and others that are restricted by group, and others that are individual specific. It's fine to delegate security to another level, but this is one area where we need to say something about the binding, I think

John Moehrke (Jun 03 2016 at 15:09):

Well said Grahame. I would note that there are appropriate Security_labels to indicate when a Binary is sensitive vs very pubic. This would be a good use of the _confidentiality evaluation. Where "U" would be used to indicate that the Binary instance is unrestricted. Where as a "N" indicates it is normal patient specific data. "R" would be restricted patient specific... etc... etc... --- This all a good example of the Security WG proposal for a "Security/Privacy Consideration" section to be added to every resource, not to duplicate the security page but to point out special considerations of that specific resource. --- GF#10126

Grahame Grieve (Jun 05 2016 at 11:29):

still. that doesn't tell me who to serve it up to...

Grahame Grieve (Jun 05 2016 at 11:30):

do we need a more specific tag?

Rowan Foster (Jun 06 2016 at 21:20):

So we seem to be saying that a reverse lookup for the uses of the binary resource needs to be performed to determine access restrictions. However that seems to be problematic as:

• Not mentioned in spec so server may not implement this or different vendor's implementations differ, causing headaches for client implementers
• Cannot use the FHIR API itself to implement this eg Observation has no search parameter for valueAttachment.url
• Means binary resources cannot be shared across FHIR servers as the reverse lookup will not be possible
• If a binary resource is referenced by multiple resources which do we use to determine security (presumably the most restrictive, but that means we have to find them all)

Rowan Foster (Jun 06 2016 at 22:19):

It has been suggested to me that I could use DocumentManifest to record the meta-data I need. This seems like it could work as it includes the subject (patient) and supports searching via the reference (ie DocumentManifest.content.pReference), and would mean only one resource to check. Is this an expected use case for the DocumentManifest resource or should access still be defined by the parent resource eg Observation? The scope and usages says it is for a set of DocumentReference, however the structure allows a reference to Any resource...

Grahame Grieve (Jun 07 2016 at 00:41):

well, another alternative for you is to use DocumentReference, and embed the data directly in the document reference. this way, you have all the metadata you need

Grahame Grieve (Jun 07 2016 at 00:42):

and then we document that if you do a read on a document reference, and you specify the content type of the document reference, then you get the content instead of the document reference (e.g. pretty much like what the binary resource does)

Rowan Foster (Jun 07 2016 at 03:41):

That sort of approach would certainly seem to be a step on the way to making things simpler. Although what would the attachment contents be when requesting FHIR XML/JSON of the DocumentReference? If it returns the base64 blob then the benefit of using a URL is gone ... I guess it could contain the DocumentReference URL and the Attachment contentType could indicate which which content type to use when requesting the attachment.

Also would need to consider what would happen when the cardinality of DocumentReference.content is two or greater, multi-part mime perhaps? (will browsers be able to handle that though?)

Also could this be applied to other places where attachments are used eg Observation?

Grahame Grieve (Jun 07 2016 at 12:26):

I don't know the answers to those questions

Paul Knapp (Jun 08 2016 at 06:19):

FM had originally proposed a resource to be used for attachments. FHIR core strongly suggested that DocumentMAnifest be used in place of that resource and FM submitted the needed changes to the DocumentManifest (for example it couldn't actually contain an attachment) andthe owning committee made he needed changes. Grahame are you suggesting that guidenace be changed to use DocumentReference or that we encourage two different ways to accomplish the same purpose?

Grahame Grieve (Jun 08 2016 at 08:11):

I don't know where DocumentManifest entered into this discussion, actually. The subject in question has been 'a binary resource'. Why would you use DocumentManifest?

Rowan Foster (Jun 19 2016 at 23:47):

If we consider a reverse lookup style process to validate the security of a Binary resource is best practice, could we use the HTTP referer header to provide the context in which to evaluate security? For example when accessing a Binary resource the referer header could be set to the FHIR resource the binary (attachment) URL was obtained from eg Referer: http://fhir3.healthintersections.com.au/open/Observation/123 It would then be the responsibility of the implementation of the Binary resource to:

• Validate that the binary resource being accessed was indeed being referenced by the referer resource
• Use the referer resource to evaluate relevant security ie does the accessing user have access to the subject of the referer resource

May need a new or existing security label on the Binary resource to indicate that the resource needs security checks. So if the referer tag is not present the server can decide whether to consider that a security check failure or just serve the resource as a security check is not necessary.

This approach seems to solve some of the questions I had around for reverse lookup ie using FHIR to implement reverse lookup, sharing attachment/Binary resources across servers, choosing which referencing resource to use when evaluating security.

However still has the issue that this is off spec so won't allow interchange of server implementations

Paul Knapp (Jun 20 2016 at 11:24):

We would use a DocumentManifest: a) because that way we can provide multiple attachments, DocumentManifest only allows one, and b) we were told to use it rather than the SupportingDocuments resource we had proposed. The DocumentManifest, like SupportingDocuments before it, supports: refering to the "thing" the attachments are supporting or in reference to; and a set of attachments which may be referred to (urls, resources, etc) or contained within.

Grahame Grieve (Jun 20 2016 at 22:37):

well, but how does that relate to Rowan's issue?

Grahame Grieve (Jun 20 2016 at 22:38):

Rowan - I don't think that standard RESTful client stacks do anything useful with regard to the referer header. how can they?

Grahame Grieve (Jun 20 2016 at 22:39):

I think we would have to be more explicit than that. But I can see that explicitly quoting your authority for the resource offers a potential solution to the problem

Brian Postlethwaite (Jun 20 2016 at 22:52):

Maybe i'm missing something, but the security is implemented by the server returning the content, not the client via queries, so is done internally.
Using a referrer header would be pretty simple to forge and get around that access control.

Grahame Grieve (Jun 20 2016 at 22:54):

I think you have. The question is, the server has a business rule that a binary is only available in certain cases .e.g this binary is only available to the patient and her care team

Grahame Grieve (Jun 20 2016 at 22:54):

when it gets

GET [base]/Binary/[id]

how does it decide whether the request comes from the patient or their care team?

Brian Postlethwaite (Jun 20 2016 at 22:55):

The authentication context, which is currently outside the spec right?

Brian Postlethwaite (Jun 20 2016 at 22:55):

The relationship of the binary to the patient is the questionable bit.

Grahame Grieve (Jun 20 2016 at 22:57):

oh right. read the back thread. the question is, when I post the binary to the server, how does the server know what the rules should be>

Brian Postlethwaite (Jun 20 2016 at 22:58):

But I think your other comments earlier in this topic were correct using the reverse lookups.
The server could have internal indexes that cover the security subject context (patient/practitioner) that are maintained when references are created
As for externally referred content, then this doesn't have any context.

Brian Postlethwaite (Jun 20 2016 at 22:58):

As with everything. its up to the server and local policy.

Brian Postlethwaite (Jun 20 2016 at 22:59):

Could be as simple as unless the "U"nrestricted tag is on it, its private to the creater until something else points to it.

Rowan Foster (Jun 21 2016 at 00:12):

I was suggesting the referer tag as a hint that will still require server validation that the binary url is in the referer resource, so I don't see how it can be forged.

If the server has internal indexes then there are a number of issues with this as I previously mentioned:

• Not mentioned in spec so server may not implement this or different vendor's implementations differ, causing headaches for client implementers
• Cannot use the FHIR API itself to implement this eg Observation has no search parameter for valueAttachment.url
• Means binary resources cannot be shared across FHIR servers as the reverse lookup/index will not be possible
• If a binary resource is referenced by multiple resources which do we use to determine security

John Moehrke (Jun 21 2016 at 13:33):

I entered GF#10126 on this topic. that is the topic that resources that don't have a natural linkage to a Patient are especially problematic regarding Privacy authorization enforcement. In this CP I recommend we just explain this as a security.privacy consideration; not try to solve it.

John Moehrke (Jun 21 2016 at 13:35):

There are many 'trust' issues wrapped in this discussion. When the server accepted the Binary resource it accepted with some authority (security layer); which likely included some busness rules as to why that Binary object should be accepted. Like that it was contained in a Bundle with Patient identifying information (such as MHD). Both business rules and security/privacy rules are outside the core specification; but need to be 'considered' carefully.

Rowan Foster (Jun 30 2016 at 02:40):

FYI My current plan is to use a modifier extension to specify the patient the file is for when uploading to FHIR Binary

Brian Postlethwaite (Jun 30 2016 at 02:42):

The Binary resource is one of the special resources that derives from "Resource" not "DomainResource" and hence it is not able to have Extensions, or ModifierExtentions.

David Hay (Jun 30 2016 at 02:46):

bother...

David Hay (Jun 30 2016 at 02:46):

Just out of interest - what else (apart from bundle) derives from Resource?

Brian Postlethwaite (Jun 30 2016 at 02:51):

Binary, Bundle, Parameters
http://hl7-fhir.github.io/domainresource.html#bnr

James Butler (Jun 30 2016 at 02:56):

In retrospect this makes perfect sense - it would be difficult to reconcile extensions with the special REST semantics of the Binary resource (how do you serve extensions for non-FHIR content types?)

Rowan Foster (Jun 30 2016 at 03:37):

Hmm, extensions are targeted at FHIR clients, however I'm really targeting the server (to apply security logic)

Grahame Grieve (Jun 30 2016 at 03:52):

I don't know why you say that.

Grahame Grieve (Jun 30 2016 at 03:52):

extensions are for everyone

Rowan Foster (Jun 30 2016 at 20:00):

I'm happy to be corrected, but that's what the wording around modifier extension implies to me eg "an application cannot safely process the resource unless it knows what the extension means for its own use of the data". An application processing the resource sounds like a client to me. Or is it expected that a server should only store a resource if it understands all modifier extensions also?

Grahame Grieve (Jun 30 2016 at 21:31):

the spec provides a definition for 'processing'. Storage and Transfer do not represent processing, but any change to the content, or extraction for presentation to a human or in another format do constitute 'processing', and most (if not all) servers do this to some degree (though the degree varies)

John Moehrke (Jul 02 2016 at 16:35):

@Rowan Foster can you explain your use of extensions "to apply security logic"? This sounds like trouble to me...

Grahame Grieve (Jul 02 2016 at 21:29):

just like security labels, but they are not a code=value pair, and so limited in their utility

Rowan Foster (Jul 03 2016 at 20:06):

@John Moehrke the server needs to decide whether the accessing user should be able to see the Binary image/file based on the Patient the image is of.

Rowan Foster (Jul 05 2016 at 01:49):

FYI, given that extensions cannot be used, I've started looking at custom operations instead. The options I'm currently considering are:

• Requiring the Binary file and the item referring to that file, eg an Observation, to be submitted as part of the same bundle and store a link to the patient or source observation along with the binary file so security rules can be applied on retrieval
• A custom operation that takes a binary and a patient id/reference that stores the binary file as usual but also includes a link to the patient so security rules can be applied on retrieval
• A custom operation that stores both the Observation (or DocumentReference, ...) & Binary in one step. A link is stored with the binary to the Observation to support security
• A custom operation that externalises inline attachments into Binary URL. With a link stored with the binary to the Observation to support security. ie on subsequent retrievals of observation there will be links to a Binary rather than an inline base64 blob that the input used

James Butler (Jul 05 2016 at 02:20):

Re. Rowan's fourth proposal, would we really need to use a custom operation? Given the kind of latitude FHIR allows to servers to do "what makes sense", I would think it would be OK to receive an Observation by the normal PUT or POST method and, if it contains an inline base64 blob, convert that to a separate Binary resource and alter the Observation attachment to contain a link instead.

Lloyd McKenzie (Jul 05 2016 at 02:37):

That sort of thing is certainly legal, but you have to use caution if there's any chance of the sender using digital signatures.

John Moehrke (Jul 05 2016 at 17:19):

@Rowan Foster Your third option is what DocumenReference is intended to do. This is how IHE organizes the FHIR resources to enable XDS like system, or a proxy to an XDS system. The access control decision is done by finding the DocumentReference that points at the specific Binary that is being Retrieved, it is the DocumentReference object that contains the metadata used in that access control decision.

Grahame Grieve (Nov 07 2016 at 22:29):

follow up to this - we are adding an element to Binary. see task GF#10126

---

Last updated: Apr 12 2022 at 19:14 UTC