This year the HAPI FHIR team prioritized developing an Enterprise Master Person Index (EMPI), within HAPI-FHIR. Our hope is that HAPI FHIR EMPI will become a community initiative with wide participation and deployment and is the go-to solution for FHIR-based EMPI implementations.
Development began in early 2019 and in the last few months we have been engaged in building the initial release. Here is what we’ve built so far:
Organizations we work with who manage FHIR repositories are excited about running EMPI on top of FHIR for a couple of reasons:
Speaking with users, we have found that organizations tend to use EMPI in one of two ways:
These two scenarios have different needs. The real-time system requires fast response time for small one-off queries. The batch analytics scenario needs to efficiently run large batches that can take hours or days to complete.
A lesson we learned early-on is that EMPI can get complex really fast. A simple-sounding requirement like supporting real-time updates for enterprise identifiers quickly fractures into a surprising number of special cases. We’re likely still missing some cases. We have aimed, whenever possible, to establish simplifying design principles to keep this complexity down. However, supporting the wide variety of EMPI use cases requires a fair amount of configurability which inevitably adds complexity.
Our initial implementation of a “Golden Record” as a Person resource that aggregates data from linked Patient or Practitioner resources is insufficient. The FHIR Patient resource is much richer than the Person resource, but the Person resource is where the links reside. We have just started adding the concept of a Golden Record which will be a designated Patient linked to a person with rules governing how this data can be updated; e.g. different data sources will have different levels of authority / priority for changing fields in the Golden Record.
Using FHIR paths and search parameters to compare and link resources naturally extends beyond matching people. We are seeing interest in matching Organizations, Medications, Allergies, and many other FHIR resources. While there isn’t a built-in linking resource for these other domains, like there is for people, most of what we built for matching people can be repurposed to match other resources as well. We have designed the HAPI EMPI configuration and database entities in such a way that they can be extended beyond Patient and Practitioner in the future.
The algorithms required to support Probabilistic Matching are well-understood, the most common being the Fellegi Sunter Jaro algorithm. Users we’ve spoken with have told us that while probabilistic matching looks good on paper, in practice its management is too complex to be useful. Adding this capability would add considerable complexity and performance tuning load to HAPI FHIR EMPI. As a result, we will await community feedback to help gauge the demand and need for this feature.
If you have any thoughts on this initiative, please join us on the hapi-fhir discussion forums: https://groups.google.com/g/hapi-fhir
https://smilecdr.com/hapi-fhir/docs/server_jpa_empi/empi.html
https://smilecdr.com/docs/empi/empi.html
https://smilecdr.com/docs/fhir_repository/search_parameter_phonetic.html