Stream: implementers
Topic: Include a Recommended Pattern for Exposing Valid Operations
Rick Geimer (Jan 28 2019 at 21:01):
FHIR-I wants to gather input from implementers on the following tracker item:
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=5884
The tracker proposes the following, and we would like to know if the community thinks this approach is useful, and if so why. If not we will likely reject the proposal.
For each resource returned from a read, vread, search, or other operation; each valid instance level operation on that resource is returned as a link associated with the resource. The relation of the link identifies the operation, the URL is the URL to follow to perform that operation.
For type level operations such as create, the same approach is followed with the create operation being returned associated with the search bundle. The conceptual model behind this is that create is an operation performed on the list.
Example: A read of an observation that the user is able to update.
GET /fhir-dstu2/obsevation/5
Would return a HTTP Link header such as:
Link: </fhir-dstu2/obsevation/5>; rel="update", </fhir-dstu2/obsevation/5>; rel="read"
John Moehrke (Jan 28 2019 at 21:15):
The statement about the security labels doesn't recognize that the labels on any specific Resource is for that Resource, where the security labeles on a Bundle are applicable to the context of the Bundle. Thus there is a method of communicating actor/context specific security labels, use the Bundle meta.security. This said, the overall proposal is more broad and useful...
First, the Link: header would only be returned to trusted clients able to utalize this. Thus where there is minimal trust the header can be not provided. The Link header is just advice, it is not a guarantee that the client will be able to do an 'update'. As long as these are clear, it should be okay to provide this method of improving the client side processing.
Michele Mottini (Jan 28 2019 at 22:22):
Seems bad: forces the servers to compute what is permitted or not on all read from all client for the benefit of the minority of client that actually need that information.
John Moehrke (Jan 29 2019 at 15:09):
I would expect that if it is expensive to calculate the link header on the server, then that server will likely never offer it. It clearly would be a policy choice on the server to calculate and offer the link header. I would expect that some systems will find it trivial to add the link header, especially when it is just a reflection of the OAuth scope (which is my worry that it is just another path for the same data)... Thus I think I am agreeing with @Michele Mottini that the most useful implementation would be expensive. That is where the response recognizes not just OAuth scope but also other business rules such as, but not limited to, consent status.
Grahame Grieve (Jan 29 2019 at 20:40):
right, it would only be useful if it got into the nuts and bolts.
Grahame Grieve (Jan 29 2019 at 20:41):
Josh suggested, i think, that there be some way for the client to ask if an operation is ok before letting the user waste minutes doing the data entry for it, but not to require the server to figure that out every single request (and search!)
Grahame Grieve (Jan 29 2019 at 20:42):
but no one is saying 'yes please, want this'
Julia Chan (Mar 10 2019 at 00:46):
Hi, 'Yes please, want this, need this, may we have this?':bow:please
Julia Chan (Mar 10 2019 at 00:47):
US Requirements Notes > Scenario 1 - PHRS FM R2>http://wiki.hl7.org/index.php?title=Personal_Health_Record_(PHR)> FileName >EHRSFM_R2_PHRSFM_R2_N1_2018JAN_Functionlist_draft_20180819.xlsx >Cells>O13,O14, O15 - "The PHR-S SHOULD NOT transmit an indications that information has been withheld by the PHR Account Holder to any stakeholder with whom the information is shared "unless required" according to organizational policy and/or jurisdictional law."- Need to find mechanism to document override by org policy or county/state/fed regulations. (cell O14) Need also mechanism for indicator to provider if there is information withheld (cell O13), which may influence treatment options , outcome & payment in value based care ecosystem. Since the consent process perhaps is highly integrated with data access control, patient apps may potentially allow them to designate/withold fine grained components which may change without notice to provider. It would be of great benefit to have a security resource in W5 format with (duration) that capture the User/RBAC definitions to FHIR assets, such that providers are aware of their security privileges for their patients and also at each practice location. Scenario 2 - It may also be applicable during emergencies in enhancing ability to "break glass" but also recover gracefully using W5 security + (perhaps provider taxonomy roles > http://www.wpc-edi.com/reference/codelists/healthcare/health-care-provider-taxonomy-code-set/).
Thank you for your time and consideration. Much Appreciated, and Congratulations on FHIR being named as Standard for CMS/ONC.
Julia Chan (Mar 13 2019 at 19:34):
Hi, Funding announcement 03.11.19 :cartwheel:♀️NAP-AX-18-003 on work related to this topic >https://www.healthit.gov/topic/onc-funding-opportunities/leading-edge-acceleration-projects-leap-health-information. Thanks much in advance.🙏
Last updated: Apr 12 2022 at 19:14 UTC
