About Project Unify

Project Unify is a proof-of-concept implementation designed to advance interoperability between the Health and Human Services domains, each of which currently uses a different standard (FHIR and NEIM, respectively). The project is being conducted by the NIC Let’s Get Technical group, the MITA Technical Architecture Committee, and additional partners who are contributing in a variety of ways to further this potentially transformative work. 

Join Project Unify Group!


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


  • Come join the team for project Unify!

    We need volunteers, SMEs, FHIR experts, Programmers, Designers to help define and implement the Unify effort.  Our current team of volunteers include:

    Rita Torkzadeh

    Podila, Pradeep 

    Noam H Arzt, PhD

    Eric Jahn 

    Brian Book

    Tom Silvious

    Dave Walsh

    If you would like to participate, please send an email to Dave Walsh at with a date and time that you could be available for a group call.   We are hoping for next week to have the call.

    Dave Walsh 


  • All Hands on Deck: We’re Starting on Project Unify Now!

    First, I hope everyone had a wonderful Thanksgiving with family and friends. Now it’s time to get started on our interoperability proof of concept (POC), called Project Unify. We’d like to get a simple first product done before the next holiday arrives – meaning by mid-December – so please email me at you want to participate in this exciting effort. We’ll hold an initial work session during the week of December 16, so stay tuned for a day, time, and call-in information.


    Project Unify aims to demonstrate how the Internet can be used to exchange data between all domains, and especially how to connect people to that information. We don’t yet know how many systems there are to run applications that support the domains relevant to our work, but we suspect it’s thousands.


    There’s a great deal of activity happening today in the healthcare space using the Fast Healthcare Interoperability Resource (FHIR). We want to provide an open-source framework that uses industry standards such as FHIR and NIEM, with the intent of implementing the POC in phases. In the end, we intend to have a reusable, open-source framework that serves as the foundation for the secure exchange of information between a variety of domains. We are excited to engage in this project with many of you in the NIC Let’s Get Technical group, as well as in the MITA TAC.


    Employing User eXperience design, we plan to offer an intuitive and easy-to-use suite of applications that need little or no training to use. Most of our target audience will have a smart phone (Apple or Android), and probably access to a laptop (Windows or Mac). So we intend to provide applications that can be used from any of those mobile devices, a basic desktop/laptop unit, or any modern browser. The order we will be implementing is: 1) Native mobile APP, 2) Desktop APP, and 3) Browser APP. The initial goal will be to show that we can provide a framework that can deliver secured data via mobile, desktop or browser-based apps. 


    We’ll develop a very simple APP to get us started, so trial users can deploy it on their mobile devices. That’s the first “product” we plan/hope to develop by mid-December. So, in addition to subject-matter and technical experts, we need volunteer test users. Please let me know as soon as possible if you can find a bit of time to fill one of these roles – and thank you enormously in advance for doing so.


    Our goal, as we get started, is to use the Hub as our primary communications vehicle. Using the Hub will facilitate the open exchange of ideas that all can learn from. So please sign up there if you haven’t already, and let colleagues who might be interested know about our project, too.

  • Dave,

    FHIR is definitely  a great development.  I've been following FHIR since 2012 when it was just an outsider Aussie coder applying industry standard RESTful principles to outdated HL7 messaging constructs.  And that origin has favorably led to its Creative Commons licensing, which I think HL7 would not normally permit, looking at the other licensing HL7 employs for other artifacts.  Regarding looking at FHIR as a model, I think a better approach is to go back to what was the genesis of FHIR itself: a gap between the common/simple ways of doing things and the established HL7 norms.  So for human services in general, I just think we need to think like FHIR's founder, but not necessarily copy FHIR (and to be fair, nobody was advocating copying), since that will not get us to human services FHIR equivalents.  

    Eric Jahn, CTO
    Alexandria Consulting LLC
    St. Petersburg, Florida


  • Eric,

    Thanks for the perspective!
    I would appreciate your continued engagement.
    We are working on two initiatives both of which are Open Source.
    The first project is called Unify:
    Unify is an effort to define a set of APIs into repositories with appropriate security (Authentication and Authorization) mechanisms.  My assumption is that for healthcare domains this will be FHIR APIs.  I have not seen this much momentum in healthcare for interoperability since HIPAA transactions and code sets.  In my opinion FHIR is going to happen for healthcare, it will be refined by initiatives like the FHIR At Scale Taskforce (FAST).  I don’t see FHIR as the end of the road but there is a lot that other domains can learn from FHIR.  We should be able to apply these lessons learned to other domains.
    The second project is called Unite:
    Unite is an open source client/user framework targeted at writing APPS that use the APIs into domains to built meaningful applications.  These APPs are consistant with your description "I think this is essentially a "data centric" view with an app marketplace”.  It is early days for Unite but I am optimistic about it’s future.  The goal is that the Unite framework will have many reusable capabilities that allow the developer to concentrate on the business value and provide the developer with reusable functionality for technical details.
    The following is a list of some of the functionality in Unite.
    produce APPS that will run on IOS, Android, Desktop (Mac Windows or Linux), in a modern browser (JavaScript). 
    Convert JSON from domain specific APIs into business models. (All FHIR resources included).
    Access to other functionality such as Maps, Videos…. via Widgets.
    Server side functionality.
    Authentication / Authorization.
    Test tool for Unify (domain endpoints)
    As I said earlier, it is early days for Unite but it already has traction in a number of arenas such as, Create Read Update and Delete (CRUD) operations on FHIR resources. Building data models from JSON. Produces APPS that run on iPhone or Android etc.
    I don’t see Unite as the only framework to develop APPS for our domains but I do believe it will address many of the pain points.
    Above all I believe it will be a. Great educational tool for all domains.
  • Re:


    Thank you for the link, Dan.  Aneesh makes great points.  I think this is essentially a "data centric" view with an app marketplace, that Aneesh is advocating.  And, it's a great idea for all of human services.  Which leads to the inevitable business question he addresses: how does one maintain data independent of the apps, from a provider perspective?  By microcharges for data access, of course.  His "Code of conduct" sort of maps to the "trusted apps" concept, which I'm not sure who first coined, but Facebook definitely helped popularize it in the software development world.  I love the consumer-facing Roku Box FHIR server, idea.  I was not expecting that.  I will never look at my humble Roku box, sitting alongside the TV, the same.  On a different subject, I must confess that I'm a little worried about FHIR usage spilling into areas outside health, as opposed to just being a bridge between health and other human services.  In its current state, FHIR would add a lot of clinical jargon and unnecessary complexity to human services at large, which has its own jargon and considerations to tackle.  As far as a template for human services APIs in general, I find it a little overly complicated.  I think a comparison of existing human services APIs to FHIR documentation will make that apparent, consumer facing APIs or otherwise.  But Aneesh's message translates perfectly to human services at-large: now is the time to develop data centric human services applications, as well.


    Eric Jahn, CTO
    Alexandria Consulting LLC
    St. Petersburg, Florida

    ‎This Week in Health IT: Aneesh Chopra Declares Now is the Best Time to Develop Consumer Applicatio…
    ‎Show This Week in Health IT, Ep Aneesh Chopra Declares Now is the Best Time to Develop Consumer Applications for Health - Feb 14, 2019
  • 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:

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

This reply was deleted.