Skip to main content

eRegister and Get Rid of the Clipboard

The Real Use Case for Personal Health Records (PHR)


I have been at this, HIE game, for a few years or so now. And when I go out and meet new people, I get the typical, "so, what do you do" question. Once I tell them and give a little explanation of what it means, about half of them have a follow-up question. There is only ever one follow-up question and it is always the same question "so, are you going to get rid of that clipboard of paperwork that I have to do over and over again every time I go to see a doctor".

The fact that I only get one question from general consumers and it is always the same question tells me one thing. This is what matters to them. This is how they see their information making it from them to their provider today. This is what they want to eliminate by using HIE or a PHR.

In essence, I see the HIE and PHR as one in the same. The HIE, in a fixed repository model, is a collection of "views" of the patient. We have a primary care view from one doctor. We have a couple specialist views from some other doctors. We have a couple hospitals views from some inpatient and emergency encounters. The PHR is either the same as the HIE consolidated view of these, or in an improved form, it is the consumers view of themselves as a patient. In essence, it is what the patient would put on the registration/intake forms when presented with them.

For a few years now, I have been putting forth what I call the eRegistration use case. eRegistration is the elimination of paperwork and pre-population of the providers system. It populates the Contact Information, Health History, Family History, Social History, Other Providers, Employment, Insurance, Payment, Disclosures, Consents and any other necessary information.

Main Case:

  1. Patient Enters Provider’s Waiting Room
  2. Patient uses smartphone to scan a barcode on the wall with the provider's Direct address
  3. Smartphone collects any relevant data from the patient (who is the request for – if multiple PHRs are registered on the same device, why are you here today, what payment do you want to use – if multiple are recorded)
  4. Smartphone sends request to PHR/HIE cloud to share data
  5. PHR/HIE cloud sends standardized message with XML Registration package containing:
    1. Patient Direct Address
    2. Health, Social, and Family History
    3. Care Team info (including Direct addresses) and desire to share visit information with care team.
    4. Insurance Info
    5. Payment Info
    6. Legal disclosures and consents
  6. Provider PMS/EHR prepopulates the PMS/EHR system with the data.
  7. Patient is seen by provider without having to fill-out the clipboard full of documents
  8. Patient is discharged without having to stop and do any paperwork
  9. Patient receives discharge instructions back via their contact address (PHR or HIE portal account)
  10. Patients care team receives appropriate encounter data
The main issue is that eRegistration cannot be achieved in vacuum by the HIE or PHR system vendor or RHIO. We need to make a few, not many, decisions on what XML documents to put into the registration package. Every provider and their system vendors needs to work together to implement such a change. That said, my real use case contains some alternate paths so that providers can all participate regardless of their technical limitations. This is done by having the HIE fill in for the EHR where the provider may not have an EHR or the EHR may not support this use case yet. This way, we continue to not let the perfect get in the way of the good and adoption of new technology move faster.

The ability to scan a barcode on the wall of my provider's office and my paperwork is done is tangible to patients. It is self-enabling. The physical action delivers feelings of trust and ownership in the act of sharing private information. Since the data is in the HIE cloud and not on the smartphone the information is safe. I believe this to be an enabler of HIE that empowers and binds the consumer to the cost and sustainability of HIE. The consumer will now feel their self-interest in HIE in a tangible way if we create this system of empowerment.

Comments

  1. UnknownJanuary 22, 2013 at 4:52 PM

    Excellent use case. It would be helpful to see if the MU 2 required C-CDA CCD 1.1 document could meet the need.
    Otherwise, we need to ensure the HIE/PHR has the data required for registration, can transform it into a xml (CDA)-based standard, and that the receiver can receive, identify, and import the same into their EHR.

    ReplyDelete
    Replies
    1. Joel RybaJanuary 22, 2013 at 7:09 PM

      Thanks. MU stage 2 is actually the reason I am addressing this now. I believe it requires hospitals to send discharge instructions electronically to patients. But my perception is that patients are happy with paper for that. So I asked myself, who really is going to have a PHR unless for that unless we give them the real benefit they want? I think that is getting rid of the clipboard.

      I agree, we can do this in CDA as it is a flexible schema. We just need the agreement on where to include new elements as flexibility means that it can be accomplished multiple ways. Perhaps C-CDA will specify some additional Schematron rules for some of these included data elements like payment preference, care-team contacts (identified by direct addresses or something unique that can be transformed into a direct address by directory lookup), disclosure & consent endorsements, and sharing preferences.

      Delete
  2. Andy OramJanuary 22, 2013 at 5:26 PM

    I agree with the thrust of the proposal. Does the password to the information stay under patient control, and if so, will providers be willing to give up that control? Do you expect a few large central storage areas, or many storage areas, and who maintains the servers?

    ReplyDelete
    Replies
    1. Joel RybaJanuary 22, 2013 at 6:55 PM

      Any password that they patient would have would be to their PHR. That PHR may be with an HIE like HIXNY or it may be with a PHR like Microsoft Healthvault or RelayHealth. The patient establishes a link between their smartphone app and their PHR. This could be password based, like using Healthvault on your phone today. No health information or any other private information has to be on the phone. The user could just maintain their PHR data from the web using a PC or they could use a smartphone app for that, or they could just let the community record (data collected in the HIE or PHR) be the collective record and not maintain at all. The scanning of the barcode in the waiting room signals the authenticated PHR account to send a DIRECT message to the provider's address that was in the barcode (note that the barcode could be a web address to the providers S/MIME cert versus being the address). The Direct message payload is the health records and can also contain insurance, payment, disclosure, and consent information as desired. The more you send, the less clipboard paperwork you should have to do if the EMR digests the payload. That is where the real work comes in.

      The storage is based on who the patient has their PHR with. It could be the ones above or could even be the patient portal of your primary care doctors EMR, or something else like a locally run app on your phone. I don't like the locally run app on the phone just because phones get lost, are rarely secured, and this is private info. That said it is still possible to have an app for PHR or PHR maintenance.

      Delete
  3. PrwatechMarch 15, 2021 at 7:32 AM

    This was nice and amazing and the given contents were very useful and the precision has given here is good.

    Apache Spark Training Institute in Pune
    Best AWS Training Institute in Pune

    ReplyDelete

Post a Comment

Popular posts from this blog

Game Changing Healthcare Information Exchange

Evolving HIE Beyond just replacing the fax machine   HIE can be more of a game changer for healthcare than just being a replacement for the fax machine. The route to being a game changer is to be an enabler of care management. That care management can come from a health plan (managed care organization), an Accountable Care Organization (ACO) like a Patient Centered Medical Home or Medicaid Health Home, or from the patient/consumer as care manager for themselves or as the caretaker of another.   To do this, I think the HIE needs to serve the following customers and their use cases. These are the healthcare providers for care coordination, the care manager in the role of managing care, the care management at a program management or quality improvement level, and the care management at a financial management level.     HIE must Support Provider-Patient Coordination Use Cases   Send patient data between providers This is the primary purpose of the HIE PUSH functionality
2 comments
Read more

Why Direct makes sense for Data Delivery to an EHR Hub

Who precisely are you sending that message to? There is a little recognized problem in using legacy HL7 over VPNs to deliver data (lab results, image studies, reports, etc). The orderer is in the message regardless of whether you are trying to send to them or not. The CC list is in the message regardless as well. The attending, the primary, etc. all there but maybe not who you are routing to. Who are you routing it to? How is this a problem? In today's modern world of Software as a Service (SaaS), many of the EHRs get data delivery through a common gateway for many practices. If you route a message to a single practice with a locally installed EHR, then when the data source (e.g. hospital or an HIE as its proxy) sends a message to the practice, the practice endpoint and the EHR endpoint are one in the same. There is no confusion about who the message is for. When the EHR serves multiple practices is where we get the confusion. The endpoint of the practice is a spoke off of
1 comment
Read more