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 May 1, 2020

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

  • Take a look at the Use Patient Story (See in the Proof of Concept link above) 

  • 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
This reply was deleted.