Remote Patient Authorization and Submission of EHR Data for Research

Type	Standard / Implementation Specification	Standards Process Maturity	Implementation Maturity	Adoption Level	Federally required	Cost	Test Tool Availability
Emerging Implementation Specification	HL7® FHIR® RESTful API	Final	Production	Feedback Requested	No	Free
Emerging Implementation Specification	HL7® FHIR® Patient Reported Outcomes Implementation Guide	In Development	Pilot	Feedback Requested	No	$
Emerging Implementation Specification	Health Relationship Trust (HEART) Specification	In Development	Pilot	Feedback Requested	No
Emerging Implementation Specification	SMART on FHIR	Final	Feedback requested	Feedback Requested	No	Free	Yes

Limitations, Dependencies, and Preconditions for Consideration	Applicable Value Set(s) and Starter Set(s)
See Sync for Science and Sync for Genes for more details about the research project use case that pertains to this interoperability need. To learn more about how APIs can help patients participate in research, see the Patient Engagement Playbook. The Kantara Initiative's UMA (User Managed Access) Work Group project's use case is designed to develop specifications that allow individual control of authorized data sharing and service access to promote interoperability in support of this interoperability need. See FHIR, API, and Open API projects in the Interoperability Proving Ground. Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used when data is being exchanged between patients and providers. The SMART on FHIR Project is working in this area, and may have additional implementation guidance, as well as a list of applications supporting this interoperability need. When using the SMART on FHIR model, the authentication model is OAuth2. The other security patterns listed do not apply.	System Authentication – The information and process necessary to authenticate the systems involved User Details – identifies the end user who is accessing the data User Role – identifies the role asserted by the individual initiating the transaction Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed May be required to authorize any exchange of patient information May be required to authorize access and use of patient information May be required to be sent along with disclosed patient information to advise the receiver about policies to which end users must comply Purpose of Use – Identifies the purpose for the transaction Security Labeling – the health information is labeled with security metadata necessary for access control by the end user

Limitations, Dependencies, and Preconditions for Consideration

Applicable Value Set(s) and Starter Set(s)

See Sync for Science and Sync for Genes for more details about the research project use case that pertains to this interoperability need.
To learn more about how APIs can help patients participate in research, see the Patient Engagement Playbook.
The Kantara Initiative's UMA (User Managed Access) Work Group project's use case is designed to develop specifications that allow individual control of authorized data sharing and service access to promote interoperability in support of this interoperability need.
See FHIR, API, and Open API projects in the Interoperability Proving Ground.
Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used when data is being exchanged between patients and providers.
The SMART on FHIR Project is working in this area, and may have additional implementation guidance, as well as a list of applications supporting this interoperability need.
When using the SMART on FHIR model, the authentication model is OAuth2. The other security patterns listed do not apply.

System Authentication – The information and process necessary to authenticate the systems involved
User Details – identifies the end user who is accessing the data
User Role – identifies the role asserted by the individual initiating the transaction
Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed
- May be required to authorize any exchange of patient information
- May be required to authorize access and use of patient information
- May be required to be sent along with disclosed patient information to advise the receiver about policies to which end users must comply
Purpose of Use – Identifies the purpose for the transaction
Security Labeling – the health information is labeled with security metadata necessary for access control by the end user

Comment