Skip to main content

A Healthcare User Identity that is better, faster, and cheaper through reuse

Why is FHIR query-based exchange so slow to be adopted? 

When it comes to FHIR Query/Pull, only Provider-to-Consumer exchange reasonably works using FHIR as the user identity of the patient comes from the provider’s own patient portal system. I propose that the issue with adoption for provider, insurer, or public health query-based exchanges is that we need one system for nationwide healthcare user identity. This has been known for over a decade, and the can was kicked down the street multiple times. 

FHIR was founded as the outcome of the Data Access Framework (DAF) project initiated by the Office of the National Coordinator (ONC). Its only evaluated use case was public health. The goal was a peer-to-peer pull (query) of data. The result was FHIR. But the DAF project intentionally left out a user identity solution. As a result, we don’t have peer-to-peer exchange because we don’t have user identity. Peer-to-peer exchange is a great concept to lower overhead costs. But it needs a trusted identity provider for the servers to decide who can access and who cannot.

For push (sending) of patient data to replace the fax machine, we invented Direct Secure Messaging (DSM). Direct is essentially an email exchange with the content placed in a Secure MIME (S/MIME) attachment with the encryption keys and certificates dynamically discovered by the Health Information System Providers (HISPs) so that no pre-exchange by the sender and recipient is necessary. Direct is broadly adopted by providers, insurers, and public health. So of course, in an asynchronous exchange, one could use DSM.

Direct Secure Messaging however has user identity issues as well, which may be why using it as an identity provider was not pursued. There is limited information about the sender that makes it to the edge system of the recipient. The receiving HISP, which processes the certificate lookup, has little more; just what is in the certificate. This doesn’t really create a problem in a mostly human-initiated asynchronous email exchange where the users will know whether this is someone they want to communicate with or not.

But what occurred to me is that identity management can be improved with minor changes to the HISP servers and improved in a way that would allow it to be used for both push (messaging) and pull (query based) exchanges. This easy enhancement would enable greater adoption for exchanges like the peer-to-peer FHIR query as originally envisioned in the DAF project.

The Direct Project is an architecturally elegant implementation of a trust framework as it really doesn’t tie encryption and signing to the transport of SMTP. These are separated by the Direct gateway. So, we can use them separately to sign and validate a Java Web Token (JWT) or Security Assertion Markup Language (SAML) statement that would include claims about the identity of the user/sender from their HISP that can be validated by the service/recipient via their HISP.

I propose that Direct HISP standards could easily be elevated to add new client-facing services to obtain a JWT (signed claims) and to validate such a JWT. The client-side HISP just uses its own public key repository for the JWT issuing/signing service. The client then uses that JWT to access a FHIR server. The authentication service of the Service provider validates with the JWT with its HISP and that service-side HISP uses Domain Name Service (DNS) lookup with the client-side HISP to get the public key and validates the signature. With the user authenticated, the FHIR server responds.

The HISP knows exactly what and who their client is, this is why it is the client-side HISP puts such claims in the JWT and signs it for the client. This information is more than just the direct address and the user or organization name in a certificate. It extends to information such as NPI for providers, specialty, type of organization, EDI identifiers for insurers, etc. Thus, it opens the ability for FHIR Server to authorize on that additional information.

Not only is this an easy add-on to the HISP, but it’s also easy for any FHIR server. Any organization publishing a FHIR endpoint today can just authenticate an additional JWT type using their Direct HISP. They just need to decide what patients and resources they let each authenticated user access based on the claims as their role-based access controls.

This solution isn’t limited to just FHIR calls. If more sender information was desired for asynchronous exchange, a JWT could be added to the payload of a Direct message to share such claims with the recipient. Or a signed SAML version of the claims in XML could be included in the XDM package exchanged between HISPs and included in an XDR post to the recipient endpoint. SAML, XDR and XDM are all XML (extensible markup language) standards used in DSM today. This could enable more automated responses in asynchronous exchange via DSM as well by evaluating the claims about who and what the user is rather than just the direct address.

This is simple matter of reuse being better as this solution is nationwide, faster as it already exists, and cheaper as it is a limited technical add-on versus building something from scratch.

Comments

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 provi...
3 comments
Read more

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 ...
7 comments
Read more

The Well Architected HIE and Direct Push

In "The Dangers of Too Much Ambition in Health Information Exchange" published in ihealthbeat, Micky Tripathi recently wrote about "over-architecting" HIEs. Mickey is correct that HIEs should not try to boil the ocean. However, the final point of Mickey’s article seems to be “Start with PUSH” because it is high value to physicians and low risk. It is true that PUSH is high value to physicians and that it is the primary thing they are willing to pay for. But, this alone will not make an HIE sustainable because physicians and hospitals won’t pay enough for it. On the other hand, Governments and Health Plans have been willing to make longer term investments into the data warehouse that supports PULL of a patient centric record. So to some degree, HIEs have to follow the money. This isn’t such a bad thing as for example the money for New York HEAL grants was to establish a strong foundational architecture for HIE. If regions followed the State architectu...
4 comments
Read more