FHIR to the Patient Use Case - Revision history

Tomjones: /* Scenarios */

2020-05-19T04:07:46Z

Scenarios

← Older revision		Revision as of 04:07, 19 May 2020
Line 36:		Line 36:
	#The information in the packet is evaluated by the EHR and found to meet the requirements for releasing the data.		#The information in the packet is evaluated by the EHR and found to meet the requirements for releasing the data.
	#The EHR displays the choices in data release requested by the user as well as the information provided by the app so that the user understand what risk they face.		#The EHR displays the choices in data release requested by the user as well as the information provided by the app so that the user understand what risk they face.
	#The user		#The user chooses to download the data which can happen in the background while the. user goes about their business.

	Alternative Path1:		Alternative Path1:

Tomjones: /* Scenarios */

2020-05-19T04:05:43Z

Scenarios

← Older revision		Revision as of 04:05, 19 May 2020
Line 44:		Line 44:
	## If the user proofing was not sufficient the site should make a recommendation as to the steps the use needs to take to rectify the problems.		## If the user proofing was not sufficient the site should make a recommendation as to the steps the use needs to take to rectify the problems.
	## It is expected that the federation would be appropriate to make a judgement as to the qualifications of the proofing of the identifier and the authentication, if not the descrepancy should be explained to the user together with remedies. This could happen if the data transfer crossed between jurisdictions that did not share a minimal set of criteria for sharing data.		## It is expected that the federation would be appropriate to make a judgement as to the qualifications of the proofing of the identifier and the authentication, if not the descrepancy should be explained to the user together with remedies. This could happen if the data transfer crossed between jurisdictions that did not share a minimal set of criteria for sharing data.
			# A good user experience would seek to recover as much of the user effort as possible to minimize the time required to recover.

	Alternative Path2:		Alternative Path2:

Tomjones: /* Scenarios */

2020-05-19T04:04:31Z

Scenarios

← Older revision		Revision as of 04:04, 19 May 2020
Line 33:		Line 33:
	#Patient queries a known Medical [[Record Locator Service]] (MRLS) to see what sites have his data online and accessible. (Always optional and may not be complete in the early years of the Cures Act.)		#Patient queries a known Medical [[Record Locator Service]] (MRLS) to see what sites have his data online and accessible. (Always optional and may not be complete in the early years of the Cures Act.)
	#Patient uses the medical record locator, either from the website of the provider, or from the MRLS, to request data.		#Patient uses the medical record locator, either from the website of the provider, or from the MRLS, to request data.
			#The packet of the data request from the user provides the information that the user agent has on the proofing complete on identity, authentication and federation for the EHR authorization process.
			#The information in the packet is evaluated by the EHR and found to meet the requirements for releasing the data.
			#The EHR displays the choices in data release requested by the user as well as the information provided by the app so that the user understand what risk they face.
			#The user

	Alternative ~~Paths~~:		Alternative Path1:
			#The data did not meet the EHR requirements for releasing data. Or the user decided that the environment into which the data would be release is not sufficient to satisfy their desire for security and privacy.
			# An alternative path for the user is described.
			## If the application was not from a certified developer the site could make a recommendation as to some apps that are certified.
			## If the user proofing was not sufficient the site should make a recommendation as to the steps the use needs to take to rectify the problems.
			## It is expected that the federation would be appropriate to make a judgement as to the qualifications of the proofing of the identifier and the authentication, if not the descrepancy should be explained to the user together with remedies. This could happen if the data transfer crossed between jurisdictions that did not share a minimal set of criteria for sharing data.

			Alternative Path2:
	# The Primary Care Physician has placed the patient records in an EHR that regularly performs scans of all patients in the EHR for health conditions.		# The Primary Care Physician has placed the patient records in an EHR that regularly performs scans of all patients in the EHR for health conditions.
	# The patient is informed that health concerns are indicated and requests consent from the user to scan other health care records.		# The patient is informed that health concerns are indicated and requests consent from the user to scan other health care records.

Tomjones: /* Scenarios */

2020-05-19T03:53:33Z

Scenarios

← Older revision		Revision as of 03:53, 19 May 2020
Line 31:		Line 31:
	#Patient wants to participate in their own care plan.		#Patient wants to participate in their own care plan.
	#Patient searches for an appropriate app to load onto their computing device (for this purposes of this scenario).		#Patient searches for an appropriate app to load onto their computing device (for this purposes of this scenario).
	#Patient queries ~~the he~~ Medical [[Record Locator Service]] (MRLS) to see what sites have his data online and accessible. (Always optional and may not be complete in the early years of the Cures Act.)		#Patient queries a known Medical [[Record Locator Service]] (MRLS) to see what sites have his data online and accessible. (Always optional and may not be complete in the early years of the Cures Act.)
	#Patient uses the medical record locator, either from the website of the provider, or from the MRLS, to request data.		#Patient uses the medical record locator, either from the website of the provider, or from the MRLS, to request data.

Tomjones: /* Preconditions */

2020-05-18T23:48:51Z

Preconditions

← Older revision		Revision as of 23:48, 18 May 2020
Line 18:		Line 18:

	==Preconditions==		==Preconditions==
	*The patient has a care provider with up-to-date medical conditions, prescriptions and allergies that the patient wants to load to their own computing device.		*The patient has a care provider with up-to-date medical conditions, prescriptions and allergies (records) that the patient wants to load to their own computing device.
	*The PCP uses an EHR which is part of the US Healthcare Assurance Framework.		*The PCP uses an EHR which is part of the US Healthcare Assurance Framework.

Tomjones: /* Full Title */

2020-05-18T23:47:51Z

Full Title

← Older revision		Revision as of 23:47, 18 May 2020
Line 1:		Line 1:
	==Full Title==		==Full Title==
	The healthcare patient in the US has the legal ~~capability~~ to download their data in a Machine-readable format like FHIR.		The healthcare patient in the US has the legal authority to download their data in a Machine-readable format like FHIR.

	==Context==		==Context==

Tomjones: /* What's Missing */

2020-05-18T23:42:54Z

What's Missing

← Older revision		Revision as of 23:42, 18 May 2020
Line 68:		Line 68:
	# Requirements for the app developer certification.		# Requirements for the app developer certification.
	# Trust Authority where the EHR can validate the certifications of the app trying to access PHI.		# Trust Authority where the EHR can validate the certifications of the app trying to access PHI.
	# While there are many protocols for stating user identifiers there is as yet on single, unified format for stating the:		# While there are many protocols and data formats for stating user identifiers there is as yet no single, unified format for stating the:
	## Identifier of the user and level of identifier proofing of that identifier.		## Identifier of the user and level of identifier proofing of that identifier.
	## certifications of the app developer		## certifications of the app developer

Tomjones: /* Goal */

2020-05-18T23:41:36Z

Goal

← Older revision		Revision as of 23:41, 18 May 2020
Line 7:		Line 7:
	* The ONC has asserted that any app that is from a "certified" developer should be able to down load data from and EHR to the patient. The primary use case will focus on that decision by the EHR to allow downloads.		* The ONC has asserted that any app that is from a "certified" developer should be able to down load data from and EHR to the patient. The primary use case will focus on that decision by the EHR to allow downloads.
	===Goal===		===Goal===
	Release of patient's health information (PHI) ~~can~~ only ~~occur~~ if the Electronic Health Record (EHR) holder has trust that it can (1) accurately identify the requester, (2) validate the request itself, and (3) certification requirements for the app developer (which have not yet been determined.)		Release of patient's health information (PHI) is only permitted if the Electronic Health Record (EHR) holder has trust that it can (1) accurately identify the requester, (2) validate the request itself, and (3) certification requirements for the app developer (which have not yet been determined.)

	===Actors===		===Actors===

Tomjones: /* Threats */

2020-05-18T23:40:31Z

Threats

← Older revision		Revision as of 23:40, 18 May 2020
Line 25:		Line 25:
	*The user has a legal right to load the data to a device and app of their own choosing, but that app must be from a certified developer as specified in the 2020-05-01 final rule.		*The user has a legal right to load the data to a device and app of their own choosing, but that app must be from a certified developer as specified in the 2020-05-01 final rule.
	*This puts the EHR between a rock and a hard place with little guidance of how to make the choice of whether to release PHI to a request received from the internet.		*This puts the EHR between a rock and a hard place with little guidance of how to make the choice of whether to release PHI to a request received from the internet.
	*The following is one that the EHR could navigate in making that choice.		*The following is one use case that the EHR could navigate in making that choice.

	==Scenarios==		==Scenarios==

Tomjones: /* Actors */

2020-05-18T23:39:26Z

Actors

← Older revision		Revision as of 23:39, 18 May 2020
Line 14:		Line 14:
	#[[Record Locator Service]](RLS) = provides the ability to identify where records are located based upon criteria such as a Person ID and/or record data type, as well as providing functionality for the ongoing maintenance of this location information.		#[[Record Locator Service]](RLS) = provides the ability to identify where records are located based upon criteria such as a Person ID and/or record data type, as well as providing functionality for the ongoing maintenance of this location information.
	#Provider = A clinician or organization that is directly engaged in treatment services. Data or transactions generated by the provider are sent to the data source, the EHR.		#Provider = A clinician or organization that is directly engaged in treatment services. Data or transactions generated by the provider are sent to the data source, the EHR.
	#Patient = A person who is the subject of health records, or an authorized representative acting on such a person’s behalf (aka guardian).		#Patient = A person who is the subject of health records, or an authorized representative acting on such a person’s behalf (aka guardian). The term user refers to either party.
	#Transaction = Per the HL7 website; an interaction that submits a set of actions to perform on a server as a single atomic action. Multiple actions on multiple resources of the same or different types may be submitted, but are not likely in a patient device. The transaction is a message that is created by the user but then has a life of its own until it completes. At that point a notification should be created to be directed to the user's agent.		#Transaction = Per the HL7 website; an interaction that submits a set of actions to perform on a server as a single atomic action. Multiple actions on multiple resources of the same or different types may be submitted, but are not likely in a patient device. The transaction is a message that is created by the user but then has a life of its own until it completes. At that point a notification should be created to be directed to the user's agent.