State Issued ID for Healthcare

From IDESG Wiki
Jump to navigation Jump to search

Full Title

Use case for a state ID describes how the mobile driver's license can be used as identity proofing credential in healthcare service (aka Medicaid).

Prepared by

Kantara Healthcare Identity Assurance and Federated Identifiers for Resilient Ecosystems Work Groups.

Goals

  1. States will make all of their state issued identifier compatible with the mDL.
  2. These identifiers MUST be able indicate if they do provide IAL2 assurance like any Real-ID would.
  3. Data will not be transferred without appropriate consent (reference the HIPAA regulations.)

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.
  • Many 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.

Expected Outcomes

  1. To enable the enrollment of a patient with a healthcare identifier that qualifies the holder for state health services.
  2. To enable remote registration at public libraries or Public Health Centers.
  3. To ensure that patient is matched to all pertinent existing healthcare records.

Actors

  1. Actor: Patient, Subject of the State Issued ID
  2. Actor: Proxy is used here to mean any person that can help the patient get registered. It could be a parent 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 (the patient has a smartphone):

  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) or other state-issued ID. (Alternate documents may be used depending on state regulations.)
  4. Patient has some evidence of prior healthcare coverage, such as an expired health insurance card or current primary physician. (This is not required but would help with patient matching.)
  5. Note that most states require some proof of residency. This can be as simple as a statement from an employer or a pay stub. Each state will have their own requirements.
  6. Patient has a mobile wallet that holds the MDL and can take a picture of the insurance card.
  7. 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.
  8. Her wallet understands that an image of some sort is required and helps with the image capture.
  9. The data required from the MDL, the image capture and potential other data is presented to the user as a consent screen.
  10. The patient chooses to send the data to the telemedicine web site.
  11. 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 physician's EHR and get a QR code that can be included in the application to the state which can link the history data.
  2. The patient has an application (aka 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 does not have (or will not use) a smartphone.
  2. The state can issue a machine readable card that can be scanned at the providers office in the same machine that can scan driver's licenses.

Tertiary Scenario:

  1. The patient's immunization status can be included for building or travel access.

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 scheduled 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 schedule an appointment for a follow up shot.

Existing Experiences

  • Several states and app developers have created "driver's license apps". Two states (CO & LA) appear to have working systems in place prior to the completion of the ISO standard.
  • It appears that the trend is for some well-established identifier supplier to offer a turn-key solution to states that comes with a "wallet" that only handles the one credential.
  • In LA there is also an app "Healthy Louisiana" that handles Medicaid or LaCHIP enrollment. There appears to be no synergy between this and the "LA Wallet" app.
  • Interoperability apparently has not even been addressed, but the state DMVs have not yet provided any real data on their implementations.

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.
  6. Proxy consent needs to be defined for those patients that cannot make decisions for themselves.

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. Patient consent is not yet well described. It is suggested that a taxonomy of categories for patients to select might be a good next step.
  3. How should revocation of consent be included in the protocol.
  4. Is the state issued (eg driver's license) ID number included in any way? (Seems to be yes In most cases.)
  5. Is a picture required in all cases.(For example religious objections to taking a picture.)
  6. Is fraud reduction a part of the working group's remit.
  7. How would 13 and under children be accommodated for example immunizations in travel. (The ages vary from state to state. In Va the agre break-down is under 16 and under 21.)
  8. Should this use case be extended to include ID issued by schools or military as IDs as those do have legal status in many cases.

References

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