Skip to content
This repository has been archived by the owner on Apr 13, 2023. It is now read-only.

Support Patient Everything #103

Closed
arthuston opened this issue Jul 27, 2021 · 2 comments
Closed

Support Patient Everything #103

arthuston opened this issue Jul 27, 2021 · 2 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@arthuston
Copy link

arthuston commented Jul 27, 2021

Is your feature request related to a problem? Please describe.
The Payer-to-Payer requirement allows a Member to authorize a Payer (the 'New' Payer) to access the user's data at another Payer (the 'Old' Payer). The most common use case is when a Member changes health plans, however, the Member changing plans is not a requirement. They could, for example, be part of two health plans.

The Payer-to-Payer requirement is vague on how this should work, particularly in how the Member would be able to grant the access, however, there are FHIR Server needs two capabilities we will need to implement this: Patient Everything, and Bulk Upload.

Describe the solution you'd like
Support Patient Everything: The Patient Everything operation extends the FHIR Patient Endpoint to allow requests for all patient data. The response is a bundle of type "searchset". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user.

When this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made asynchronously, and associated with bulk data formats. The operation to access multiple patient records at once is not required for Payer to Payer.. The requirement states that a single patient should return data synchronously as a bundle, however, this may return thousands of records and potentially timeout -- an asynchronous operation should be strongly considered.

Our preliminary design is to write the information to an S3 bucket where it can be read using a signed URL with TTL.

Additionally, the OAUTH2 scopes must be used to determine which records will be returned. Typically, the scopes will provide access to the Clinical Records (e.g. Patient/Observation.read, etc) for the Patient and exclude Payment Records (Patient/ExplanationOfBenefit.read, etc.)

Describe alternatives you've considered
Data could be extracted by calling all endpoints and combining the data.

Additional context
None.

@arthuston arthuston added the enhancement New feature or request label Jul 27, 2021
@rsmayda rsmayda added the help wanted Extra attention is needed label Aug 19, 2021
@rsmayda
Copy link
Contributor

rsmayda commented Aug 19, 2021

Thanks Art as discussed lets work closely on prototyping this!

@kcadette
Copy link
Contributor

kcadette commented Apr 3, 2023

FHIR Works on AWS has been moved to maintenance mode. While in maintenance, we will not add any new features to this solution. All security issues should be reported directly to AWS Security at aws-security@amazon.com. If you are new to this solution, we advise you to explore using HealthLake, which is our managed service for building FHIR based transactional and analytics applications. You can get started by contacting your AWS Account team. If you are an existing customer
of FHIR Works on AWS, and have additional questions or need immediate help, please reach out to fwoa-migration-support@amazon.com or contact your AWS Account team.

@kcadette kcadette closed this as completed Apr 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants