I’ve done a lot of work on designing provider network directory schemas. Much of it is described in this blog (“provider directories” tag) and in the related “Interoperability” entry on the DDOD website. But so far, the effort has been focused on designing a standard data schema that could adequately represent the way the healthcare industry currently operates in terms of provider networks and health insurance coverage. Now I’d like to highlight an important factor that’s been overlooked: the mechanics of moving this data between systems.
In their recent machine readability requirement for insurance issuers on health insurance marketplaces, CMS/CCIIO did not specify the transport mechanism for the QHP schema. The only requirement is to register the URL containing the data with HIOS (Health Insurance Oversight System). The URLs could be to a static page or to a dynamic RESTful query. I’d like to point out that CMS or third party services have an opportunity to provide significant value to both consumer applications and transaction oriented systems by adding a RESTful FHIR layer. Ideally, this would be done in front of globally aggregated datasets that have been registered in HIOS. The resulting FHIR API would have resource types of Provider, Network and Plan, which correspond to the JSON files of the QHP provider directory schema. The most relevant resource type
Much of the usefulness for machine readable provider network requirement is around enabling consumers to ask certain common questions when they need to select an insurance plan. (For example: Which insurance plans is my doctor in? Is she taking new patients at a desired facility under a particular plan? What plans have the specialists I need in a specific geographic region?) These questions could easily translate to FHIR queries using the Search interaction on any of the defined resource types. With required monthly updates and potentially frequent changes in network and provider demographics, there are also use cases that benefit from availability of the History interaction, either as a type-level change log or an instance-level version view. Additionally, by adding search parameters, response record count limits, and pagination in front of network directory datasets, load from traffic on aggregated data servers could be much more efficient.
I set up a server with an example of a FHIR API implemented for provider directories, although limited to NPPES data model. A big thanks to Dave McCallie for creating and sharing the original codebase: GitHub.com/ DavidXPortnoy/ nppes_fhir_demo. You can find the live non-production sandbox version here: http://fhir-dev.ddod.us:8080/nppes_fhir. Here are a few sample queries you can run against it:
- Practitioner with specific NPI: http://fhir-dev.ddod.us:8080/nppes/Practitioner/1023001708
- Ophthalmology or Optometrist in Chicago (Also shows how pagination works.): 1st page http://fhir-dev.ddod.us:8080/nppes/Practitioner?address=Chicago&specialty%3Atext=ophthalmology+optometrist&page=1&_count=15, then 2nd page http://fhir-dev.ddod.us:8080/nppes/Practitioner?address=Chicago&specialty%3Atext=ophthalmology+optometrist&page=2&_count=15
- Last name starts with “Gold” on Main Street: http://fhir-dev.ddod.us:8080/nppes/Practitioner?family=Gold*&address=Main
I’m working on expanding the functionality of this server to accommodate the full provider network directory schema, including components of provider demographics, facilities, organizations, credentialing, insurance plans, plan coverage, and formularies.
Edit 10/2015: It should be said that my HHS Entrepreneur-in-Residence colleague, Alan Viars, has led an effort to build a robust API for NPPES for HHS IDEA Lab’s NPPES Modernization Project. It’s designed to handle both efficient read access wanted by many applications and robust methods for making changes. Although initially it focused on providing the simplest purpose built API possible, Alan is now looking at creating a version that would be based on FHIR practices.
Additional FHIR server implementations
The current FHIR server is quite simple. It’s implemented using Python, Elasticsearch as document store for NPPES records, Flask as Python web server, and Gunicorn as WSGI web gateway. Let’s call it the Flask-ElasticSearch implementation. There are a couple other more popular alternatives.
It seems that the most active FHIR open source codebase is HAPI, located at https://github.com/jamesagnew/
Finally, FHIRbase, located at https://github.com/fhirbase/
There are also a surprisingly large number of Windows-based FHIR servers that I haven’t considered, due to a desire to stay on non-proprietary platforms. Although perhaps it shouldn’t be that surprising given the Windows heavy history of EHR and other healthcare apps.