PEOJECTS is where you can share your peojects related to interoperability and information-sharing across NIC's six domains that contribute to everyone’s health and wellness. Here you can access other members' projects, express your interest to join, invite your friends, comment, like, follow, share, and more.

Projects

Aug 10, 2019 to Aug 30, 2019

You need to be a member of The NIC Collaboration Hub to add comments!

Join The NIC Collaboration Hub

Comments

  • Hi Larry,

    Thanks for your feedback about threaded comments. I just turned it ON. Let me know how this is working for you.

    Have a great weekend

    Sondes Ben Chagra
    SOCI/NIC Online Community Manager and the Hub Manager/Admin

     

    Sondes Ben Chagra
    The NIC Collaboration Hub is a secure and interactive platform. This is where you can inspire, be inspired, and make a difference!
  • This is why we talk about trust domains and trust frameworks, and why TEFCA may be an important element here in creating a national trust fabric. 

  • As an HIE for the State of Arkansas we belong to SHEIC and eHealthExchange.  Right now, we use zip code mapping in the PCDH model to obtain Arkansan's medical record when they visit other state's medical facilities.  We are however, in the processes of direct connect with other HIEs in neighboring states.  We must do this because our Regional Hub in Oklahoma MyHealth cannot perform this function for us at this time.

    I have often wondered when we receive a query for a patient from a facility or another HIE how do we know that the person requesting the information is authorized.  We know the facility or the HIE is authorized because of certificates that we have exchanged. Then, from our point of view we accept that the person requesting the information is authorized because that facilities security has authorized them.

    However, with more and more interoperability we are not going to have exchanged certificates with every entity. eHealthExchange is now taking a Hub approach where they will be doing some of the verification of the entities and directing the traffic/request on where to go.

    Dr. Ozeran’s point number 2 could be completed by using these authorization servers, much like we use DNS servers on the internet. We would have an authentication entity that would validate an entity to have an authorization server. Each authorization server would update the others, just like the DNS does through replication. Then whenever a request comes in the request would be validated by an authorization server.

  •  

    Person Matching

    Patient Identifier Cross-Referencing - IHE Wiki
  • Again, I agree with Noam. All of these things are true, including the limited ability of all of these efforts to create the actual trust that is desired. Perhaps the TEFCA will be the final linchpin that makes it all work, for healthcare. Even if it does, that will not get us very far in this effort. As I said at the outset, crossing domains adds a layer of nuance that makes this even more complicated.


    I suggest that we begin by hearing whether others agree with these steps or not. Are there other steps in the authentication and authorization process? Should we describe these steps differently? We can iterate the steps to consensus. Once we have a consensus about what we need to accomplish, I suggest we start separate conversations, one for each step. For some of the steps, we can begin by looking at efforts in all of the domains that have actually solved the problem and look at the techniques each domain used. Then we can work through what might work for this effort. Throughout, we need to ensure that we hear from at least one person and preferably several people from each domain to make sure we are not making erroneous assumptions about what might work in the domain.

  • Well, Larry, that's why several efforts have focused on creating a trust domain (initially just for healthcare) so that the authentication step can be pre-negotiated by each entity participating in a pre-established procedure. Of course, this has not quite come to be. For Direct, DirectTrust has tried to be that trust domain; for other activities (Commonwell, Carequality, SHIEC) other organizations have stepped up. ONC hopes that TEFCA will enable some of these functions via participation through its RCE.

    DirectTrust.org
  • Agree with Noam that these are different aspects of identity (proofing and matching), but we thought it would be easier to start with them in one place and they can diverge into separate efforts.
    There is a lot of literature and techniques for both, but I think the authentication issue here may offer a few new nuanced challenges because of the cross-domain foundation. Here is my first pass on a high level view of how I think authentication might look for entity A seeking information about person Z. For information where person Z is known to have data the process (below) would be different from when entity A wants to find places where person Z has data.
    1. Entity A sends a request for data about person Z to a named data source.
    2. The data source responds asking for proof as to entity A's identity and a reference describing why entity A is authorized to access this data. Only at step 2 and there are already a few things we need to figure out. We need a process that all entities in all domains will accept when verifying the identity of each requesting entity. This alone may be a long conversation and require new infrastructure. We also need a standard vocabulary for describing why an entity is authorized to request the data. Lastly we need rules about what constitutes an entity in any one domain to be authorized to get data from each other domain. This might be a matrix of the prescribed vocabulary, but it will require conversation that leads to political consensus.
    3. Entity A provides authorization according to the standard methods and terms.
    4. The data provider validates the authorization and authentication. How does this happen? Is there a shared authentication server that keeps credentials for all entities in all domains? Does the authentication server also contain the types of data to which a given entity is permitted access? Is this a negotiated list on a domain by domain basis or a specific entity to entity (one-to-one) match?
    5. If either the authorization or authentication fail, what happens next? How many authentication attempts are permitted? What auditing is performed for failed authentication requests? If the authentication is successful, but the entity is not authorized to receive the information requested, is there simply a message indicating that no data can be provided? Is there a log of these events that is reviewed on a regular basis? Does an audit occur over a certain threshold?
    6. When the authentication and authorization succeed, the data is transmitted. Does the authentication server keep track of the data format that the requesting entity prefers? Is there a transformation server that inserts in this process and makes a translation before the data is sent?

  • As I said in response to Daniel's initial post in the main group thread, there is a difference between identity matching and patient matching. The former usually refers to proving you are who you say you are (as a patient, clincician, whatever) related to access to a system. Patient matching usually refers to the process of aggregating patient records from disparate sources and making sure they are properly linked together.

    I have done a lot of writing on patient matching. Here are some sources:

    https://www.hln.com/gao-report-on-patient-matching-nothing-new-unde...

    https://www.hln.com/update-on-patient-matching-activities/

    https://www.hln.com/patient-matching-and-hie-do-we-even-have-a-stra...

    https://journals.ke-i.org/index.php/mra/article/view/1150

    GAO Report on Patient Matching: Nothing New Under the Sun – HLN Consulting, LLC
    • Good stuff on matching, Noam.  I see a lot of the work cited (especially the GAO report) discusses the topic of "how to best match persons algorithmically".  Of course, this will be a rapidly evolving practice in the years to come.  I guess I'm less concerned at the moment with how we match, versus the match interfaces between systems, trusting that the matching is done effectively by the master index.  At this point, I'm more concerned with "how complete are the PIX standard interfaces for transmitting match information", and "are the resulting responses complete enough for practical human services information exchanges"?  This is a topic I haven't had the bandwidth to focus on, but I'm glad this group looks poised to go there. 

      GAO Report on Patient Matching: Nothing New Under the Sun – HLN Consulting, LLC
    • Thanks for clearly differenitating.  A good first step on this journey. 

      Daniel 

      GAO Report on Patient Matching: Nothing New Under the Sun – HLN Consulting, LLC
This reply was deleted.