Earlier this week I attended a Roundtable event at Harvard hosted by Aneesh Chopra and Nick Sinai. The topic was open health data. The Roundtable had a jam-packed room of some of the best minds in the #OpenHealthData community. It was a high energy session and it demonstrates how this country can do amazing things when we work together.
So here is my personal perspective as I reflect on those fascinating discussions:
Patients at the center:
One of the participants made a most astute comment. “We have to put the consumer/patient at the center.” This is absolutely critical.
The industry has spent far too long and far too many resources to organize for outcomes without involving the patient. To correct that we have to treat the patient as a true peer in what we are building. That does not mean the patient has to self manage but instead means that they can choose a service like PicnicHealth, MedYear, HealthVault or any other service that comes along that they choose to trust with their data. This is where earlier iterations have stumbled. Direct is an example, where the industry is closing ranks to apply authentication that is hard to scale in the consumer space, leaving the consumer as a second class citizen in the network – a receive only node.
Avoiding a repeat of this outcome requires that we set two “stretch goals”:
- We push FHIR implementers to include write access in their FHIR Implementation. Write functionality is an Implicit feature of the FHIR spec but I fear that most implementers will resist implementing this part of the spec. Privately I see this as a stretch goal for my CMS BlueButton assignment. I want to push for beneficiaries to be able to trust applications to update the self entered data In their CMS personal health record.
Bi-directional data transfer is critical to pushing the interoperability envelope but it is the key to making step changes in the efficient operation of the healthcare system. Bi-directional data flows open up the possibility for patients to submit corrections to their records. Think of what that could do to save money by adding an extra data point to fraud, waste and abuse analysis.
- Accomplishing objective 1 requires that we also push forward with User Managed Access and convert the HEART workgroup efforts from policy discussion to pilot implementation. This will provide a framework whereby beneficiaries can choose which applications they trust to: read, write or read and write to any particular FHIR implementation. Ie. Something they choose when they connect an app to a FHIR data stream.
I think that these two objectives will go a long way to giving control of their data to patients and making them a true peer in the network.
BlueButton on FHIR
For my part as HHS Entrepreneur-in-Residence at CMS I am actively working on building “BlueButton on FHIR”. My personal goal is to create a prototype service using fake/test data that could be demonstrated at a Developer.HealthCa.mp collaborative learning event that would precede the Health Data Palooza (May 30 or 31st, 2015). I welcome any help and support to get the Prototype operational and to organize the HealthCa.mp event.
To move this forward I have published a draft Medicare BlueButton Plus file format in JSON and XML. Check out the repository on Github: http://2.healthca.mp/1FEyrz3
I have also been thinking about the Provider Directory issue. I remember from my time with the Blues how I would have earnest discussions with the team responsible for Provider Directories. The payers will argue that their directories are up to date. They update them as soon as they receivers formation from the provider. The problem is that the providers have no incentive to update the numerous payer directories they belong to. That is unless their checks stop arriving.
Consequently I think the idea of tagging web pages with meta data has some legs. However, I think we need to produce a set of open source tools that Providers can use to maintain their own records. If the medical professional maintains the information on the plans they participate in this can be crawled by the payer organizations who then cross check with their own records that the provider is in fact included in specific plans. Unless we go down to the facility/provider level to enable easy publication we will always be fighting the CICO issue (crap in-crap out).
Alan Viars,Fred Trotter and others have already done some work on this Association/Linkages issue. Using machine readable meta tags should provide a mechanism whereby providers can declare an association to a payer/plan and linking to a payer/plan dataset allows a cross-check to show that the plan recognizes the payer as part of the relevant plan. A bi-directional handshake. I am sure it wouldn’t take much for a Google or other search engine to use this tagging to create a dual certified (provider/payer) directory.
I can’t speak for CMS but they could kickstart this approach by requiring providers to record in their NPI record not just their direct email address but also the uri where their plan reference data is stored. This could be their own web site or a third party site they defer to (eg. A payer directory).
[category News, Health, BlueButton]
[tag health, cloud, ONC, opendata, BlueButton]
Health & Cloud Technology Consultant
Mark is available for challenging assignments at the intersection of Health and Technology using Big Data, Mobile and Cloud Technologies. If you need help to move, or create, your health applications in the cloud let’s talk.
Stay up-to-date: Twitter @ekivemark
I am currently HHS Entrepreneur-in-Residence working on an assignment to update BlueButton for Medicare Beneficiaries.
The views expressed on this blog are my own.
I am also a Patient Engagement Advisor, CTO and Co-Founder to Medyear.com. Medyear is a powerful free tool that helps you collect, organize and securely share health information, however you want. Manage your own health records today.
Medyear: Less hassle. Better care.
via WordPress http://2.healthca.mp/1wuyHBB