Mobile Driver's License in Healthcare: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
 
(32 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Full Title==
== Full Title==
Use case for the mobile driver's license as identity proofing credential in healthcare telemedicine.
Use case for the mobile driver's license as identity proofing credential in healthcare telemedicine.
===Prepared by===
Kantara Healthcare Identity Assurance Work Group
==Context==
==Context==
The mobile drivers license
The mobile driver's license makes many new possibilities available. This scenario is one (or two) of them.
===Goal===
===Goal===
To enable the enrollment of a remote patient with a healthcare identifier and [https://tcwiki.azurewebsites.net/index.php?title=EHR Electronic Health Record (EHR)] which is accessible by the patient or other [[Guardian]].
To enable the enrollment of a remote patient with a healthcare identifier and [https://tcwiki.azurewebsites.net/index.php?title=EHR Electronic Health Record (EHR)] which is accessible by the patient or other proxy.


===Actors===
===Actors===
#Actor: Patient
#Actor: Patient
#Actor: [[Guardian]] is used here to mean any person that can help the patient get registered. It could be a patient, spouse, nursing home personnel, public health professional or similar.
#Actor: Proxy is used here to mean any person that can help the patient get registered. It could be a patient, spouse, nursing home personnel, public health professional or similar.
#Actor: Healthcare intake personnel.
#Actor: Healthcare intake personnel and potentially the physician for creating followup actions by the patient.


==Preconditions==
==Preconditions==
*The patient is is need of telemedicine and is not currently known to the practice.
* The patient is in need of healthcare using telemedicine and is not currently known to the practice.
* The patient has access to a mobile device that can authenticate the user and communicate to the physician or pratice.
===Trigger===
The Patient has an appointment that is their very first one via their computer.


==Scenarios==
==Scenarios==
Primary Scenario:
Primary Scenario:
# Patient receives notice of appointment and instructions for online registration, or in person if they want to risk it.
# Patient receives notice of appointment and instructions for online registration, or in person if she wants to risk it.
# Patient has a mobile driver's license (MDL) and doesn't want to travel to the doctors office, which is why she chose telemedicine in the first place.
# Patient has a mobile driver's license (MDL) and doesn't want to travel to the doctor's office, which is why she chose telemedicine in the first place.
# Patient has an insurance card that is machine readable.
# Patient has an insurance card that is machine readable.
# Patient has a mobile wallet that holds the MDL and can take a picture of the insurance card.
# Patient has a mobile wallet that holds the MDL and can take a picture of the insurance card.
Line 27: Line 33:
Bonus capability.
Bonus capability.
# The patient is asked for prior health history and is able to navigate to her PCP and get a QR code that can be included in the message to the telemedicine site which can get the history data.
# The patient is asked for prior health history and is able to navigate to her PCP and get a QR code that can be included in the message to the telemedicine site which can get the history data.
# The patient has a wallet that can authenticate the user's presence and allows the user to enter their existing driver's card as a machine-readable image.


Secondary Scenario:
Secondary Scenario:
# Patient schedules a lab visit after the telemedicine session is completed.
# Patient schedules a lab visit after the telemedicine session is completed.


==Problems==
Tertiary Scenario:
# Getting the wallet into the patients smart phone or lab top may prove to be challenging.
# The patient's grandchild acts on her behalf as an access proxy.
 
==Successful Outcome==
# The patient is correctly matched to their electronic health record.
# The patient has a successful telemedicine experience, receives a set of reports, is schedules for a lab test and immunization at the local pharmacy.
# Follow up procedures are created and sent to her smartphone and give her notices when she must take medicine or other procedures.
 
==Unsuccessful Outcome==
# Not all of the patient's records are available on-line and some action in the real-world is required to get them altogether.
# The Telemedical connection fails or is not of sufficient quality for the physician to complete the examination.
# The patient feels that the quality of care was not sufficient to meet their needs.
 
==Privacy Concerns==
* The EHR may release more information that is required for the current visit.
* The patient may be in close quarters with others that should not hear the results of the session.
 
==Issues==
# The patient is one of the 19% of the population w/o a smart phone. Perhaps her grandchild can help with that.
# Getting the wallet into the patient's smart phone or lap top may prove to be challenging.
# The patient is not comfortable with technology.
# The patient is not comfortable with technology.
# Who determines what data from the MDL is sent to the EHR?  (e.g., the healthcare community specs or explicit user consent)?
# Is the driver's license ID number included in any way?
# Is a picture required for patient record matching to the person on the telemedicine call.
# Is fraud one of the threats to be addressed within the scope of the recommendation?


==Outcome==
==References==
This use case was updated on 2021-11-11.


==References==
* [[Mobile Driver's License]] on this wiki.
* [[Mobile Driver's License]] on this wiki.
* [[State Issued ID for Healthcare]] on this wiki.


[[Category:Profile]]
[[Category:Profile]]
[[Category:Health]]
[[Category:Health]]
[[Category:Use Cases]]
[[Category:Use Cases]]

Latest revision as of 05:23, 13 November 2021

Full Title

Use case for the mobile driver's license as identity proofing credential in healthcare telemedicine.

Prepared by

Kantara Healthcare Identity Assurance Work Group

Context

The mobile driver's license makes many new possibilities available. This scenario is one (or two) of them.

Goal

To enable the enrollment of a remote patient with a healthcare identifier and Electronic Health Record (EHR) which is accessible by the patient or other proxy.

Actors

  1. Actor: Patient
  2. Actor: Proxy is used here to mean any person that can help the patient get registered. It could be a patient, spouse, nursing home personnel, public health professional or similar.
  3. Actor: Healthcare intake personnel and potentially the physician for creating followup actions by the patient.

Preconditions

  • The patient is in need of healthcare using telemedicine and is not currently known to the practice.
  • The patient has access to a mobile device that can authenticate the user and communicate to the physician or pratice.

Trigger

The Patient has an appointment that is their very first one via their computer.

Scenarios

Primary Scenario:

  1. Patient receives notice of appointment and instructions for online registration, or in person if she wants to risk it.
  2. Patient has a mobile driver's license (MDL) and doesn't want to travel to the doctor's office, which is why she chose telemedicine in the first place.
  3. Patient has an insurance card that is machine readable.
  4. Patient has a mobile wallet that holds the MDL and can take a picture of the insurance card.
  5. Patient navigates to the telemedicine web site which can send a message to her wallet to provide the mdl and insurance card as an image.
  6. Her wallet understands that an image of some sort is required and helps with the image capture.
  7. The data required from the MDL, the image capture and potential other data is presented to the user as a consent screen.
  8. The patient chooses to send the data to the telemedicine web site.
  9. The visit with the physician can start immediately, or when the physician becomes available.

Bonus capability.

  1. The patient is asked for prior health history and is able to navigate to her PCP and get a QR code that can be included in the message to the telemedicine site which can get the history data.
  2. The patient has a wallet that can authenticate the user's presence and allows the user to enter their existing driver's card as a machine-readable image.

Secondary Scenario:

  1. Patient schedules a lab visit after the telemedicine session is completed.

Tertiary Scenario:

  1. The patient's grandchild acts on her behalf as an access proxy.

Successful Outcome

  1. The patient is correctly matched to their electronic health record.
  2. The patient has a successful telemedicine experience, receives a set of reports, is schedules for a lab test and immunization at the local pharmacy.
  3. Follow up procedures are created and sent to her smartphone and give her notices when she must take medicine or other procedures.

Unsuccessful Outcome

  1. Not all of the patient's records are available on-line and some action in the real-world is required to get them altogether.
  2. The Telemedical connection fails or is not of sufficient quality for the physician to complete the examination.
  3. The patient feels that the quality of care was not sufficient to meet their needs.

Privacy Concerns

  • The EHR may release more information that is required for the current visit.
  • The patient may be in close quarters with others that should not hear the results of the session.

Issues

  1. The patient is one of the 19% of the population w/o a smart phone. Perhaps her grandchild can help with that.
  2. Getting the wallet into the patient's smart phone or lap top may prove to be challenging.
  3. The patient is not comfortable with technology.
  4. Who determines what data from the MDL is sent to the EHR? (e.g., the healthcare community specs or explicit user consent)?
  5. Is the driver's license ID number included in any way?
  6. Is a picture required for patient record matching to the person on the telemedicine call.
  7. Is fraud one of the threats to be addressed within the scope of the recommendation?

References

This use case was updated on 2021-11-11.