Tag Archives: healthcare

Leveraging healthcare data for consumer solutions

On April 23, 2016, over 300 developers from around the country descended on San Francisco for the weekend to tackle some of the hardest challenges facing the nation.  The event was called BayesHack, sponsored by the nonprofit Bayes Impact.  There were representatives from 7 cabinet-level federal agencies present to set up the 11 “prompts”, mentor the teams and judge the entries.  The prompts for the U.S. Department of Health and Human Services and the Department of Veterans Affairs asked challenging questions on how to leverage existing datasets…

  • How can data connect individuals with the health providers they need?
  • How can data get help to sufferers of opioid addiction?
  • How can data predict and prevent veteran suicide?
  • How can data tackle End Stage Renal Disease (ESRD) and Chronic Kidney Disease (CKD)?

 

As part of the judging process, the teams had to pitch their solutions to both agencies and private sector judges, such as partners at Andreessen Horowitz.  All teams submitted their code to the event’s github account, so that it could be used for judging, as well as ensuring that it will be available in the public domain.    For hackathons such as this one, it’s important to recognize that even if there are already similar commercial products, getting solutions into the public domain makes it possible for others build on later.  (Incidentally, this focus on actual working prototypes via GitHub is surprisingly lacking from many hackathons.  Bayes did a great job focusing on potential implementation beyond just the weekend.)

Of particular focus was the “How can data connect individuals with the health providers they need?” prompt, since this data has only recently become available, due to a regulatory requirement.  This data consisted of commercial healthcare provider networks for plans on ACA insurance marketplaces, including plan coverage, practice locations, specialties, copays and drug formularies.  There were 7 team submissions, most of which produced solutions focusing on usability for consumers and advanced analytics to policy makers.  Some teams expanded the scope to include not just insurance selection, but access to care in general.

To summarize some of the novel ideas in the solutions…

  • Simplified mobile-first user experience, resembling TurboTax for health selection
  • Visualizations and what-if analysis for policy makers
  • Voice recognition and NLP, as in Google freeform search instead of menus and buttons
  • Ranking algorithms and recommendation engines
  • Ingesting additional 3rd party information (such as Vitals, Yelp, and Part D claims) for consumers who need additional information before they can make an informed choice
  • Providing an API for other apps to leverage
  • Enabling self-reporting of network accuracy, like GasBuddy for health plan coverage

Here are some notable entries for this prompt:

The Hhs-marketplace team created an app that leverages chart visualizations to let a consumer compare plan attributes against benchmarks, such as state averages.  The example below shows a user entering a zip code and the specialists they’re interested in seeing.  The app finds the plans that meet those criteria, displays cost comparisons for them and a graphical comparison of the options.

 

The Fhir salamander team created mobile-first responsive web front end that takes the user through a series of simple menu choices to get them to recommended plans.  Along the way, for convenience and efficiency, it enables the user to click a button to place a telephone call to the plans (to ensure that the doctor they want is taking new patients from that plan) or to view the summary plan description files.

In working on the challenge the team transcribed the JSON provider network schema into a relational model.  They reported identifying data quality issues and therefore needing to clean up the raw data in order to use it for analytics.  They also generated state-level statistics to assist in comparison.  The app is written in Javascript, while the analytics are in Python.  They feel that the relational model, code to load it and the code to clean up the data could be reused elsewhere.  While the AWS website (http://tiny.cc/bayeshhs_fsdemo) is no longer live, the deck is available (http://tiny.cc/bayeshhs_fs).

The Hhs insights team produced an interactive provider density map.  Their approach was to target policy makers, rather than consumers.  For that purpose, they built aggregate analytics and related visualizations.  For example, their code uses DOL MSA (Metro Statistical Area) for GeoJSON calculations and visualizations.  In order to enable the needed analytics, they had to take on the challenge of normalizing the JSON schema of provider networks into a tabular format, as well as pre-calculating several aggregate metrics.

The Hhs marketplace finder team created an app that displays the pros-cons of the top 5 plan option for the
user, along with visualizations for making quantitative comparisons easy to understand.  Bad choices are suppressed to avoid screen clutter.  It starts with less than 10 simple questions.  Then adds a prediction of the user’s healthcare needs, which was determined based on statistics by age, gender, preexisting conditions and location.  Finally, it would eventually make it possible for a user to estimate their total cost based on different events, such as hospitalization or illness.
A data science team from Berkeley calling themselves Semantic Search, submitted an extremely ambitious

project.  Basically, creation of a Google Pagerank for healthcare decisions.  Instead of the menus and buttons of a traditional app UI, this solution used a freeform field for a user to indicate what they were looking for.  The goal is to let a consumer who is not tech saavy explain their situation in a natural way, without the interface and technology getting in the way.  Under the covers it uses natural language processing, ranking algorithms and a recommendation engine.  The user is ultimately presented with the top couple plans, along with explanations of why they were recommended.  To make the solution possible, this app has to collect behavioral data logs, use logistic regression to predict the probability that a certain plan would work, and leverage the LETOR ranking mechanism to provide answers.
As an interesting side note, a Schema.org standard for U.S. health insurance networks has recently been adopted.  Eventually, medical groups and insurance companies can publish semantically tagged information directly to the web, bypassing the current single point of collection at CMS.  This would allow for a growth of relevant data that could be used by applications like this one.

 

 

Disclaimer: The challenge prompt used for HHS does not constitute the department’s official stance or endorsement of this activity.  It was used in an unofficial capacity only and intended to take advantage of data newly available from industry due to changes in regulations of the health insurance marketplace.

 

Schema.org publishes health plan and provider network schemas

Some good news on healthcare standards

I have been working with the Google semantic web group for many months to design several schemas that represent healthcare provider networks and health insurance plan coverage.  The good news is that these schemas have been officially published for use with Schema.org.  This is the first step towards a wider adoption for a more consistent designation for this type of information.  The schemas are:

Health Insurance Plan: List of health plans and their corresponding network of providers and drug formularies http://pending.webschemas.org/HealthInsurancePlan
Health Plan Network: Defines a network of providers within an health plan. http://pending.webschemas.org/HealthPlanNetwork
Health Plan Cost Sharing Specification: List of costs to be paid by the covered beneficiary. http://pending.webschemas.org/HealthPlanCostSharingSpecification
Health Plan Formulary: Lists of drugs covered by health plan. http://pending.webschemas.org/HealthPlanFormulary

Now for the background…

In November 2015, the US health agency Centers for Medicare & Medicaid Services (CMS) enacted a new regulatory requirement for health insurers who list plans on insurance marketplaces. They must now publish a machine-readable version of their provider network directory and health plan coverage, publish it to a specified JSON standard, and update it at least monthly. Many major health insurance companies across the US have already started to publish their health plan coverage, provider directories and drug formularies to this standard.

The official schema is kept in a GitHub Repository: https://github.com/CMSgov/QHP-provider-formulary-APIs.  This format makes it possible to see how which changes were made and when.  It also has an issues section to facilitate ongoing discussion about the optimal adoption of the standard.  There’s a website that goes into a more detailed explanation on the background of this effort: https://www.cms.gov/CCIIO/Resources/Data-Resources/marketplace-puf.html.

This website also includes the “Machine-readable URL PUF” seed file” to the actual data that have been published by insurance company.  This file contains URLs that can be crawled to aggregate the latest plan and provider data.

In terms of adoption, U.S. health plans that participate in insurance markeplaces have published: *

  • 39 states
  • 398 health plans
  • ~26,000 URLs describing insurance coverage, provider networks, drug formularies

* Updated November 2016


A group of companies representing the provider, payer and consumer segments of healthcare convened to discuss the standard throughout 2015.  The considerations that went into formation of the standard can be found at: http://ddod.healthdata.gov/wiki/Interoperability:_Provider_network_directories

Vision of healthcare provider network directories

Background

There are four pieces of information that U.S. consumers need to make informed choices about their healthcare insurance coverage.

  1. Directory: What are the healthcare provider demographics, including specialty, locations, hours, credentialing?
  2. Coverage: Does the provider take a particular insurance plan?
  3. Benefits: What are the benefits, copays and formularies associated with my plan?
  4. Availability: Is the provider accepting new patients for this particular insurance plan and location?

Without having these capabilities in place, consumers are likely to make uninformed decisions or delay decisions.  That in turn has significant health and financial impacts.

Problem

Healthcare provider directories have historically been supplied by the NPPES database.  But it has been lacking in terms of being accurate, up to date, or even able to represent reality accurately.  First, the overhead of making changes is quite high and there hasn’t been an easy way for a provider to delegate ability to make changes.  Second, the incentives aren’t there.  There are no penalties for abandoning updates and many providers don’t realize how frequently NPPES data is downloaded and propagated to consumer-facing applications.  Third, the data model is fixed by regulation, but it cannot accurately represent the many-to-many relationships among practitioners, groups, facilities and locations.  It also doesn’t adequately reflect the ability to manage multiple specialties and accreditations.


Incidentally, my work in the area of provider directories has been driven by the needs of DDOD.  Specifically, there were at least five DDOD use cases that directly depended on solving the provider directory problems.  But the actual problem extends well past the use cases.  An accurate and standardized “provider dimension” is needed for any type of analytics or applications involving providers.  That could include having access to insurance coverage information to analytics on utilization, open payments, fraud and comparative effectiveness research.

Addressing consumers need to understand their options in terms of coverage and benefits has historically been a challenge that’s yet to be solved.  There are routine complaints of consumers signing up for new coverage, only to find out that their provider doesn’t take their new plan or that they are not accepting patients for their plan.  These problems have been the driver for Insurance Marketplaces (aka, FFMs) instituting a new rule requiring QHPs (Qualified Health Plans) to publish machine readable provider network directories that are updated on at least a monthly basis.  This rule, which is effective open enrollment 2015 and the technical challenges around it are described in detail in the related DDOD discussion on provider network directories.  (Note that although the rule refers to “provider directories”, in reality it includes all 4 pieces of information.)  CMS already collects all this information from QHPs during the annual qualifications process.  It asks payers to submit template spreadsheets containing information about their plans, benefits and provider networks.

The seemingly simple question as to whether a provider is taking new patients has been a challenge as well.  That’s because the answer is both non-binary and volatile.  The answer might be different depending on insurance plan, type of referral, location and even time of day.  It may also fluctuate based on patient load, vacations and many other factors.  The challenged becomes even harder when you consider the fact that providers often don’t have the time or financial incentive to update this information with the payers.

Approach

Aneesh Chopra and I put together an industry workgroup to help determine how to best implement the QHP rule.  The workgroup spans the full spectrum of industry participants, payers, payer-provider intermediaries, providers and consumer applications.  It should be noted that we have an especially strong representation from payers and intermediaries, representing a substantial portion of the market.  While looking at the best ways to implement the rule from a technical and logistical perspective, we identified a missing leg: incentives.

3 pillars needed to reach critical mass for a new standard to become sustainable
Technology Logistics Incentives

The QHP rule and the specified data schema provides a starting point for the technology.  Workgroup participants also suggested how to use their organizations’ existing systems capabilities to fulfill the rule requirements.  We discussed logistics of how data can get moved from its multiple points of origin to CMS submission.

Through this exercise, it became quite clear that the implementation of the QHP mandate could make significant progress towards achieving its stated goals if certain actions are taken in another area — Medicare Advantage (MA).  That’s because, much of the data in the proposed standard originates with providers, rather than payers.  Such data typically includes provider demographics, credentialing, locations, and whether they’re accepting new patients.  But at this point, marketplaces are able to only exert economic pressure on payers.  MA, on the other hand, can leverage the STAR rating system to establish incentives for providers as well, which typically get propagated into provider-payer contracts.  STAR incentives are adjusted every year.  So it should be well within CMS’s ability to establish the desired objectives.  They can also leverage the CAHPS survey to measure the level of progress these efforts are making towards providing the necessary decision making tools to consumers.  At the moment, marketplaces don’t have any such metric.

It’s worth noting that Original Medicare (aka, Medicare FFS or Fee for Service) has an even stronger ability to create incentives for providers and I’ve been talking with CMS’s CPI group about publishing PECOS data to the new provider directory standard.  PECOS enjoys much more accurate and up to date provider data than NPPES, due to its use for billing.  But the PECOS implementation is not as challenging as its QHP counterpart in that we’re effectively publishing coverage for only one plan.  So complexities around plan coverage and their mapping to provider networks don’t apply.  But consumers still benefit from up to date provider information.

Vision

If we create incentive-driven solutions in the areas of Marketplaces, Medicare Advantage, Managed Medicaid, and Original Medicare, we might be able to solve the problems plaguing NPPES without requiring new regulation or a systems overhaul.  We will be including the vast majority of the practitioners across the U.S., almost all payers and deliver the needed information for consumers to make decisions about their coverage.

Finally, we are partnering with Google to leverage the timing of the QHP rule with a deployment of a compatible standard on Schema.org.  Doing so would help cement the standards around provider directories and insurance coverage even further.  It empowers healthcare providers and payers to publish their information in a decentralized manner.  Since updating information is so easy, it can happen more frequently.  Third party applications could pull this information directly from the source, rather than relying on a central body.  And the fact that search engines correctly interpret and index previously unstructured data means faster answers for consumers even outside of specialized applications.

Record matching on mortality data

I’m looking forward to teaming up with my HHS Entrepreneur-in-Residence cohorts Paula Braun and Adam Culbertson.  We have a “perfect storm” coming up, where all three of our projects are intersecting.  Paula is working on modernizing the nation’s mortality reporting capabilities.  Adam has been working with the HIMSS (Heath Information Management Society and Systems) organization to improve algorithms and methods for matching patient records.  And I, for the DDOD project, have been working on a use case to leverage NDI (National Death Index) for outcomes research.  So the goals of mortality system modernization, patient matching and outcomes research are converging.Patient Matching Exercise

To that end, Adam organized a hackathon at the HIMSS Innovation Center in Cleveland for August 2015.  This event throws in one more twist: the FHIR (Fast Healthcare Interoperability Resources) specification.  FHIR is a flexible standard for exchanging healthcare information electronically using RESTful APIs.  The hackathon intends to demonstrate what can be accomplished when experts from different domains combine their insights on patient matching and add FHIR as a catalyst.  The event is broken into two sections:

Section 1:  Test Your Matching Algorithms
Connect matching algorithms to a FHIR resource server containing synthetic patient resources.  The matching algorithms will be updated to take in FHIR patient resources and then perform a de-duplication of the records.  A final list of patient resources should be produced.  Basic performance metrics can then be calculated to determine the success of the matching exercise.  Use the provided tools, or bring your own and connect them up.Section 2:  Development Exercise
Develop applications that allow EHRs to easily update the status of patients who are deceased. A synthetic centralized mortality database, such as the National Death Index or a state’s vital statistics registry, will be made available through a FHIR interface.  External data sources, such as EHRs, will be matched against this repository to flag decedents. The applications should be tailored to deliver data to decision makers. This scenario will focus on how different use cases drive different requirements for matching.

Matching algorithms for patient recordsPatient matching and de-duplication is an important topic in EHRs (Electronic Health Records) and HIEs (Health Information Exchanges), where identifying a patient uniquely impacts clinical care quality, patient safety, and research results.  It becomes increasingly important as organizations exchange records electronically and patients seek treatment across multiple healthcare providers.   (See related assessment titled “Patient Identification and Matching Report” that was delivered to HHS’s ONC in 2014.)

We’re looking forward to reporting on progress on all three initiatives and the common goal.

This topic is covered on the HHS IDEA Lab blog:  http://www.hhs.gov/idealab/2015/08/10/teaming-advance-patient-matching-hackathon/

Appendix: Background on patient matching

Additional challenges occur because real-world data often has errors, variations and missing attributes.  Common errors could include misspellings and transpositions.  Many first names in particular could be written in multiple ways, including variations in spelling, formality, abbreviations and initials.  In large geographies, it’s also common for there to be multiple patients with identical first and last names.

Data set Name Date of birth City of residence
Data set 1 William J. Smith 1/2/73 Berkeley, California
Data set 2 Smith, W. J. 1973.1.2 Berkeley, CA
Data set 3 Bill Smith Jan 2, 1973 Berkeley, Calif.

Although there’s a broad range of matching algorithms, they can be divided into two main categories:

  • Deterministic algorithms search for an exact match between attributes
  • Probabilistic algorithms score an approximate match between records

These are often supplemented with exception-driven manual review.  From a broader, mathematical perspective, the concept we’re dealing with is entity resolution (ER).  There’s a good introductory ER tutorial that summarizes the work in Entity Resolution for Big Data, presented at KDD 2013.  Although it looks at the discipline more generically, it’s still quite applicable to patient records.  It delves into the areas of Data Preparation, Pairwise Matching, Algorithms in Record Linkage, De-duplication, and Canonicalization.  To enabling scalability, it suggest use of Blocking techniques and Canopy Clustering    These capabilities are needed so often, that they may be built into commercial enterprise software.  IBM’s InfoSphere MDM (Master Data Management) is an example.

Metrics for patient matchingWhen comparing multiple algorithms for effectiveness, we have a couple good metrics: precision and recall.  Precision identifies how many of the matches were relevant, while recall identifies how many of the relevant items were matched.  F-Measure combines the two.  It should be noted that the accuracy metric, which is the ratio of items accurately identified to the total number of items, should be avoided.  It suffers from the “accuracy paradox”, where lower measures of accuracy may actually be more predictive

 

  • Precision:     p = TP/(TP+FP)
  • Recall:    r = TP/(TP+FN)
  • F-Measure =  2 p r / (p + r)
  • Accuracy:   a = TP+TN/(TP+TN+FP+FN)

In the long run, the challenge can also be approached from the other side.  In other words, how can the quality of data entry and storage within an organization be improved.  This approach could reap benefits in downstream matching, reducing the need for complex algorithms and improving accuracy.  AHIMA published a primer on Patient Matching in HIEs, in which they go as far as calling for a nationwide standard that would facilitate more accurate matching.  They suggest standardizing on commonly defined demographic elements, eliminating use of free text entry except for proper names, and ensuring multiple values aren’t combined in single fields.

Healthcare Provider Registries

As I’ve been reviewing Use Cases for DDOD (Demand-Driven Open Data), I’m realizing how much the industry depends on an up-to-date, reliable source of healthcare providers (aka, physicians, groups, hospitals, etc.).  Although some people may also call such an effort “NPI registry”, the actual need identified encompasses much more than even the fields and capabilities of the existing NPPES database.

Here are just the Use Cases that directly mention NPPES and other existing registries.

And besides these, there are at least a dozen more that would benefit from this repository, since they rely on the “provider” dimension for their analytics.  For example, most analysis on provider quality, utilization, and fraud depend on this dimension.

The most obvious improvements needed are around:

  • More realistic association between provider, group, and location, recognizing that these are many-to-many relationships that change with time
  • More accurate specialty taxonomy
  • More up to date information (since NPPES entries are rarely updated)
  • Easier method to query this information (rather than relying on zip file downloads)

But there are challenges on the “input” side of the equation as well.  There also seems to be some confusion in terms of assigning rights for modifying registries.  For example, it’s not easy for a provider group to figure out how to delegate update rights for all of its physicians to third party administrator.

There’s a growing list of companies and non-profits (including the American Medical Association) that have been trying to capitalize on the opportunities for a better solution.  As we go about working on the use cases mentioned here, I’d be looking to build a body of knowledge that would contribute to solving the core problems identified.


Related post:  CMS is enabling streamlined access to NPPES, PECOS, EHR to 3rd parties

 

The Birth of Demand-Driven Open Data

And so it begins

My project as an Entrepreneur-in-Residence with the HHS IDEA Lab is called “Innovative Design, Development and Linkages of Databases”.  Think of it as Web 3.0 (the next generation of machine readable and programmable internet applications) applied to open government and focused on healthcare and social service applications.  The underlying hypothesis was that by investigating how HHS could better leverage its vast data repositories as a strategic asset, we would discover innovative ways to create value by linking across datasets from different agencies.

So to sum up…  I was to find opportunities across a trillion dollar organization, where the experts already working with the data have a lifetime of domain-specific experience and several acronyms after their name.  And I was to accomplish this without any dedicated resources within one year.  Pretty easy, right?

My hope was that my big data experience in industry — both for startups and large scale enterprises — was a sufficient catalyst to make progress.  And I had one other significant asset to make it all come together…  I was fortunate that the project was championed by a phenomenal group of internal backers: Keith Tucker and Cynthia Colton, who lead the Enterprise Data Inventory (EDI) in the Office of the Chief Information Officer (OCIO), and Damon Davis, who heads up the Health Data Initiative and HealthData.gov.

Tell me your data fantasies

The first step was to set out on a journey of discovery.  With guidance and clout from the internal sponsors, I was able to secure meetings with leaders and innovators for big data and analytics efforts across HHS.  I had the privilege of engaging in stimulating discussions at CMS, FDA, NIH, CDC, NCHS, ONC, ASPE and several other organizations.

Upon attempting to synthesize the information gathered into something actionable, I noticed that past open data projects fell into two camps.  In the first camp, were those with ample examples of how external organizations were doing fantastic and often unexpected things with the data.  In the second, while the projects may have been successfully implemented from a technical perspective, it wasn’t clear whether or how the data was being used.

The “aha” moment

That’s when it hit me — we’re trying to solve the wrong problem.  It seemed that the greatest value that has been created with existing HHS data — and thereby the most innovative linkages — has been done by industry, researchers and citizen activists.  That meant we can accomplish the main goals of the project if we look at the problem a bit differently.  Instead of outright building the linkages that we think have value, we can accelerate the rate at which external organizations to do what they do best.

It seemed so obvious now. In fact, I had personally experienced this phenomenon myself.  Prior to my HHS fellowship, I built an online marketplace for medical services called Symbiosis Health.  I made use of three datasets across different HHS organizations.  But I did so with great difficulty.  Each had deficiencies which I thought should be easy to fix.  It might be providing more frequent refreshes, adding a field that enables joins to another dataset, providing a data dictionary or consolidating data sources.  If only I could have told someone at HHS what we needed!

Let’s pivot this thing

Thus, the “pivot” was made.  While pivoting is a well known concept for rapid course correction in Lean Startup circles, it’s not something typically associated with government.  Entrepreneurs are supposed to allow themselves to make mistakes and make fast course corrections.  Government is supposed to plan ahead and stay the course.  Except in this case we have the best of both worlds — IDEA Lab.  It gives access to all the resources and deep domain expertise of HHS, but with the ability to pivot and continue to iterate without being weighed down by original assumptions!  I feel fortunate for an opportunity to work in such an environment.

Pivoting into Demand-Driven Open Data


So what exactly is this thing?

The project born from this pivot is called Demand-Driven Open Data (DDOD).  It’s a framework of tools and methods to provide a systematic, ongoing and transparent mechanism for industry and academia to tell HHS what data they need.  With DDOD, all open data efforts are managed in terms of “use cases” which enables allocation of limited resources based on value.  It’s the Lean Startup approach to open data.  The concept is to minimize up front development, acquiring customers before you build the product.

As the use cases are completed, several things happen.  Outside of the actual work done on adding and improving datasets, both the specifications and the solution associated with the use cases are documented and made publicly available on the DDOD website.  Additionally, for the datasets involved and linkages enabled, we add or enhance relevant tagging, dataset-level metadata, data dictionary, cross-dataset relationships and long form dataset descriptions.  This approach, in turn, accelerates future discoveries of datasets.  And best of all, it stimulates the linking we wanted in the first place, through coded relationships and field-level matching. 

How does it fit into the big picture?

It’s beautiful how the pieces come together.  DDOD incorporates quite well with HHS’s existing Health Data Initiative (HDI) and HealthData.gov.  While DDOD is demand-driven from outside of HHS, you can think of HDI as its supply-driven counterpart.  That’s the one guided by brilliant subject matter experts throughout HHS.  Finally, HealthData.gov is the data indexing and discovery platform that serves as a home for enabling both these components.  As a matter of fact, we’re looking for DDOD to serve as the community section of HealthData.gov.

Let’s roll!

So now the fun begins.  Next up…  More adventure as we work through actual pilot use cases.  We’ll also cover some cool potential components of DDOD that would put more emphasis on the “linkages” aspect of the project.  These include usage analytics, data maturity reporting, and semantic tagging of the dataset catalog and fields in the data dictionary.  Stay tuned.

 In the mean time, you can get involved in two ways…  Get the word out to your network about the opportunities provided by DDOD.  Or, if you have actual use cases to add, go to http://demand-driven-open-data.github.io/ and get them entered.

 

CMS is enabling streamlined access to NPPES, PECOS, EHR to 3rd parties

I had a couple conversations this week with subject matter experts from industry and government about the NPPES and PECOS systems.

NPPES (National Plan and Provider Enumeration System) is a registry of healthcare providers, including their NPI (National Provider Identifier), specialty taxonomy and contact information.

PECOS (Medicare Provider Enrollment, Chain, and Ownership System) is a system that supports Medicare enrollment for providers and has its own similar database.

There seems to be a lot of demand for these systems to be:

  1. Kept up to date.  Currently NPPES is often too out of date to be useful for patients.  PECOS is updated more frequently, but isn’t available publicly.
  2. Easier to update.  One of the reasons NPPES is not updated often is the difficulty and overhead of doing so.  It would benefit greatly from an easier user interface, a public API and ability for surrogate 3rd parties to make updates.
  3. More realistic.  The data model for NPPES is much to simplistic to reflect the way providers currently do their work.  It should allow for many-to-many relationships between physicians, organizations and locations.
  4. Kept in sync. Discrepancies between NPPES and PECOS may be hard to resolve.  Sometimes it’s due to NPPES being out of date.  Other times it’s because the provider handles billing for Medicare differently .

First, my colleague and fellow HHS Entrepreneur-in-Residence, Alan Viars, has been leading a phenomenal effort to build a robust API for NPPES.  It was created as part of 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.  It was developed to focus on functionality and let external developers design beautiful user interfaces.

Second, CMS’s Identity & Access (I&A) Management System may help with some of these needs.  I&A is supposed to enable “streamlined access to NPPES, PECOS, and EHR” to both healthcare providers and their 3rd party surrogates.  There’s an introductory presentation on the topic that explains further: http://www.cms.gov/Outreach-and-Education/Outreach/NPC/Downloads/508-IA-Call-FINALDM2.pdf.  That said, I still need to familiarize myself with it and its capabilities.

 

PS: In an effort to help people who had problems with the CMS website, I uploaded a video to YouTube that demonstrates how a 3rd party can request to work on behalf of a healthcare provider as a surrogate.

U.S. Turns to Private Sector for IT Innovation

Last week, the Department of Health and Human Services welcomed its third group of “entrepreneurs-in-residence” — mainly private-sector tech experts and start-up founders who are spending a year advising the agency on its health IT projects.   Read the full article in The Washington Post

HHS's IDEA Lab External Entrepreneurs

U.S. Turns to Private Sector for IT Innovation and HHS’s IDEA Lab External Entrepreneurs make it happen.
(Photo: David Portnoy, from left, Mark Scrimshire, Niall Brennan and Damon Davis working on project in the HHS IDEA Lab.)

HHS IDEA Lab – Innovative Linkages Initiative

HHS IDEA LabFull speed ahead on a bold new initiative from the HHS IDEA Lab called “Innovative Design, Development and Linkages of Databases“.

As the largest funder of biomedical research in the world, U.S. Department of Health and Human Services (HHS) directly and indirectly generates massive amounts of scientific data through research, grants, and contracts. The HHS Office of the Chief Information Officer and the HHS IDEA Lab want to build an innovative strategy to design, develop and link public-facing research database applications for the HHS.

The goal of this project is to create a solution to the U.S. Department of Health and Human Services’ (HHS)  current problem of multiple, disparate data sources that simultaneously meets the requirements of two new White House memoranda (Increasing Access to Results of Federally Funded Scientific Research and Open Data Policy – Managing Information as an Asset).

Case study in Linked Data and Semantic Web: The Human Genome Project

The National Human Genome Research Institute’s “GWAS Catalog” (Genome-Wide Association Studies) project is a successful implementation of Linked Data (http://linkeddata.org/) and Semantic Web (http://www.w3.org/standards/semanticweb/) concepts.  This article discusses how the project has been implemented, challenges faced and possible paths for the future.