We’ve published some help for states implementing the new CMS Interoperability and Patient Access Rule.

Let Videntity help you do this the right way.

https://bit.ly/state-api-playbook

The Alliance for Better Health has awarded Videntity a contract to build the nation’s first consumer-directed health information exchange supporting Medicaid members in New York. Building off our work on the Blue Button 2.0 for the Centers for Medicare and Medicaid Services , we are creating a truly transformational service that intersects identity and healthcare. We are honored and and humbled to be working with the Alliance for Better Health on this impactful endeavor.

For the official announcement, please see https://abhealth.us/press-release/regional-consumer-directed-health-information-exchange/. For even more details see http://www.docnotes.net/2018/07/cdex.html.

What is the difference between “FHIR Bulk Data” and “Flat FHIR”? They are different names for the same thing! http://blog.transparenthealth.org/2018/06/fhir-bulk-api-aka-flat-fhir.html

#HealthIT #FHIR

We’ve made it much easier to get going with Djmongo by using a pre-built Amazon Machine Image (AMI). Here is a link to kick off your very own instance in Amazon Web Services Elastic Cloud Computing (EC2).

ami-27164930

Notes

The size of the instance you’ll need will be based on your data. We recommend an M3- XLarge for medium sized applications. Be sure to open port 80 (HTTP) when setting up security groups After the instance is fully launched, point your browser to the instance’s public DNS. The default console username/password is kitty/purry.

Please congratulate Molly Gehring for trying out Djmongo during All Things Open 2016. Molly is a developer at the Office of Research Informatics at the Duke University School of Medicine. She won the records player and 3 vinyl albums from our booth. Way to go Molly!

Create an API with Djmongo for a chance to win a new turntable and 3 Vinyl Records!

You don’t have to use the Amazon Machine Image (AMI), but it is highly recommended that you do because it will get you up and running quickly. Here is a link to kick off your very own instance in Amazon Web Services Elastic Cloud Computing (EC2).

ami-27164930

The size of the instance you’ll need will be based on your data. We recommend an M3- XLarge for medium sized applications. Be sure to open port 80 (HTTP) when setting up security groups After the instance is fully launched, point your browser to the instance’s public DNS. The default console username/password is kitty/purry.

Rules

• * You must be an attendee at the 2016 All Things Open Conference
• * Submit the URL of the API and what it does to sales@videntity.com by 4PM on October 28 2016.
• * The winner will be determined by the Videntity team

The winner will be announced here on this blog and on Twitter by 5PM on Thursday October 28 2016. We welcome any feedback you have on Djmongo as well.



Good Luck!

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 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 “csv2mongo.py” 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:

https://djmongo.oauth2.io/search/api/public/pecos/compiled/compiled.json?npi=1205824083

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:

https://djmongo.oauth2.io/search/api/public/pecos/compiled/compiled.json?npi=1255498457

Summary

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.

On April 5th and 6th, the Office of the National Coordinator (ONC) and the Federal Health Architecture (FHA) held a workshop at MITRE in McLean VA on the subject of “Provider Directories”. Attendees included representatives from health plans, state organizations, health providers, and the military. A key takeaway from the two days for me is that there are a myriad of use cases for provider directories throughout the US healthcare ecosystem. The meeting included healthy debate around such issues as who should operate the directory, who should pay for the directory, and which technologies should be employed. What most participants did agree on, however, is that reliable and accurate provider directories represent an important tool for improving US healthcare system operations.

My software demonstration was designed to show how provider data can be updated by a 3rd party application using a RESTFul API, protected by oAuth2, in a FHIR format. Below is a list of the various components along with brief descriptions.

Software Components

oAuth2 and Write API Gateway Server: This server controls the Authorization Server, the Protected Resources (our updated APIs), and the API administration. It is a Django application making use of Django oAuth Toolkit. Running Demo|Source code 

oAuth2 Example Client: This sample client lets a client user login and subsequently call a series of RESTFul APIs to update provider data. It is a Django application making use of python-social-auth. Running Demo|Source code

Public Provider Registry and Read APIs: This application serves up data to humans and machines. The user interface provides simple NPPES search capabilities. NPPES and other types of provider data are available via API and there are numerous APIs available from this server. (I’ll be adding a catalog with documentation soon). During my demonstration I presented a “PECOS API” that reports if a provider participates in Medicare and, if so, for which provider organizations. The URL I demonstrated is here: https://registry.npi.io/search/pecos/base.json?NPI=1205824083. I plan to make some updates soon to reorganize the data to simplify things. Running Demo | Source code

Provider Data Tools:  This is a set of command line tools and libraries for manipulating provider data. It can break the NPPES data into smaller CSVs and convert the NPPES data into FHIR resource documents or Provider JSON documents. It can also help import those data into a MongoDB database. See the README in the source code for more documentation. Source code 

Select Data Sources

NPPES Data

PECOS Provider Enrollment Data

Charlie Ornstein’s Tip Sheet on Medicare Datasets

I often get asked the question, “What is the difference between REST and RESTFul?” First off, let’s keep in mind that many words in technology are used inconsistently or change meaning in specific contexts. Sometimes when people say REST often they actually mean RESTFul. Both terms refer to a software architectural style of Application Programming Interface (API) development.

REST stands for “Representational State Transfer” and was coined in 2000 by Roy Fielding while working on his PhD at UC Irvine. The key notion is that the HTTP verbs, “POST”, “GET”, “PUT”, and “DELETE” can be used like the database operations “Create”, “Read”, “Update”, and “Delete”. These database operations are often referred to as CRUD. So in pure REST, there is a one to one match as outlined below.

POST: Create
GET: Read
PUT: Update
DELETE: Delete

RESTFul is a slightly more relaxed version of the same general software architectural style. For example, we might choose not to use PUT or DELETE at all and instead use POST or GET in some manner to achieve the same update and delete functions. Many APIs out there work in this way since it’s often simpler and more practical.

REST/RESTFul approaches are not new, but they are an increasingly popular pattern for exposing machine-to-machine interfaces, i.e. APIs. REST/RESTful approaches are popular in part because they are technology agnostic in the sense that usually they can be implemented in any programming language and on a variety of HTTP (Web) servers. Also, REST/RESTFul servers and clients are easier to implement than SOAP architectures since, unlike the latter, they don’t require WebLogic, WebSphere, or similar heavy (and often expensive) software tools to implement.