Verify My Identity is Now Open ID Connect Certified

As of December 3rd 2018, the open source software, Verify My Identity is certified compliant by the Open ID Foundation! Thanks to the Videntity Team and the Alliance for Better Health.


Videntity Joins the Open ID Foundation

As of November 1st 2019 Videntity has joined the Open ID Foundation.


Getting Quality-based Payment Models Right Means Replacing X12

Check out our guest blog post on quality-based payment models and the X12 standard:

Getting Quality-based Payment Models Right Means Replacing X12 on the Zansor’s blog.


The Medicare Provider Directory API

The Centers for Medicare and Medicaid (CMS) recently released Medicare provider enrollment data contained in the “Provider Enrollment, Chain, and Ownership System” or “PECOS”. CMS will release updates of these new public data about every quarter. The Medicare Enrollment data are useful because not only because they show if a provider participates in Medicare, but also organizational affiliations. For example, doctor A serves Medicare patients at hospital X and clinic Y. At clinic Y, doctors that take Medicare are doctors A, B, C, etc. This kind of information is useful to state Medicaid agencies, health plans, and the general public. This article explains how I created an API out of this public data.

Background on the Data Format

You can read all about the data here but the short version is that is the data are divided into three flat files: a base file containing basic demographic information, an (incomplete) address file, , and a reassignment file. In Medicare/PECOS terms, a reassignment is when a health provider reassigns the benefit to another party. Often practitioners are not paid by Medicare directly, but instead opt to “reassign” the benefit to an organization, such as a hospital, which is often where the provider receives his or her salary. This reassignment is indicative of an affiliation or work relationship.

Processing the Data

To make the PECOS data more accessible, the three flat files must be transformed. I first converted the three flat files into three MongoDB collections using the command-line utility “” found in json-data-tools. After I indexed certain fields for speed, I wrote a custom script to sort through the data and yield two new MongoDB collections called “combined_organizations” and “combined_individuals”. Then using the RESTful API framework Djmongo as the RESTful Application server responsible for exposing the new data, voilà, I have a functioning RESTful API for Medicare providers. All the input required is the NPI number for the organization or individual in the URL.

Using the API

As an example, we can determine that “Leslie Crytser”, with the NPI of 1205824083, is enrolled with Medicare with two organizations, “Stony Point Surgery Center, LLC”, and “West End Anesthesia Group”. Here is an example using Leslie’s NPI:

And on the flip side, we can see which providers are setup to bill Medicare through a particular institution such as, “Stony Point Surgery Center, LLC”, with the NPI of 1255498457, using the following RESTful URL:


While functional, this PECOS API is still a work in progress. I plan to add address data and convert the documents into proper FHIR resources. Currently, the address data only contain city, state, and zip code. I hope CMS decides to release the address line information in the future. After some further updates, I plan to make available the script that creates these files possibly within the Provider Data Tools package or elsewhere.

A final item to note is that just because a provider/institution is included in the PECOS data, doesn’t necessarily mean that any services were provided via Medicare. PECOS enrollments/re-enrollments work on a 5-year schedule; therefore the provider/institution may not currently be accepting Medicare patients.

I hope the health information ecosystem finds this somewhat useful. Feedback welcome.


The Direct Certificate Discovery RESTFul API

As part of my HHS Fellowship, I was asked by more than one stakeholder to perform some level of validation on the Direct email address. I’ve written before on how I think Direct certificates should be discoverable in HTTP as well. I didn’t get much traction on that proposal. To this end, I’ve built the next best thing; a RESTFul API that both fetches and reads x509 Certificate information via LDAP and DNS and returns this information over HTTP. In the NPPES Write API Alpha, this mechanism is used as the “gatekeeper” for Direct address inclusion in health provider records. It prevents addresses that are not backed by a discoverable certificate from being accepted. For example, “” would not be accepted, but “” would be accepted. You can check out a live demo at If you would like to install it on your own site, start by typing the following into a terminal window.

pip install django-direct

The source code can be found here on GitHub. Note there are a number of dependencies to the underlying getdc library. Please check out the getdc documentation too.


Return from Sabbatical

Alan Viars, founder and president of Videntity, has completed his appointment as an HHS External Entrepreneur at the Centers for Medicare and Medicaid Services (CMS) and has returned to Videntity full time.


President’s Sabbatical

Alan Viars, founder and president of Videntity, is on sabbatical from Videntity until Spring 2015 during his appointment as an HHS External Entrepreneur at the Centers for Medicare and Medicaid Services (CMS). He is working on an open-source redesign and modernization of the National Plan and Provider Enumeration System (NPPES). NPPES is best known as the system that issues National Provider Identifiers (NPIs). More information about this effort cat be found at


Certificate Authority Management System for Direct

The management software that runs the certificate authority (CA) at, or more precisely, is now open source. “vcert” is a web-based application written in Django which relies on OpenSSL for certificate creation and management. is still free to use, but if you need operate your own CA or a registration authority (RA), then this system provides a simple web-based interface for doing so. This software was originally designed to facilitate testing of the Direct Project.

The source code can be found here on GitHub. See the README for more information on installation and operation.


Converting Stata files to CSV using R

A simple recipe for converting Stata data into CSV. CSV stands for comma separated valuew. Common uses for this recipe is when you want to move information from Stata into a spreadsheet or another database. In this example, we assume in Stata input file name is called “MyStata.dta” and the resulting CSV file name is “MyStata.csv”.
Here is the process.

Install R (if its not already installed)

$ sudo apt-get install r-base-core

Now run R from the folder where your Stata (.dta) files lives.

  $ R

You should see something like this:

R version 2.14.1 (2011-12-22)
Copyright (C) 2011 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.


Import the foreign library

> library(foreign)

Import the Stata data

> MyData <- read.dta("MyStata.dta")

Now write the information out to a CSV file using write.csv()

write.csv(MyData, file = "MyStata.csv")

Quit R

> q()

Now you have your CSV file.


Provider Directory Proposal (NPPES Redux)

A couple of weeks ago, I attended ONC’s Direct Bootcamp in Crystal City, VA. A hot topic at the two-day conference was the notion of a “Provider Directory” that incorporates Direct email addresses.

I also read that HHS/CMS intends to revamp the National Plan and Provider Enumeration System (NPPES). This is the system that manages National Provider Identifiers or (NPIs). Every individual provider and provider organization has one of these numbers, sort of like a tax ID for providers. A common complaint I hear is that it contains information that is often out of date and/or incorrect.

So what, you might ask, does the NPPES have to do with the Direct Project? Having worked with the NPPES data and having some background with Direct, the idea of “killing two birds with one stone” has captured my imagination. (Nerdy and wonky I know.) This is an opportunity for government efficiency by consolidating systems. Efficiency can only be achieved if the new system is simple, however. Too often in health information technology, consultants and vendors introduce complexity for complexity’s sake. After all, complexity is good for the bottom line for many companies because it means more billable hours and more services sold. Sadly, I see this sort of thing all the time. As an American and a taxpayer it ticks me off.(See footnote)

To illustrate what I mean by “simple”, I’ve built a prototype web service application that illustrates my vision of a combined NPPES and Direct email Provider Directory. Before I outline that technical proposal, however, I’d like to point out how adding some other data fields to NPPES could result in a an empowering service for patients, providers, and payers.

Adding Other Data Points to NPPES

While a full NPPES would involve adding more fields and require pagination, which I have not included here, items that I think contain more fields and would require pagination that is not illustrated here, items that I think would be most useful to add include:

1. Diagnosis and Procedure Codes such as ICD9, ICD10, and CPT codes that are typically provided by the provider.

2.Payer and health plan identifiers to make it easy easy to search and determine if a provider takes a particular insurance plan, for example.

3.State Medical Board License information to determine in which state(2) the provider is licensed.(An even better idea is for our nation to adopt a national medical board and do away with state medial boards altogether.)

An NPPES Web Service Proposal

This is my proposal for a simple NPPES web service in a RESTFul style. I have provided examples and defined some basic HTTP request and response expectations.

Here is an example of a simple search query looking for all doctors named “Fred Smith” that have a practice within the zip code 20004. We simply use the any web client to query the database. In this example we return the data in JSON, but we could also just as easily return it in XML, CSV, or HTML.

 GET http://localhost/nppes/example.json?first_name=Fred&last_name=Smith&zip=21223

If any results are found, we get back an HTTP 200 response and a JSON file containing a non-empty list of results.


    "message": "OK",
    "num_results": 1,
    "results": [
            "first_name": "Fred",
            "last_name": "Smith",
            "npi": "23456789",
            "address_1": "901 Pennsylvania Ave",
            "address_2": "",
            "city": "Washington",
            "state": "DC",
            "zip": "20004",
            "telephone": "202-555-5555",
            "fax": "202-777-7777",
            "provider_type": "",
            "regular_email": "",
            "direct_emails": [
                    "organization": "Hope Hospital",
                    "npi": "3453456985",
                    "email": ""
                    "organization": "Fred Smih MD",
                    "npi": "23456789",
                    "email": ""


Note that within the results is a field called “direct_emails”. We assume each provider could have many Direct addresses, for example, if he or she works at multiple organizations. This field maps all other NPIs and Direct addresses together.

We can also query by a Direct address…..

GET http://localhost/nppes/example.json?

…and we can also query by an NPI…..

GET http://localhost/nppes/example.json?npi=23456789

The above two example returns the same result as before. So we can query by name, address, provider type, etc. and we can also query just by a Direct email address or an NPI.

For cohesiveness, I’d like to outline what things look like when no results are returned (i.e. an unhappy path). If no results are found or some sort of error occurs, then the NPPES web service responds with something other than an HTTP 200 status. Here are two unhappy examples; A valid query returning no results, and an invalid query.

No Results


GET http://localhost/nppes/search/?first_name=Fred&last_name=Appleseed


    "message": "No search result matched your query.",
    "results": [ ]

The HTTP response code is 404.

Invalid Query


GET http://localhost/nppes/search/?foo=bar



    "message": "You supplied an invalid search parameter: foo",
    "results": [ ]


The HTTP response code is 400.

Next Steps

This blog post is an open letter to HHS/CMS on how to construct a new NPPES without the complexity that often accompanies health IT. Comments and feedback are welcome.

Resources and Background NPPES

Currently the NPPES data is made available as a comma separated value (CSV) file. The field headers/names are in a separate CSV file. This URL is not on a .gov domain and is somewhat hard to find. I’ve published a link to it here. Thanks Fred Trotter. The sign up and update is not an electronic process. Here is a link to the PDF sign-up/update form. Almost certainly any NPPES modernization effort would involve making this an online process.

Footnote: John Stewart made this point well in his segment “The Red Tape Diaries – Veterans Benefits” (VIDEO). At Videntity, we subscribe to the mantra that building things as simply and as efficiently as possible is always the best design choice, even if it means a smaller contract.