Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and HIPAA for FREE!!

The Burden of Structured Data: What Health Care Can Learn From the Web Experience (Part 2 of 2)

Posted on September 23, 2016 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The first part of this article summarized what Web developers have done to structure data, and started to look at the barriers presented by health care. This part presents more recommendations for making structured data work.

The Grand Scheme of Things
Once you start classifying things, it’s easy to become ensnared by grandiose pipe dreams and enter a free fall trying to design the perfect classification system. A good system is distinguished by knowing its limitations. That’s why microdata on the Web succeeded. In other areas, the field of ontology is littered with the carcasses of projects that reached too far. And health care ontologies always teeter on the edge of that danger.

Let’s take an everyday classification system as an example of the limitations of ontology. We all use genealogies. Imagine being able to sift information about a family quickly, navigating from father to son and along the trail of siblings. But even historical families, such as royal ones, introduce difficulties right away. For instance, children born out of wedlock should be shown differently from legitimate heirs. Modern families present even bigger headaches. How do you represent blended families where many parents take responsibilities of different types for the children, or people who provided sperm or eggs for artificial insemination?

The human condition is a complicated one not subject to easy classification, and that naturally extends to health, which is one of the most complex human conditions. I’m sure, for instance, that the science of mosquito borne diseases moves much faster than the ICD standard for disease. ICD itself should be replaced with something that embodies semantic meaning. But constant flexibility must be the hallmark of any ontology.

Transgender people present another enormous challenge to ontologies and EHRs. They’re a test case for every kind of variation in humanity. Their needs and status vary from person to person, with no classification suiting everybody. These needs can change over time as people make transitions. And they may simultaneously need services defined for male and female, with the mix differing from one patient to the next.

Getting to the Point
As the very term “microdata” indicates, those who wish to expose semantic data on the Web can choose just a few items of information for that favored treatment. A movie theater may have text on its site extolling its concession stand, its seating, or its accommodations for the disabled, but these are not part of the microdata given to search engines.

A big problem in electronic health records is their insistence that certain things be filled out for every patient. Any item that is of interest for any class of patient must appear in the interface, a problem known in the data industry as a Cartesian explosion. Many observers counsel a “less is more” philosophy in response. It’s interesting that a recent article that complained of “bloated records” and suggested a “less is more” approach goes on to recommend the inclusion of scads of new data in the record, to cover behavioral and environmental information. Without mentioning the contradiction explicitly, the authors address it through the hope that better interfaces for entering and displaying information will ease the burden on the clinician.

The various problems with ontologies that I have explained throw doubt on whether EHRs can attain such simplicity. Patients are not restaurants. To really understand what’s important about a patient–whether to guide the clinician in efficient data entry or to display salient facts to her–we’ll need systems embodying artificial intelligence. Such systems always feature false positives and negatives. They also depend on continuous learning, which means they’re never perfect. I would not like to be the patient whose data gets lost or misclassified during the process of tuning the algorithms.

I do believe that some improvements in EHRs can promote the use of structured data. Doctors should be allowed to enter the data in the order and the manner they find intuitive, because that order and that manner reflect their holistic understanding of the patient. But suggestions can prompt them to save some of the data in structured format, without forcing them to break their trains of thought. Relevant data will be collected and irrelevant fields will not be shown or preserved at all.

The resulting data will be less messy than what we have in unstructured text currently, but still messy. So what? That is the nature of data. Analysts will make the best use of it they can. But structure should never get in the way of the information.

The Burden of Structured Data: What Health Care Can Learn From the Web Experience (Part 1 of 2)

Posted on September 22, 2016 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

Most innovations in electronic health records, notably those tied to the Precision Medicine initiative that has recently raised so many expectations, operate by moving clinical information into structure of one type or another. This might be a classification system such as ICD, or a specific record such as “medications” or “lab results” with fixed units and lists of names to choose from. There’s no arguing against the benefits of structured data. But its costs are high as well. So we should avoid repeating old mistakes. Experiences drawn from the Web may have something to teach the health care field in respect to structured data.

What Works on the Web
The Web grew out of a structured data initiative. The dream of organizing information goes back decades, and was embodied in Standard Generalized Markup Language (SGML) years before Tim Berners-Lee stole its general syntax to create HTML and present information on the Web. SGML could let a firm mark in its documents that FR927 was a part number whereas SG1 was a building. Any tags that met the author’s fancy could be defined. This put semantics into documents. In other words, the meaning of text could be abstracted from the the text and presented explicitly. Semantics got stripped out of HTML. Although the semantic goals of SGML were re-introduced into the HTML successor XML, it found only niche uses. Another semantic Web tool, JSON, was reserved for data storage and exchange, not text markup.

Since the Web got popular, people have been trying to reintroduce semantics into it. There was Dublin Core, then RDF, then microdata in places like schema.org–just to list a few. Two terms denoting structured data on the Web, the Semantic Web and Linked Data, have been enthusiastically taken up by the World Wide Web Consortium and Tim Berners-Lee himself.

But none of these structured data initiatives are widely known among the Web-browsing public, probably because they all take a lot of work to implement. Furthermore, they run into the bootstrapping problem faced by nearly all standards: if your web site uses semantics that aren’t recognized by the browser, they’re just dropped on the ground (or even worse, the browser mangles your web pages).

Even so, recent years have seen an important form of structured data take off. When you look up a movie or restaurant on a major search engine such a Google, Yahoo!, or Bing, you’ll see a summary of the information most people want to see: local showtimes for the movie, phone number and ratings for a restaurant, etc. This is highly useful (particularly on mobile devices) and can save you the trouble of visiting the web site from which the data comes. Google calls these summaries Rich Cards and Rich Snippets.

If my memory serves me right, the basis for these snippets didn’t come from standards committees involving years of negotiation between stake-holders. Google just decided what would be valuable to its users and laid out the standard. It got adopted because it was a win-win. The movie theaters and restaurants got their information right into the viewer’s face, and the search engine became instantly more valuable and more likely to be used again. The visitors doing the search obviously benefitted too. Everyone found it worth their time to implement the standards.

Interestingly, as structure moves into metadata, HTML itself is getting less semantic. The most recent standard, HTML5, did add a few modest tags such as header and footer. But many sites are replacing meaningful HTML markup, such as p for paragraph, with two ultra-generic tags: div for a division that is set off from other parts of the page, and span for a piece of text embedded within another. Formatting is expressed through CSS, a separate language.

Having reviewed a bit of Web history, let’s see what we can learn from it and apply to health care.

Make the Customer Happy
Win-win is the key to getting a standard adopted. If your clinician doesn’t see any benefit from the use of structured data, she will carp and bristle at any attempt to get her to enter it. One of the big reasons electronic health records are so notoriously hard to use is, “All those fields to fill out.” And while lists of medications or other structured data can help the doctor choose the right one, they can also help her enter serious errors–perhaps because she chose the one next to the one she meant to choose, or because the one she really wanted isn’t offered on the list.

Doctors’ resentment gets directed against every institution implicated in the structured data explosion: the ONC and CMS who demand quality data and other fields of information for their own inscrutable purposes, the vendor who designs up the clunky system, and the hospital or clinic that forces doctors to use it. But the Web experience suggests that doctors would fill out fields that would help them in their jobs. The use of structured data should be negotiated, not dictated, just like other innovations such as hand-washing protocols or checklists. Is it such a radical notion to put technology at the service of the people using it?

I know it’s frustrating to offer that perspective, because many great things come from collecting data that is used in analytics and can turn up unexpected insights. If we fill out all those fields, maybe we’ll find a new cure! But the promised benefit is too far off and too speculative to justify the hourly drag upon the doctor’s time.

We can fall back on the other hope for EHR improvement: an interface that makes data entry so easy that doctors don’t mind using structured fields. I have some caveats to offer about that dream, which will appear in the second part of this article.

ONC’s Interoperability Standards Advisory Twitter Chat Summary

Posted on September 2, 2016 I Written By

The following is a guest blog post by Steve Sisko (@ShimCode and www.shimcode.com).

Yesterday the Office of the National Coordinator for Health Information Technology (ONC) hosted an open chat to discuss their DRAFT 2017 Interoperability Standards Advisory (ISA) artifacts.  The chat was moderated by Steven Posnak, Director, Office of Standards and Technology at Office of the National Coordinator for Health Information and used the #ISAchat hashtag under the @HealthIT_Policy account. The @ONC_HealthIT Twitter account also weighed in.

It was encouraging to see that the ONC hosted a tweetchat to share information and solicit feedback and questions from interested parties. After a little bit of a rough start and clarification of the objectives of the chat, the pace of interactions increased and some good information and ideas were exchanged. In addition, some questions were raised; some of which were answered by Steven Posnak and some of which were not addressed.

What’s This All About?

This post summarizes all of the tweets from the #ISAchat. I’ve organized the tweets as best as I could and I’ve excluded re-tweets and most ‘salutatory’ and ‘thank you’ tweets.

Note: The @hitechanswers  account shared a partial summary of the #ISAchat on 8/31/16 but it included less than half of the tweets shared in this post. So you’re getting the complete scoop here.

Topic 1: Tell us about the ISA (Interoperability Standards Advisory)
Account Tweet Time
@gratefull080504 Question: What is the objective of #ISAchat?   12:04:35
@onc_healthit To spread the word and help people better understand what the ISA is about 12:05:00
@gratefull080504 Question: What are today’s objectives, please? 12:08:43
@onc_healthit Our objective is to educate interested parties. Answer questions & hear from the creators 12:11:02
@johnklimek “What’s this I hear about interoperability?” 12:12:00
@cperezmha What is #PPDX? What is #HIE? What is interoperability? What is interface? #providers need to know the differences. Most do not. 12:14:41
@techguy Who is the target audience for these documents? 12:44:06
@healthit_policy HITdevs, CIOs, start-ups, fed/state gov’t prog admins. Those that have a need to align standards 4 use #ISAchat 12:46:18
@ahier No one should have to use proprietary standards to connect to public data #ISAchat 12:46:19
@shimcode Reference Materials on ISA
Ok then, here’s the “2016 Interoperability Standards Advisory” https://t.co/5QkmV3Yc6w
12:07:19
@shimcode And here’s “Draft 2017 Interoperability Standards Advisory” https://t.co/TUFidMXk0j 12:07:38
@stephenkonya #ICYMI Here’s the link to the @ONC_HealthIT 2017 DRAFT Interoperability Standards Advisory (ISA): https://t.co/VTqdZHUjBW 12:10:57
@techguy Question: Do you have a good summary blog post that summarizes what’s available in the ISA? 12:52:15
@onc_healthit We do! https://t.co/vVW6BM5TFW Authored by @HealthIT_Policy and Chris Muir – both of whom are in the room for #ISAchat 12:53:15
@healthit_policy Good? – The ISA can help folks better understand what standards are being implemented & at what level 12:06:29
@healthit_policy Getting more detailed compared to prior versions due largely to HITSC & public comments 12:29:48
@healthit_policy More work this fall on our side to make that come to fruition. In future, we’re aiming for a “standards wikipedia” approach 12:33:03
@survivorshipit It would be particularly helpful to include cited full documents to facilitate patient, consumer participation 12:40:22
@davisjamie77 Seeing lots of references to plans to “explore inclusion” of certain data. Will progress updates be provided? 12:50:00
@healthit_policy 1/ Our next milestone will be release of final 2017 ISA in Dec. That will rep’snt full transition to web 12:51:15
@healthit_policy 2/ after that future ISA will be updated more regularly & hopefully with stakeholder involved curation 12:52:21
@bjrstn Topic:  How does the ISA link to the Interoperability Roadmap? 12:51:38
@cnsicorp How will #ISA impact Nationwide Interoperability Roadmap & already established priorities? 12:10:49
@healthit_policy ISA was 1st major deliverable concurrent w/ Roadmap. Will continue to b strong/underlying support to work 12:13:49
@healthit_policy ISA is 1 part of tech & policy section of Roadmap. Helps add transparency & provides common landscape 12:53:55
@healthit_policy Exciting thing for me is the initiated transition from PDF to a web-based/interactive experience w/ ISA 12:30:51
@onc_healthit Web-based version of the ISA can be found here: https://t.co/F6KtFMjNA1 We welcome comments! 12:32:04
@techguy Little <HSML> From a Participant on the Ease of Consuming ISA Artifacts
So easy to consume!
12:40:57
@healthit_policy If I knew you better I’d sense some sarcasm :) that said, working on better nav approaches too 12:43:36
@techguy You know me well. It’s kind of like the challenge of EHRs. You can only make it so usable given the reqs. 12:45:36
@shimcode I think John forgot to enclose his tweet with <HSML> tags (Hyper Sarcasm Markup Language) 12:46:48
@ahier Don ‘t Use My Toothbrush!
OH (Overheard) at conference “Standards are like toothbrushes, everyone has one and no one wants to use yours”
13:15:43
Topic 2: What makes this ISA different than the previous drafts you have issued?
Account Tweet Time
@cnsicorp #Interoperability for rural communities priority 12:32:40
@healthit_policy Rural, underserved, LTPAC and other pieces of the interoperability puzzle all important #ISAchat 12:35:33
@cnsicorp “more efficient, closer to real-time updates and comments…, hyperlinks to projects…” 12:47:15
@shimcode Question: So you’re not providing any guidance on the implementation of interoperability standards? Hmm… 12:21:10
@gratefull080504 Question: Are implementation pilots planned? 12:22:51
@healthit_policy ISA reflects what’s out there, being used & worked on. Pointer to other resources, especially into future #ISAchat 12:24:10
@ahier The future is here it’s just not evenly distributed (yet) #ISAchat 12:25:15
@healthit_policy Yes, we put out 2 FOAs for High Impact Pilots & Standards Exploration Awards 12:25:56
@healthit_policy HHS Announces $1.5 Million in Funding Opportunities to Advance Common Health Data Standards. Info here: https://t.co/QLo05LfsLw
Topic 3: If you had to pick one of your favorite parts of the ISA, what would it be?
Account Tweet Time
@shimcode The “Responses to Comments Requiring Additional Consideration” section. Helps me understand ONC’s thinking. 12:45:32
@healthit_policy Our aim is to help convey forward trajectory for ISA, as we shift to web, will be easier/efficient engagement 12:47:47
@healthit_policy Depends on sections. Some, like #FHIR, @LOINC, SNOMED-CT are pointed to a bunch. 12:49:15
@gratefull080504 Question: What can patients do to support the objectives of #ISAchat ? 12:07:02
@gratefull080504 Question: Isn’t #ISAChat for patients? Don’t set low expectations for patients 12:10:44
@gratefull080504 I am a patient + I suffer the consequences of lack of #interoperability 12:12:26
@healthit_policy Certainly want that perspective, would love thoughts on how to get more feedback from patients on ISA 12:12:35
@gratefull080504 What about patients? 12:13:03
@gratefull080504 First step is to ensure they have been invited. I am happy to help you after this chat 12:13:57
@survivorshipit Think partly to do w/cascade of knowledge–>as pts know more about tech, better able to advocate 12:15:21
@healthit_policy Open door, numerous oppty for comment, and representation on advisory committees. #MoreTheMerrier 12:15:52
@gratefull080504 I am currently on @ONC_HealthIT Consumer Advisory Task Force Happy to contribute further 12:17:08
@healthit_policy 1 / The ISA is technical in nature, & we haven’t gotten any comments on ISA before from patient groups 12:08:54
@healthit_policy 2/ but as we look to pt generated health data & other examples of bi-directional interop, we’d like to represent those uses in ISA 12:09:51
@resultant TYVM all! Trying to learn all i can about #interoperability & why we’re not making progress patients expect 13:09:22
@shimcode Question: Are use cases being developed in parallel with the Interoperability Standards? 12:13:28
@shimcode Value of standards don’t lie in level of adoption of std as a whole, but rather in implementation for a particular use case. 12:16:33
@healthit_policy We are trying to represent broader uses at this point in the “interoperability need” framing in ISA 12:18:58
@healthit_policy 2/ would be great into the future to have more detailed use case -> interop standards in the ISA with details 12:19:49
@healthit_policy Indeed, royal we will learn a lot from “doing” 12:20:40
@shimcode IHE Profiles provide a common language to discuss integration needs of healthcare sites and… Info here: https://t.co/iBt2m8F9Ob 12:29:12
@techguy I’d love to see them take 1 section (say allergies) and translate where we’d see the standards in the wild. 12:59:04
@techguy Or some example use cases where people want to implement a standard and how to use ISA to guide it. 13:00:38
@healthit_policy Check out links now in ISA to the Interop Proving Ground – projects using #ISAchat standards. Info here: https://t.co/Co1l1hau3B 13:02:54
@healthit_policy Thx for feedback, agree on need to translate from ISA to people seeing standards implemented in real life 13:01:08
@healthit_policy Commenting on ISA Artifacts
We want to make the #ISA more accessible, available, and update-able to be more current compared to 1x/yr publication
12:34:22
@cperezmha #interoperability lowers cost and shows better outcomes changing the culture of healthcare to be tech savvy is key 12:35:10
@healthit_policy One new feature we want to add to web ISA is citation ability to help document what’s happ’n with standards 12:37:12
@shimcode A “discussion forum” mechanism where individual aspects can be discussed & rated would be good. 12:39:53
@healthit_policy Good feedback. We’re looking at that kind of approach as an option. ISA will hopefully prompt debate 12:40:50
@shimcode Having to scroll through all those PDF’s and then open them 1 by 1 only to have to scroll some more is VERY inefficient. 12:41:25
@shimcode Well, I wouldn’t look/think too long about it. Adding that capability is ‘cheap’ & can make it way easier on all. 12:43:48
@shimcode Question: What Can Be Learned About Interoperability from the Private Sector?
Maybe @ONC_HealthIT can get input from Apple’s latest #healthIT purchase/Gliimpse? What do they know of interoperability?
12:19:13
@healthit_policy > interest from big tech cos and more mainstream awareness is good + more innovation Apple iOS has CCDA sprt 12:22:59
@drewivan Testing & Tools
I haven’t had time to count, but does anyone know approximately how many different standards are included in the document?
12:47:29
@healthit_policy Don’t know stat off had, but we do identify and provide links for test tools as available. 12:56:31
@drewivan And what percentage of them have test tools available? 12:54:38
@shimcode According to the 2017 ISA stds just released, a tiny fraction of them have test tools. See here: https://t.co/Jbw7flDuTg 12:58:02
@shimcode I take back “tiny faction” comment on test tools. I count 92 don’t have test tools, 46 do. No assessment of tool quality though. 13:08:31
@healthit_policy Testing def an area for pub-private improvement, would love to see # increase, with freely available too 12:59:10
@techguy A topic near and dear to @interopguy’s heart! 12:59:54
@resultant Perhaps we could replace a couple days of HIMSS one year with #interoperability testing? #OutsideBox 13:02:30
 
Walk on Topic: Promotion of ISA (Thank you @cperezmha)
What can HIE clinics do to help other non-users get on board? Is there a certain resource we should point them too to implement?
Account Tweet Time
@davisjamie77 Liking the idea of an interactive resource library. How will you promote it to grow use? 12:35:57
@healthit_policy A tweetchat of course! ;) Also web ISA now linking to projects in the Interoperability Proving Ground 12:39:04
@davisjamie77 Lol! Of course! Just seeing if RECs, HIEs, other #HIT programs might help promote. 12:40:44
@healthit_policy Exactly… opportunities to use existing relationships and comm channels ONC has to spread the word 12:41:28
@stephenkonya Question: How can we better align public vs private #healthcare delivery systems through #interoperability standards? 12:42:23
Miscellaneous Feedback from Participants
Account Tweet Time
@ahier Restful APIs & using JSON and other modern technologies 12:54:03
@waynekubick Wayne Kubick joining from #HL7 anxious to hear how #FHIR and #CCDA can help further advance #interoperability. 12:11:30
@resultant We all do! The great fail of #MU was that we spent $38B and did not get #interoperability 12:14:21
@waynekubick SMART on #FHIR can help patients access and gain insights from their own health data — and share it with care providers. 12:17:44
@resultant I think throwing money at it is the only solution… IMHO providers are not going to move to do it on their own… 12:20:44
@shimcode @Search_E_O your automatic RT’s of the #ISAChat tweets are just clouding up the stream. Why? smh 12:08:30
@ahier
Do you see #blockchain making it into future ISA
12:28:02
@healthit_policy Phew… toughy. lots of potential directions for it. Going to segue my response into T2 12:28:58
@hitpol #blockchain for healthcare! ➡ @ONC_HealthIT blockchain challenge. Info here: https://t.co/vG60qRAqqa 12:31:33
@healthit_policy That’s All Folks!
Thank you everyone for joining our #ISAchat! Don’t forget to leave comments.
PDF version

 
About Steve Sisko
Steve Sisko has over 20 years of experience in the healthcare industry and is a consultant focused on healthcare data, technology and services – mainly for health plans, payers and risk-bearing providers. Steve is known as @ShimCode on Twitter and runs a blog at www.shimcode.com. You can learn more about Steve at his LinkedIn page and he can be contacted at shimcode@gmail.com.

Schlag and Froth: Argonauts Navigate Between Heavy-weight and Light-weight Standardization (Part 2 of 2)

Posted on August 26, 2016 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The previous section of this article laid out the context for HL7 FHIR standard and the Argonaut project; now we can look at the current status.

The fruits of Argonaut are to be implementation guides that they will encourage all EHR vendors to work from. These guides, covering a common clinical data set that has been defined by the ONC (and hopefully will not change soon), are designed to help vendors achieve certification so they can sell their products with the assurance that doctors using them will meet ONC regulations, which require a consumer-facing API. The ONC will also find certification easier if most vendors claim adherance to a single unambiguous standard.

The Argonaut implementation guides, according to Tripathi, will be complete in late September. Because FHIR is expected to be passed in September 2017, the Argonaut project will continue to refine and test the guides. One guide already completed by the project covers security authorization using OpenID and OAuth. FHIR left the question of security up to those standards, because they are well-established and already exist in thousands of implementations around the Web.

Achieving rough consensus

Tripathi portrays the Argonaut process as radically different from HL7 norms. HL7 has established its leading role in health standards by following the rules of the American National Standards Institute (ANSI) in the US, and similar bodies set up in other countries where HL7 operates. These come from the pre-Internet era and emphasize ponderous, procedure-laden formalities. Meetings must be held, drafts circulated, comments explicitly reconciled, ballots taken. Historically this has ensured that large industries play fair and hear through all objections, but the process is slow and frustrates smaller actors who may have good ideas but lack the resources to participate.

In contrast, FHIR brings together engineers and other interested persons in loose forums that self-organize around issues of interest. The process still tried to consider every observation and objection, and therefore, as we have seen, has taken a long time. But decision-making takes place at Internet speed and there is no jockeying for advantage in the marketplace. Only when a milestone is reached does the formal HL7 process kick in.

The Argonaut project works similarly. Tripathi reports that the vendors have gotten along very well. Epic and Cerner, the behemoths of the EHR field, are among the most engaged. Company managers don’t interfere with engineer’s opinions. And new vendors with limited resources are very active.

Those with a background in computers can recognize, in these modes of collaboration, the model set up by the Internet Engineering Task Force (IETF) decades ago. Like HL7, the IETF essentially pre-dated the Internet as we know it, which they helped to design. (The birth of the Internet is usually ascribed to 1969, and the IETF started in 1986, at an early stage of the Internet. FTP was the canonical method of exchanging their plain-text documents with ASCII art, and standards were distributed as Requests for Comments or RFCs.) The famous criteria cited by the IETF for approving standards is “rough consensus and running code.” FHIR and the Argonauts produce no running code, but they seem to operate through rough consensus, and the Argonauts could add a third criterion, “Get the most important 90% done and don’t let the rest hold you up.”

Tripathi reports that EHR vendors are now collaborating in this same non-rivalrous manner in other areas, including the Precision Medicine initiative, the Health Services Platform Consortium (HSPC), and the SMART on FHIR initiative.

What Next?

The dream of interoperability has long included the dream of a marketplace for apps, so that we’re not stuck with the universally hated EHR interfaces that clinicians struggle with daily, or awkwardly designed web sites for consumers. Tripathi notes that SMART offers an app gallery with applications that ought to work on any EHR that conforms to the open SMART platform. Cerner and athenahealth also have app stores protected by a formal approval process. (Health apps present more risk than the typical apps in the Apple App Store or Google Play, so they call more more careful, professional vetting.) Tripathi is certain that other vendors will follow in the lead of these projects, and that cross-vendor stores like SMART’s App Gallery will emerge in a few years along with something like a Good Housekeeping seal for apps.

The Argonaut guides will have to evolve. It’s already clear that EHR vendors are doing things that aren’t covered by the Argonaut FHIR guide, so there will be a few incompatible endpoints in their APIs. Consequently, the Argonaut project has a big decision to make: how to provide continuity? The project was deliberately pitched to vendors as a one-time, lightweight initiative. It is not a legal entity, and it does not have a long-term plan for stewardship of the outcomes.

The conversation over continuity is ongoing. One obvious option is to turn over everything to HL7 and let the guides fall under its traditional process. A new organization could also be set up. HL7 itself has set up the FHIR Foundation under a looser charter than HL7, probably (in my opinion) because HL7 realizes it is not nimble and responsive enough for the FHIR community.

Industries reach a standard in many different ways. In health care, even though the field is narrow, standards present tough challenges because of legacy issues, concerns over safety, and the complexity of human disease. It seems in this case that a blend of standardization processes has nudged forward a difficult process. Over the upcoming year, we should know how well it worked.

Schlag and Froth: Argonauts Navigate Between Heavy-weight and Light-weight Standardization (Part 1 of 2)

Posted on August 25, 2016 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

You generally have to dwell in deep Nerdville to get up much excitement about technical standards. But one standard has been eagerly followed by thousands since it first reached the public eye in 2012: Fast Healthcare Interoperability Resources (FHIR). To health care reformers, FHIR embodies all the values and technical approaches they have found missing in health care for years. And the development process for FHIR is as unusual in health care as the role the standard is hoped to play.

Reform From an Unusual Corner

FHIR started not as an industry initiative but as a pet project of Australian Grahame Grieve and a few developers gathered around him. From this unusual genesis it got taken up by HL7 and an initial draft was released in March 2012. Everybody in health care reform rallied around FHIR, recognizing it as a viable solution to the long-stated need for application programming interfaces (APIs). The magic of APIs, in turn, is their potential to make data exchange easy and create a platform for innovative health care applications that need access to patient data.

So, as a solution to the interoperability problems for which EHR vendors had been dunned by users and the US government, FHIR won immediate accolades. But these vendors knew they couldn’t trust normal software adoption processes to use FHIR interoperably–those processes had already failed on earlier standards.

HL7 version 2 had duly undergone a long approval process and had been implemented as an output document format by numerous EHR vendors, who would show off their work annually at an Interoperability Showcase in a central hall of the HIMSS conference. Yet all that time, out in the field, innumerable problems were reported. These failures are not just technical glitches, but contribute to serious setbacks in health care reform. For instance, complaints from Accountable Care Organizations are perennial.

Congress’s recent MACRA bill, follow-up HHS regulations, and pronouncements from government leaders make it clear that hospitals and their suppliers won’t be off the hook till they solve this problem of data exchange, which was licked decades ago by most other industries. It was by dire necessity, therefore, that an impressive array of well-known EHR vendors announced the maverick Argonaut project in December 2014. (I don’t suppose its name bears any relation to the release a few months before of a highly-publicized report from a short-lived committee called JASON.)

Argonaut include major EHR vendors, health care providers such as Partners Healthcare, Mayo, Intermountain, and Beth Israel Deaconess, and other interested parties such as Surescripts, The Advisory Board, and Accenture. Government agencies, especially the ONC, and app developers have come on board as testers.

One of the leading Argonauts is Micky Tripathi, CEO of the Massachusetts eHealth Collaborative. Tripathi has been involved in health care reform and technical problems such as data exchange long before these achieved notable public attention with the 2009 HITECH act. I had a chance to talk to him this week about the Argonauts’ progress.

Reaching a Milestone

FHIR is large and far-reaching but deliberately open-ended. Many details are expected to vary from country to country and industry to industry, and thus are left up to extensions that various players will design later. It is precisely in the extensions that the risk lurks of reproducing the Tower of Babel that exists in other health care standards.

The reason the industry have good hopes for success this time is the unusual way in which the Argonaut project was limited in both time and scope. It was not supposed to cover the entire health field, as standards such as the International Classification of Diseases (ICD) try to do. It would instead harmonize the 90% of cases seen most often in the US. For instance, instead of specifying a standard of 10,000 codes, it might pick out the 500 that the doctor is most likely to see. Instead of covering all the ways to take a patient’s blood pressure (sitting, standing, etc.), it recommends a single way. And it sticks closely to clinical needs, although it may well be extended for other uses such as pharma or Precision Medicine.

Finally instead of staying around forever to keep chopping off more tasks to solve, the Argonaut project would go away when it was done. In fact, it was supposed to be completed one year ago. But FHIR has taken longer than expected to coalesce, and in the meantime, the Argonaut project has been recognized as a fertile organization by the vendors. So they have extended it to deal with some extra tasks, such as an implementation guide for provider directories, and testing sprints.

That’s some history; the next section of this article will talk about the fruits of the Argonaut project and their plans for the future.

ONC Kicks Off Blockchain Whitepaper Contest

Posted on July 11, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Hold onto your hats, folks. The ONC has taken an official interest in blockchain technology, a move which suggests that it’s becoming a more mainstream technology in healthcare.

As you may know, blockchain is the backbone for the somewhat shadowy world of bitcoin, a “cryptocurrency” whose users can’t be traced. (For some of you, your first introduction to cryptocurrency may have been when a Hollywood, CA hospitals was forced to pay off ransomware demands with $17K in bitcoins.)

But despite its use by criminals, blockchain still has great potential for creating breakthroughs for legitimate businesses, notably banking and healthcare. Look at dispassionately, a blockchain is just a distributed database, one which maintains a continuously growing list with data records hardened against tampering and revision.

Right now, the most common use the blockchain is to serve as a public ledger of bitcoin transactions. But the concept is bubbling up in the healthcare world, with some even suggesting that blockchain should be used to tackle health data security problems.

And now, the ONC has shown interest in this technology, soliciting white papers that offer thoughtful take on how blockchain can help meet important healthcare industry objectives.

The whitepaper, which may not be no longer than 10 pages, must be submitted by July 29. (Want to participate, but don’t have time to write the paper yourself? Click here.Papers must discuss the cryptography and underlying fundamentals of blockchain technology, explain how the use of blockchain can meet industry interoperability needs, patient centered outcomes research, precision medicine and other healthcare delivery needs, as well as offering recommendations for blockchain’s implementation.

The ONC will choose eight winning papers from among the submissions. Winning authors will have an opportunity to present the paper at a Blockchain & Healthcare Workshop held at NIST headquarters in Gaithersburg, MD on September 26th and 27th.

In hosting this contest, ONC is lending blockchain approaches in healthcare a level of credibility they might not have had in the past. But there’s already a lot of discussion going on about blockchain applications for health IT.

So what are people talking about where blockchain IT is concerned? In one LinkedIn piece, consultant Peter Nichol argues that blockchain can address concerns around scalability and privacy electronic medical records. He also suggests that blockchain technology can provide patients with more sophisticated privacy control of their personal health information, for example, providers can enhance health data security by letting patients combine their own blockchain signature with a hospital’s signature.

But obviously, ONC leaders think there’s a lot more that can be done here. And I’m pretty confident that they’re right. While I’m no security or cryptocurrency expert, I know that when a technology has been kicked around for several years, and used for a sensitive function like financial exchange without racking up any major failures, it’s got to be pretty solid. I’m eager to see what people come up with!

Sansoro Hopes Its Health Record API Will Unite Them All

Posted on June 20, 2016 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

After some seven years of watching the US government push interoperability among health records, and hearing how far we are from achieving it, I assumed that fundamental divergences among electronic health records at different sites posed problems of staggering complexity. I pricked up my ears, therefore, when John Orosco, CTO of Sansoro Health, said that they could get EHRs to expose real-time web services in a few hours, or at most a couple days.

What does Sansoro do? Its goal, like the FHIR standard, is to give health care providers and third-party developers a single go-to API where they can run their apps on any supported EHR. Done right, this service cuts down development costs and saves the developers from having to distribute a different version of their app for different customers. Note that the SMART project tries to achieve a similar goal by providing an API layer on top of EHRs for producing user interfaces, whereas Sansoro offers an API at a lower level on particular data items, like FHIR.

Sansoro was formed in the summer of 2014. Researching EHRs, its founders recognized that even though the vendors differed in many superficial ways (including the purportedly standard CCDs they create), all EHRs dealt at bottom with the same fields. Diagnoses, lab orders, allergies, medications, etc. are the same throughout the industry, so familiar items turn up under the varying semantics.

FHIR was just starting at that time, and is still maturing. Therefore, while planning to support FHIR as it becomes ready, Sansoro designed their own data model and API to meet industry’s needs right now. They are gradually adding FHIR interfaces that they consider mature to their Emissary application.

Sansoro aimed first at the acute care market, and is expanding to support ambulatory EHR platforms. At the beginning, based on market share, Sansoro chose to focus on the Cerner and Epic EHRs, both of which offer limited web services modules to their customers. Then, listening to customer needs, Sansoro added MEDITECH and Allscripts; it will continue to follow customer priorities.

Although Orosco acknowledged that EHR vendors are already moving toward interoperability, their services are currently limited and focus on their own platforms. For various reasons, they may implement the FHIR specification differently. (Health IT experts hope that Argonaut project will ensure semantic interoperability for at least the most common FHIR items.) Sansoro, in contrast can expose any field in the EHR using its APIs, thus serving the health care community’s immediate needs in an EHR-agnostic manner. Emissary may prevent the field from ending up again the way the CCD has fared, where each vendor can implement a different API and claim to be compliant.

This kind of fragmented interface is a constant risk in markets in which proprietary companies are rapidly entering an competing. There is also a risk, therefore, that many competitors will enter the API market as Sansoro has done, reproducing the minor and annoying differences between EHR vendors at a higher level.

But Orosco reminded me that Google, Facebook, and Microsoft all have competing APIs for messaging, identity management, and other services. The benefits of competition, even when people have to use different interfaces, drives a field forward, and the same can happen in healthcare. Two directions face us: to allow rapid entry of multiple vendors and learn from experience, or to spend a long time trying to develop a robust standard in an open manner for all to use. Luckily, given Sansoro and FHIR, we have both options.

Prescription Benefits’ Information Silos Provide Feedstock for RxEOB

Posted on June 7, 2016 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

In health care, silos between industries prevent synergies like in the travel industry, where you can order your hotel, flight, rental car, and tourist sights all in one place. Interoperability–the Holy Grail of much health care policy, throughout the Meaningful Use and MACRA eras–is just one sliver of the information hoarding problem. There is much more to integrated care, and prescriptions illustrate the data exchange problems in spades. Pharmacist Robert Oscar recognized the business possibilities inherent in breaking through the walls, and formed RxEOB 15 years ago to address them.

RxEOB helps patients and their physicians make better decisions about medications, taking costs and other interests into account. Sold to health insurance plans and benefits managers, it’s an information management platform and a communication platform, viewing patients, health plans, physicians, pharmacists, and family members as team members.

It’s instructive to look at the various players in the prescription space, what data each gives to RxEOB, and what RxEOB provides to each in return.

Payers

These organizations have lots of data that’s useful in the RxEOB ecosystem: costs, formularies, and coverage information. What payers often lack is information such as price, benefit status, and tier for drugs “similar to” one that is being prescribed.

The “similar to” concept is central to the pharmaceutical field, from the decision made by drug companies to pursue research, through FDA approval (they want proof that a new medication is substantially better than ones it is similar to), to physician choices and payer coverage. There may be good reasons to prescribe a medication that costs more than ones to which it is similar: the patient may not be responding to other drugs, or may be suffering from debilitating side effects. Still, everyone should know what the alternatives are.

Physicians

One of RxEOB’s earliest services was simply to inform doctors about the details of the health care coverage their patients had. This is gradually becoming an industry function, but is still an issue. Nowadays, thanks to electronic health records, most physicians theoretically have access to all the information they need to prescribe thoughtfully. But the information they want may be buried in databases or unstructured documents, jumbled together with irrelevant details. RxEOB can extract and combine information on available drugs, formularies, authorization requirements, coverage information, and details such as patient drug histories to help the doctor make a quick, accurate decision.

Pharmacies

These can use RxEOB’s information on the benefits and cost coverage offered by health insurance for the patients they serve.

Benefits managers

These staff know a lot about patients’ benefits, which they provide to RxEOB. In return, RxEOB can help them set up portals and use text messaging or mobile apps to communicate to patients.

Consumers

Finally we come to the much-abused patients, who have the greatest stake in the whole system and are the least informed. The consumer would like to know everything that the rest of the system knows about pricing, alternatives, and coverage. And the consumer wants to know more: why they should take the drug in the first place, for instance, how to deal with side effects. RxEOB provides communication channels between the patient and all the other players. Thus, the company contributes to medication adherence.

RxEOB is a member of the National Council of Prescription Drug Programs (NCPDP) which works on standards for such things as prior authorizations and communications. Thus, while carving out a successful niche in a dysfunctional industry, it is helping to move the industry to a better place in data sharing.

More Patient Demand, More Communications

Posted on May 31, 2016 I Written By

The following is a guest blog post by Andy Nieto, IT Strategist for DataMotion Health.
Andy Nieto
Nearly every news outlet does an annual recap about what has changed over the past 12 months. In recent years, we’ve learned we are now more connected, more aware, traveling more, doing more and so on. The role of the local family doctor being the only caregiver has also changed, giving way to more specialists, more providers and more needs. A survey by GfK Roper showed Americans over 65 saw an average of 28 doctors – and that was five years ago. There are now 8,000 of us reaching age 65 every day. By 2029, the 65+ group will comprise more than 20 percent of the population.

This is just the tip of the iceberg. Healthcare is encountering numerous problems, fueled by an aging population. For the industry to adapt, move forward, and produce better health outcomes, one particular change is critical.

Problem One: More People Seeing More Doctors

A 2014 Journal of the American Medical Association article, “Finding the Missing Link for Big Biomedical Data” (jama.2014.4228), identified there are a tremendous number of data elements which affect a patient’s health, wellness, and ultimately, their outcomes from treatment.

There are two concurrent efforts underway to manage and control this data. The first was the HITECH Act and move to digitization, management and aggregation of patient data. This push for electronic health records (EHRs) has resulted in more than 3,000 certified healthcare technology products on the market. There are 900,000 active physicians, more than 5,700 hospitals, 60,000 pharmacies and 100,000 physical therapy entities. And this doesn’t include countless caregivers, ancillary staff, labs, etc.

That said, the volume of information is staggering and will only increase.

The second effort underway is to define care needs and create communities to effectively address these. The Health Information Management System Society (HIMSS) has created the Health Story Project in an effort to understand the scope of these needs. The Office of the National Coordinator for Health Information Technology (ONC) has patient rights and wellness acts. And virtually every insurance and health system has some type of health outreach management plan.

All of these communities are empowered by access to, and utilization of, information about the patients under their care. Most importantly, it is imperative that the “left hand understand what the right hand is doing” in order to treat patients more effectively and safely, control costs, create greater efficiencies and much more.

Problem Two: So Much Information in So Many Places
“Americans are sicker” is a blanket statement that the media now seems to report daily. Obesity, chronic conditions and increased costs for healthcare are constantly in the headlines. At least one report has stated that 45 percent of all Americans suffer from at least one chronic condition. What’s more, by 2025 one half of all Americans will suffer from chronic conditions.

For many businesses and industries, there’s long been an 80/20 rule where 80% of the cost was from 20% of materials, 80% of revenue from 20% of customers, etc.  For healthcare though, there are many who feel the situation with chronic care patients is much worse.

Of course, effective treatment means a need for more specialists, more providers and more information to handle those with such conditions. But that vital information is now in so many places.

Problem Three: The Communication Crisis
When I was growing up, my mother always told me to “use my words” to address conflict. Unfortunately, our healthcare crisis has an even larger and more fundamental conflict – a lack of communication. How do we deal with any of these problems if we cannot communicate?

Communication in healthcare is a multi-pronged issue. Information must be exchanged. Care, providers, resources and schedules must be coordinated. Amidst this, we cannot forget the patient, and that today as a country we are less healthy and demands have increased.

One study found patients with chronic conditions as a result of poor lifestyle choices, obesity for example, are significantly less likely to be compliant with treatment plans. The fact is, patients that have regular and interactive communication with their providers are significantly more likely to be compliant with care plans and demonstrate better outcomes.

Communication, including feedback with the patient, is critical to addressing patient compliance

A Single Solution
Communication is the foundation of coordinating the volume of care providers, specialists and services needed to address patient health, wellness and outcomes. HIPAA, HITECH, Omnibus rulings, as well as the ongoing work of the ONC and HIMSS, all support interoperability and connected healthcare. Opening the lines of communication is the first step, though with this progress, the problem of data becomes clear.

Communication exists in many forms. Healthcare is both a science of medicine and an art of care, which means various types of information must be exchanged. To achieve the “holy grail” of interoperability, obstacles for clinical information exchange must be removed. Barriers around data types and formats are a blockade to progress. Conversation, consultation, planning and discussion are as critical to the delivery of care as discrete and diagnostic data elements. Therefore, messaging must be used that is open and empowered to ALL types of data – from structured digital data to images and unstructured documents – and security is obviously imperative.

Simple communication is a conversation between providers. So, why is it, then, that many “so called” clinical messaging solutions do not support the simple process of person-to-person dialogue? A communications solution must support both “science and art.” Care coordination, facilitating provider-to-provider and provider-to-patient interaction removes barriers, simplifies and improves care delivery, and by extension, improves health and wellness.

With this in mind, the themes of “more” must be extended to healthcare to move forward. And that means more communication, more coordination and more care.

About Andy Nieto
Andy Nieto is the IT Strategist for DataMotion Health, a provider of secure health information delivery services and solutions. An accredited HISP (health information service provider) of Direct Secure Messaging, the DataMotion Direct service enables efficient interoperability and sharing of a person’s data across the continuum of care and their broader lives. For more information, please visit http://www.datamotionhealth.com.

Healthcare Data Standards Tweetstorm from Arien Malec

Posted on May 20, 2016 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

If you don’t follow Arien Malec on Twitter, you should. He’s got strong opinions and an inside perspective on the real challenges associated with healthcare data interoperability.

As proof, check out the following Healthcare Standards tweetstorm he posted (removed from the tweet for easy reading):

1/ Reminder: #MU & CEHRT include standards for terminology, content, security & transport. Covers eRx, lab, Transitions of Care.

2/ If you think we “don’t have interop” b/c no standards name, wrong.

3/ Standards could be ineffective, may be wrong, may not be implemented in practice, or other elts. missing

4/ But these are *different* problems from “gov’t didn’t name standards” & fixes are different too.

5/ e.g., “providers don’t want 60p CCDA documents” – data should be structured & incorporated.

6/ #actually both (structured data w/terminology & incorporate) are required by MU/certification.

7/ “but they don’t work” — OK, why? & what’s the fix?

8/ “Government should have invested in making the standards better”

9/ #actually did. NLM invested in terminology. @ONC_HealthIT invested in CCDA & LRU projects w/ @HL7, etc.

10/ “government shouldn’t have named standards unless they were known to work” — would have led to 0 named

11/ None of this is to say we don’t have silos, impediments to #interoperability, etc.

12/ but you can’t fix the problem unless you understand it first.

13/ & “gov’t didn’t name standards” isn’t the problem.

14/ So describe the problems, let’s work on fixing them, & abandon magical thinking & 🦄. The End.

Here was my immediate response to the tweetstorm:

I agree with much of what Arien says about their being standards and the government named the standards. That isn’t the reason that exchange of health information isn’t happening. As he says in his 3rd tweet above, the standards might not be effective, they may be implemented poorly, the standards might be missing elements, etc etc etc. However, you can’t say there wasn’t a standard and that the government didn’t choose a standard.

Can we just all be honest with ourselves and admit that many people in healthcare don’t want health data to be shared? If they did, we’d have solved this problem.

The good news is that there are some signs that this is changing. However, changing someone from not wanting to share data is a hard thing and usually happens in steps. You don’t just over night have a company or individual change their culture to one of open data sharing.