State Issued ID for Healthcare

From IDESG Wiki
Revision as of 04:03, 14 December 2020 by Tomjones (talk | contribs) (→‎References)
Jump to navigation Jump to search

Full Title

Use case for a state ID that follows the mobile driver's license as identity proofing credential in healthcare service (aka Medicaid).

Prepared by

Kantara Healthcare Identity Assurance Work Group

Context

  • This use case roughly follows the Commonwealth of Virginia example of the DMV running state issued identifiers for services. This scenario is one (or two) of them.
  • Most states now use a Healthcare specific identification card (eg the Washington State Apple Card). This use case looks forward to the case where the state has combined all identification cards into a single system.
  • It is possible that the state will determine that a single card that services all purposes would be indistinguishable on the web from a mobile driver's license. In that case the permission to drive would just be one attribute of the state ID card.
  • Other health issues, including organ donor information, would likely be included as attributes in such a card.

Goal

  1. To enable the enrollment of a patient with a healthcare identifier that qualifies the holder for state health services.
  2. Enable remote registration at public libraries or Public Health Centers.

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. (Note that these could be a part of the healthcare system, but could equally be in a centralized state Identifier-issuing agency like the DMV).
  4. Actor: State Healthcare system together with a card that is issued to patients that qualify for public assistence.

Preconditions

  1. The patient is in need of healthcare using mobile device and is not currently enrolled for state services with a state issued identification card.
  2. The patient has access to a mobile device that can authenticate the user and communicate to the physician or pratice.
  3. Alternate use case, the patient only has a library or other public computer.
    1. For the purposes of registration the registration device must have a camera.
    2. Or the patient must already be registered with a state issued card that has their picture, such as a driver's license.

Scenarios

Primary Scenario:

  1. Patient does not have adequate healthcare coverage and applies to the state for assistance.
  2. Patient receives notice of appointment and instructions for online registration, or in person if she wants to face the challenges that could attend in-person registration.
  3. 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.
  4. Patient has an insurance card that is machine readable.
  5. Patient has a mobile wallet that holds the MDL and can take a picture of the insurance card.
  6. 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.
  7. Her wallet understands that an image of some sort is required and helps with the image capture.
  8. The data required from the MDL, the image capture and potential other data is presented to the user as a consent screen.
  9. The patient chooses to send the data to the telemedicine web site.
  10. 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.

Problems

  1. The patient is one of the 19% of the population w/o a smart phone. Perhaps her grandchild can help with that.
  2. Some states are not very careful to limit the exposure of user private information on a driver's license today (2020-12).
  3. Getting the wallet into the patients smart phone or lap top may prove to be challenging.
  4. The patient is not comfortable with technology.
  5. The cost of the healthcare card is so high in terms of money or legal jeopardy that the patient avoids applying for the card.

Open Questions

  1. Who determines what data from the ID card is sent to the EHR? (eg. the healthcare community specs or explicit user consent)?
  2. Is the state issued (eg driver's license) ID number included in any way?
  3. Is a picture required in all cases.
  4. Is fraud a part of the working group's remit.

Outcome

  1. The patient is correctly matched to their electronic health records that may have started when the patient had employer-paid health care.
  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.

References

Retrieved from "https://wiki.idesg.org/index.php?title=State_Issued_ID_for_Healthcare&oldid=15438"