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

Aug 10, 2019 to Nov 29, 2019
Status:
 Identification
Type:
 Federal

Updates

About

This group is now comprised of the Person Matching and Proof of Concept demonstration project.  You will find more information about the group, it's purpose, activities and of course the recordings and notes from weekly calls.  Please contact Dave Walsh for more information about the group or to contribute. 

Join Let Get Technical! Group for more.

 

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

  • I am joining this group and am very interested in Person Matching as the State of Washington is starting on a project for sharing data between the HHS Coalition members: Social Services, Health Care Authority, Health Benefits Exchange, Department of Children Youth and Families and Department of Health.  I am a Data Architect for the Department of Health and the point of contact for the HHS Coalition MPI Project.

    The HHS MPI group’s current scope of work is:

    • Identifying the collection of MPI use cases within the health and human service agencies
    • Making a recommendation to enterprise governance regarding MPI priorities
    • Reviewing previous work and document what can be leveraged
    • Identifying existing systems and data that could be leveraged
    • Reviewing financial mapping results(which identify funding sources for potential Health IT related projects)

    Internal to DOH, I am involved in developing shared analytical environments for addressing the opioid epidemic thru linking data from different sources - death, prescriptions, mental health, emergency medical etc.

  • I wanted to add a dimension to this patient matching and identity proofing topic.  It is often neglected in health interoperability protocol discussions, and almost always neglected in human services equivalents.  And that dimension is: the availability of reference implementations for any of the interoperbility protocols we consider.  

    How does this group feel about the necessity of always including reference implementation availability quality as a key metric of any interoperability protocol? 

    At one end of the reference implementation quality spectrum is a simple proof-of-concept code implementation.  At the other end, would be scalable/load tested components, verified to have been implemented in working enterprise systems.  The working, tested reference implementation will uncover problems the simplicity of the proof-of-concept might not anticipate.

    Likewise, if the reference implementations are freely licensed, they are of higher value to the protocol package, since they can be improved and reused by the vendor and general open source community (vendor-supported or otherwise).  

    I wanted to get the group's thoughts on this notion of reference implementations.  I bring this up out of concern for the current dearth and quality of these reference implementations.  I think the first step is cataloging the landscape of implementations available for any protocol, such as patient matching and identity proofing.

    The Open Health Information Exchange Group is currently in the process of mapping reference implementations for their various health exchange components.  Who is doing the same for human services? 

    Though there are overlapping considerations, especially in the realms of identity and matching, human services do require a generality/flexibility which typically gets locked out of health care reference implementation use cases.  If we can work with open source identity and match reference implementations for health care, to keep them flexible enough to be reused in human services applications, we will have furthered the prospects for HIE/CIE interoperability so necessary for Social Determinants of Health to succeed.

  • Carmen Smiley identified this - looks like a good one for representatives of LGT Person Matching to attend:

    On September 6, ONC will host a symposium on Patient Matching for Prescription Drug Monitoring Programs (PDMPs). This one-day symposium will bring together PDMP administrators, standards development groups, health IT developers, representatives from pharmacies, and a number of other stakeholders to discuss patient matching challenges and opportunities to support the interoperability of prescription data.

    In-person attendance is full, but we encourage anyone who is interested to join the web conference as their schedule allows. A high level agenda and the ability to register can be found here:  https://event.capconcorp.com/wp/prescription-drug-management-program/.

    Home
  • As mentioned, we are working on developing a functional repository to house and disseminate documents (expecting it within a few weeks).  In the interim let's continue to post in discussion section - here are some timely Links relevant to Person Matching Project: 

     

    https://sequoiaproject.org/wp-content/uploads/2018/06/The-Sequoia-Project-Framework-for-Patient-Ide…
  • 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.

This reply was deleted.