PROJECTS is where you can share your projects 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

Daniel Stein, president of the Stewards of Change Institute, says his group is convening diverse industry stakeholders to tackle big challenges such as patient matching. - 2019 Connected Health Conference | HIMSS TV

Updates

Related Documents

About Project Unify - Join Us!

The Let’s Get Technical Group is developing a Proof of Concept implementation to demonstrate how information can be shared reliably and securely across domains using already-accepted standards. Specifically, we plan to extend the work already done by the MITA-TAC group through a new use-case scenario that LGT and TAC people will use to educate participants in this project – and then organizations working to further cross-sector information-sharing regarding the standards, processes and other issues that facilitate interoperability. The two to three domains that we will connect will be decided by the LGT and TAC experts creating this PoC over the next three to four months.

We are seeking technical and subject-matter experts, developers/testers, and anyone who wants to follow along, to volunteer to provide input and gain a better understanding of how to provide interoperable, cloud-based solutions relevant to Project Unify (which is what we’re calling it). So we invite anyone/everyone in the TAC and LGT groups to participate. Please contact Dave Walsh for more information about participating in the project. 

Background

The healthcare community is making substantial investments in interoperability and data-sharing, generally by using an approach/standard known as Fast Healthcare Interoperability Resources. FHIR-based solutions are already being applied, and many trial implementations are available. CMS plans to publish a final rule for the healthcare community in the next few months to help vendors understand how best to architect new systems using FHIR. Project Unify aims to leverage and reuse healthcare’s learning to achieve similarly secure interoperability in human services and related domains.  

Initial/Next Steps

Project Unify will have versions associated with the capabilities being deployed. The first version will be V. 0.0.1. Its components will be: 

  • An initial FHIR server and repository from the Michigan Health Information Network (MIHiN). 
  • A cross-domain name-matching capability. The intent is to address issues, concerns and requirements being identified by the LGT person-matching workgroup. 
  • Story development. A group of us will develop a PoC storyline that for demonstration purposes. The MITA TAC already has developed an opioid abuse story that will serve as the starting point for the joint LGT/TAC efforts. 
  • A User eXperience (UX) framework. This user-facing app development framework will take a mobile-first approach to develop apps that use the other services.

About LGT Group

Join Let Get Technical! Group for more. You will find more information about the group, it's purpose, activities, action plans and of course the recordings and notes from weekly calls. Please contact Dave Walsh for more information about participating in the group or other ways to contribute.

 

 

E-mail me when people leave their comments –

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

Join The NIC Collaboration Hub

Comments

  • Here is a slightly revised Template for the Person Matching Project and also notes from our last call.  Please add your comments, questions, recommendations to this post. 

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

This reply was deleted.