Thursday, January 17, 2013

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.


  1. 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.

    1. 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.

  2. 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?

    1. 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.

  3. a pride for me to be able to discuss on a quality website because I just learned to make an article on
    cara menggugurkan kandungan

  4. This comment has been removed by the author.

  5. Wow it is really wonderful and awesome thus it is very much useful for me to understand many concepts and helped me a lot. it is really explainable very well and i got more information from your blog.

    rpa training in chennai | rpa training in chennai
    rpa training in pune | rpa online training | rpa training in bangalore

  6. Really you have done great job,There are may person searching about that now they will find enough resources by your post
    python training in velachery | python training institute in chennai

  7. I would really like to read some personal experiences like the way, you've explained through the above article. I'm glad for your achievements and would probably like to see much more in the near future. Thanks for share.
    java training in chennai | java training in bangalore

    java training in tambaram | java training in velachery

  8. Really very nice blog information for this one and more technical skills are improve,i like that kind of post.
    Devops Training courses
    Devops Training in Bangalore
    Best Devops Training in pune
    Devops interview questions and answers

  9. Wow it is really wonderful and awesome thus it is very much useful for me to understand many concepts and helped me a lot. it is really explainable very well and i got more information from your blog.

    rpa training in velachery| rpa training in tambaram |rpa training in sholinganallur | rpa training in annanagar| rpa training in kalyannagar

  10. Really you have done great job,There are may person searching about that now they will find enough resources by your post

    Java Training in Chennai
    Automation Anywhere Training in Chennai

  11. I’m planning to start my blog soon, but I’m a little lost on everything. Would you suggest starting with a free platform like Word Press or go for a paid option? There are so many choices out there that I’m completely confused. Any suggestions? Thanks a lot.

    AWS Training in NewYork City | Amazon Web Services Training in Newyork City
    AWS Training in London | Amazon Web Services Training in London, UK
    Amazon Web Services Online Training in USA | AWS Online Course in USA

  12. Only here you will find the best casino gaming Come in and win now.

  13. На любой вкус светодиодные ленты можно найти в Ekodio, бюджетные и премиум, всех цветов и характеристик