Wes Rishel
VP Distinguished Analyst
12 years at Gartner
45 years IT industry
Wes Rishel is a vice president and distinguished analyst in Gartner's healthcare provider research practice. He covers electronic medical records, interoperability, health information exchanges and the underlying technologies of healthcare IT, including application integration and standards. Read Full Bio
by Wes Rishel | November 17, 2011 | Comments Off
Are you tired of government not listening? Here is your chance to set the record straight on the NwHIN. You don’t have to live in a tent or pound a drum. You can sit comfy in a chair and pound a keyboard.
During the summer and fall, an ad hoc work group of the HIT Standards Committee analyzed some of the specifications used in developing the first implementation of the Nationwide Health Information Network (NwHIN). During that work, it became apparent that there was a reservoir of experience available on using the specs. After all, the participants in the NwHIN include Centers for Disease Control and Prevention, Community Health Information Collaborative (Minn), Department of Defense, Douglas County (OR) Individual Practice, HealthBridge, Inland Northwest Health, Kaiser Permanente, Marshfiled Clinic (Wisc), MedVirgina, MulitCare Health System (WA), NCHICA, Oregon Community Health, Regenstrief (IHIE), Social Security Agency, South Carolina Health Information Exchange, Southeast Michigan Health Information Exchange, Utah Health Information Network, Veteran’s Health Administration and Western New York Clinical Information Exchange (HealtheLink).
Not everyone was invited to testify and not everyone that was invited was available on short notice. Public comments during the HIT SC meetings made it clear that some people felt that the public record was inadequate.
Most processes that advise the government are controlled under regulations that were developed in the era of the Selectric typewriter. They require months to schedule an extra meeting or announce a request for comments. Fortunately the Obama administration has pioneered the use of blogs as a low overhead means of enabling open and transparent public comment. Accordingly we on the HIT Standards Committee requested an entry on the ONC Federal Advisory Committee Blog, requesting further input. HITSC Seeks Comments on Exchange Specifications by December 15, 2011 was created on Nov 9, with the hope that people who participated in the NwHIN efforts would publicly comment.
So far, comments have been light and added no information on the topic at hand.
Come on, folks. Be a movement. Occupy the Internet. Give us the facts. Answering the questions posted there describing your experience implementing the specs.
Thanks!
Modified 17 Nov at 22:40 US Eastern time: nonsubstantive, factual change.
Category: Uncategorized Tags: Healthcare Interoperability, NHIN, NwHIN, ONC
by Wes Rishel | September 26, 2011 | Comments Off
Recently I have been peer-reviewing my colleagues’ presentations for Gartner Symposium 2011. Those of you who have attended know that it mostly dedicated to IT in general, attended by roughly 10,000 CIOs and their direct reports across all industries and government. Sunday October 16 in Orlando we are doing a track specifically for healthcare providers and payers.
I will be speaking on the readiness of HIE vendors to support HIE, particularly care coordination and analytics. This is a kind of HIE where the value proposition is clear. It will be fun watching as the vendors estimate the important features and move their products from PPTware to paper mache and from there to solid brickwork.
It is interesting to note that the yin-yang of “best of breed” vs. enterprise products gets played out in one market after another. The race is all but over in electronic health records and pretty far along for payer transaction systems. My colleague, Joanne Galimi, will use survey data to position this issue for payer business intelligence systems. Hint: it’s still wide open.
When I had surgery in 2004 every nurse and resident at Stanford carried a BlackBerry, so I was astounded seven years later to read the presentation of Barry Runyon. He finds that only a few hospitals have traded their pagers in wholesale for smart phones. When will our devices support our hopes of improving our care processes? Barry will triage roles vs device requirements, but it is clear that clinicians must have a single device for codes, calls, alerts and collaboration.
For those of you attending be sure to sign up for 1-on-1 sessions with me and your other analysts on the Web before arriving. Many of us are totally booked up before day 1.
Category: Healthcare Providers Interoperability Vertical Industries Tags: analytics, business intelligence, EHR, Health Information Exchange, health plans, Healthcare Interoperability, Healthcare Providers
by Wes Rishel | September 11, 2011 | 2 Comments
Some involved in the search for an Entity Level Provider Directory are advocating for an approach that relies on search engines like Google and Bing and a modest approach to standardizing data using microdata while others are arguing for a more structured and rigorous approach based on a highly federated use of LDAP.
The federal policy version of “who will bell the cat” is “who will fund the service.” The LDAP approach assumes that some larger number of LDAP service providers can make a business out of gathering, auditing and maintaining identity data or that the government dole for HIE will continue unabated. This approach assumes we can pay enough to drag this information out of practices even though we have heard testimony that docs are notoriously reluctant to provide one additional datum about themselves over and above what is necessary to be licensed and credentialed.
The other approach puts the onus on practices to create their own identity information, either directly or with help from their health information service provider, electronic health record vendor, affiliated ACO, or professional society. The payment for the rather nominal requirement to create a web page comes from the practice, although it is likely buried in fees they pay practice management of other IT services. Likely sources of the Web page support include for health information service providers (HISPs), EHR and HIE vendors that incorporate a consumer-facing portal into their products, medical professional organizations, and IPAs.
A microcosm of this “big system” vs “individual” approach can be found in our ongoing discussion on how to represent the practice areas on such Web sites. There are two lists available, the provider taxonomy constructed her HIPAA and a federated list maintained by specialty organizations and coordinated by the A.M.A. Both are designed to support the arcane distinctions necessary for billing or accreditation. We are not aware that either has a consumer-friendly semantic mapping.
To achieve semantic interoperability and consumer-friendliness we need two things.
- a “golden” taxonomy — one or the other, available free
- a free semantic mapping from golden terms to consumer-friendly terms — and free updating. “Government-paid” would counts as free.
However, I question whether semantic interoperability is a requirement here. If we follow a consumer search engine approach to ELPD, why not let the practices describe their specialties however they like, as they do now? We might define a data item that contains free text and is semantically described as “consumer-friendly declared practice area (free text, repeated items separated by commas).”
This advice will be better from some source than from others. The sources will compete in the marketplace in terms of overall effectiveness of practice Web pages including but not limited to proper identification of specialty areas. Some might even collaborate to establish and maintain a common list of consumer-friendly terms likely to be effective in consumer-entered searches. Other entrepreneurs might spider through web sites and build up more sophisticated and effective search products.
Some practices might inadvertently or slyly cheat by self-describing practice areas for which they are not licensed or competent. This is not desirable but there are many other methods of regulating the actual provision of care; we do not need to build that into the burden we pay to begin to use Direct more widely.
The whole point of keeping it simple is to get a useful dollop of work done, put it into action and see how economics and innovation shapes the next step.
If we keep it simple we could get this dollop done in a year. If we entangle it in state-by-state programs to mount (and inter-federate) LDAP servers who knows how long it might take, and whether the services will be economically sustainable?
Category: Healthcare Providers Interoperability Tags: Direct Project, EHR, Health Information Exchange, Health IT, Healthcare Providers, NHIN Direct
by Wes Rishel | August 16, 2011 | 4 Comments
Graham Grieve, a major participant in HL7 standards writes HL7 needs a fresh look because V3 has failed.
I agree with much of what he says, in particular his distinction between clinical interop and semantic interop. I take it to mean that the level of rigor required for getting to working clinical interop is less than full semantic interop and more likely to be handled with feasible modifications to existing products.
[BTW, a big +1 to Graham for his blog name: Health Intersections. It really captures the nature of interoperability as interfaces at the intersection of different systems, businesses and medical and IT cultures. This is the POV that leads to the distinction between clinical interop and semantic interop.]
I also agree with some commenters that V3 Is Not a “Total Failure.” The RIM is a basic contribution to healthcare modeling that for the first time captured the role of “role” in relating administrative and clinical data. It’s use of “mood” to capture the alignment of and differences among clinical data throughout the workflow of healthcare was equally brilliant. It is a shame that the developers chose to describe that discovery in terms that played well in academic circles and added barriers to sharing the knowledge with the 95% of IT folks that do the real work. This same pursuit of the perfect abstraction extended into the data types, adding to general difficulty in getting acceptance of V3 artifacts.
V3 Messaging is close enough to having had zero impact as to not merit further discussion. Some RIM-based artifacts, however, such as the CCD and other documents in the CDA family have achieved centers of use and are at least at the level of “it’s better to use these than to start over.” (That may not sound like much but it is exactly the level of success that HL7 V2 enjoys.)
It’s interesting to explore why CDA has fared better than V3 messaging. Here are some factors to consider:
Fighting a Different War. V3 messaging was the classic case of the generals fighting the last war. CDA explored new territory and looked at interfaces in a manner that was well-understood by clinicians (signed documents). It thereby received support from a class of pragmatists who would not invest a lot of time in improving interfaces that were working “well enough.”
Detachment from the Communication Paradigm. CDA documents are all about content. They are not tied to how (or even whether) they get transported.
Less Top-Downedness. Because a great deal of CDA development was focused on specific use cases it was sometimes possible to hide the complexities of the RIM in stuff the clinicians and other business experts were willing to accept as “the XML gibberish.”
Implementation Guides. The nature of CDA permitted focus on fairly narrow use cases. This led to the development of implementation guides that allowed implementers to figure out what to plug in among the XML gibberish in order to communicate. Not ideal but able to make headway for those that are fighting a new war.
Less Bad SNOMED Juju. In the U.S., CAP was seen as interested in financially exploiting its the intellectual property in SNOMED and deeply suspected within parts of the AMIA community. In some other countries SNOMED was seen as a US-only product. HL7 was driven by folks on the side that was suspicious of, if not outright hostile to, SNOMED. As a result most of us in HL7 ignored the intricate nature of the relationship between codes and information structures on the theory that codes were a separate problem. Although SNOMED CT still has many issues, the formation and behavior of IHTSDO has led to the widespread view that it is better to work with IHTDSDO to improve SNOMED than to start again.
[I am honestly not clear on why the CDA group had less hostility to SNOMED. Perhaps it was because it formed later in the history of HL7 and brought in new blood; perhaps it was because it was more focused on specific use cases it had a more utilitarian view. It is also possible I am imagining that there was a difference. The important point is that a "fresh look" in HL7 has to purge HL7 of residual resentment of SNOMED and include cooperation with IHTSDO as a base part of its methodology.]
Applying the Lessons
I am not arguing that CDA was a raging success; I see growing adoption of implementation guides that include CDA documents but the pace of adoption since CDA R2 became a standard does not justify a view that CDA represents a perfect solution to the overall problems in the HL7 V3 series of standards. Nonetheless it is important that the fresh look be fighting the right war, detached from the communication paradigm, less top-down, have tool-based support for the rapid development of implementation guides and squarely aligned with IHTSDO.
What’s in a Word?
Several of the commenters on Graham’s post implied that declaring V3 a failure has negative political consequences. This can be true. Backing for national level programs in their countries may not transfer to the fresh look if they have to acknowledge that what they were backing failed. These are the realities we face working in a world where spending decisions are made by agencies with wide scope and little depth. However, the countervailing concern is that some more comfortable political formulation might leads diehards within HL7 to believe that all that is needed is to tweak version 3. Should that view prevail, the relevance of HL7 will substantially decline.
Category: Healthcare Providers Interoperability Tags: EHR, Health 2.0, Health Information Exchange, Health IT, Healthcare Interoperability, Healthcare Providers, HL7 Fresh Look, simple interop
by Wes Rishel | July 26, 2011 | 2 Comments
I am very proud of the responses to my Send the Questions to the Data. They were thoughtful and fact-based contributions to the discussion.
Of course, the post was prompted by the buzz that ONC has been generating on this topic. The next shoe has dropped in Rich Elmore’s post Distributed Population Queries – A National Priority. It is equally significant to note that Rich has taken a leave of absence from AllScripts and is carrying an ONC business card while he works on this. In this post Rich announced the “summer concert series,” apparently an environmental scan designed to bring a common information base to interested parties.
This beast is obviously not a biped; Rich also announced that a third shoe will drop in September with the formation of Query Health under the S&I Framework. It is significant that Rich was a key player in the Direct Project, at the time a unique combination of a small investment in government time and money with a lot of volunteer work, organized by principles that have been successful in open source communities. These include
- all activities are open anyone can observe and follow through a public wiki
- those that are committed to implementations get to speak and influence the decisions
- rough consensus, running code, final specification
- a lack of formalized governance rules.
Query Health is different than the Direct Project in that it will be handled under the I&S Framework.
Although I hear the monthly briefings on the Framework I confess to being confused exactly what it is. It is easy to understand the projects that lead directly to meaningful use regulations but Query Health deals with an important scenario that may not find immediately available standard that have widespread use.
Maybe ONC wants a way to launch multiple projects with the representative participation, innovation and group dynamics of The Direct Project and yet still have a way to ensure that the purpose and work products of the individual products are well coordinated.
The twin goals of achieving spontaneity and innovation while achieving government-level coordination seem like an oxymoron. Rich will have his hands full. On the other hand, he is an able consensus builder with a great software background, and ONC has walked the tightrope between innovation and the government regulatory apparatus better than any other government interop agency that I have ever seen.
I look forward to seeing the “fourth shoe drop” when the Query Health begins running with live patient data sometime soon.
Category: Interoperability Vertical Industries Tags: Direct Project, Health Information Exchange, Healthcare Interoperability, Healthcare Providers, HIE, Meaningful Use, PCAST Report, Query Health
by Wes Rishel | July 17, 2011 | 3 Comments
Discussion flowing from Redwood MedNet on Friday. Rumor that ICD-11 is either going to be replaced by a version of SNOMED or going to be incorporated into a future version of SNOMED. Possible impllication: the US should wait for ICD-11 because coding will be so much easier then.
I don’t buy the implication at all, for two reasons. We can’t continue to limp along on ICD-9 until ICD-11 is fully cooked and goes through the processes that enabled ICD-10, such as adoption in other countries.
My other concern is the fundamental difference between a classification system and a concept enumeration. Classification systems are designed to always be able to express an answer (perhaps better, perhaps worse.) The question might be “what did this patient die of, what was the regional distribution of various kinds of lung cancer” or “given the problems and course of treatment, under which of the clauses in our contract or regulation do you want to be paid?”
In order to ensure that the question can always be answered, classification systems include “not otherwise specified” (NOS) categories to catch the loose ends. When too many diverse loose ends are lumped together in the same NOS category, the answers to the questions become less discriminating and conclusions (or payments) derived from them more random or subject to “optimization” by plausible choices among loosely defined categories.
For keepers of systems of concepts “not otherwise specified” is anathema. As soon as you add a concept that was previously included in NOS, the definition of NOS has changed and you can’t compare data across encoded at different times. They prefer not to add concepts until the medical version of the Council of Elders has convened to determine where the new concept fits in the ontology and how it maps to other concepts. This is very important for research and advanced applications such as clinical decision support based on coded data.
What might the rumor mean?
One interpretation of the rumor might be “just send the data (in SNOMED concepts) and let the receiver decide on the classification. This is like when I ask my wife “what color do you want the bathroom” and she says “well powder blue goes better with the tiles but aqua goes better with the towels.” I got a bunch of data but woe be onto me if I were to use it to take responsibility for picking the paint. This shifting of roles is unlikely to be acceptable any time soon.
Another interpretation might be that IHTSDO would map any given version of SNOMED to a specific version of ICD-11 and distribute ICD-11 along with SNOMED. Careful attention to the exact version of ICD-11 that was in use could permit using the SNOMED ontologies to manipulate data expressed in ICD-11. That would be a valuable addition to medical informatics and has some benefits in terms of funding translation of both code sets into various languages.
I think the latter interpretation sounds feasible. It still wouldn’t justify holding on to that collection of big, vague buckets called ICD-9 for another 3-5 years.
Category: Healthcare Providers Tags: ICD-10, ICD-11, ICD-9, SNOMED
by Wes Rishel | July 17, 2011 | 3 Comments
Mark Frisse started an interesting thread on Google+ today based on Assessing the Effect of Standards in Digital Health Records on Innovation by Steve Lohr. He chose not to make it public so I can’t cite it directly here.
I now face the typical Google-plusser dilemma. I want to add to the thread but I also want my thought to be public. So I am posting the blog entry and will cite it there.
There is not yet enough science to determine the one right way to do user interfaces. I doubt that there is enough science to objectively conclude trade-offs between, for example, being able to see everything at once that is on a printed cover sheet vs. using smaller or less costly devices. (It would be easy to see a standard based solely on usability principles proscribing any devices other than wall-mounted HD screens with special glasses needed to prohibit accidental viewing by non-authorized people.) I *AM NOT* making light of usability principles; I am simply pointing out that they represent one set of factors in a trade-off in selecting an EHR.
If we do have some science now, it should go into lifting the veil of obscurity that vendors place around their usability.
USABILITY MEASURES
I propose the notion of a “usability measure.” Like a “quality measure” it would be specific and might have specific exclusions. In order to be a “measurable measure” it could not usually be generic to the entire EHR. While “all references to a patient should include gender, age and unit number” might well be a good principle, the measure for this principle might enumerate four or five situations where the patient information is displayed such as patient selection, results lists, individual results viewing, ordering and documentation and NIST criteria would include scripts for determining yes-no answers in those situations.
Experience with clinical measures has shown that going from generally agreed-on principles to computable measures is a substantial investment of time.
A public dialogue with minority representation from the vendor community should review proposed measures and categorize them into these groups:
1) So obvious it would be unethical not require this of all EHRs. The criteria for inclusion in this group should be very high.
2) Likely to be important factors; submission to the measure should be required for EHR certification and the average across all submissions be published. If a certified product is purchased by a health delivery organization and the vendor failed to provide its own scores before the HDO was committed to the product, that HDO should be ineligible for receiving the benefit of meaningful use incentives (bonuses now, relief from penalties in the future).
3) Candidate measures; submission to the measure should be required for EHR certification but there is no requirement for EHR vendors to provide their scores. Anonymous scores would be published so that healthcare industry could see the spread of how products performed on the measure.
4) Worthy of further study; the measures should be published as fodder for study, no scripts are prepared and testing does not occur as a part of certification.
OTHER REGULATORY ACTIONS
Given threats to patient safety based on usability, any EHR that is purchased under a contract that includes a “usability gag clause” should be ineligible to benefit under the incentive program. Such a clause would penalize the client for speaking publicly about the usability of the product. Vendors have justifiable concerns about a minority of irresponsible who will make up or exaggerate such issues in order to put pressure on the vendor on some unrelated point. They also have justifiable concerns about “Internet warriors” who take every public dialogue as a no-holds-barred battle for attention and dominance. Nonetheless, the greater good for healthcare and patients is achieved by favoring transparency. All of us are Internet users and we are learning to glean the gems from the crud.
Category: Healthcare Providers Tags: ARRA, EHR, usability
by Wes Rishel | July 7, 2011 | 10 Comments
One of the insights of the PCAST report was the utility of sending the question to the data vs centralizing the data to answer questions. It may take a long time to achieve this by defining a new universal data language and using digital content management to manage consumer privacy preferences, but what happens if we uncouple that the basic “question to the data” notion from the more elaborate vision of the Report?
The utility to public health and some kinds of research could be substantial and it may be possible to get started with an intense, voluntary effort similar to The Direct Project.
Public health covers a lot of territory. Some concepts for gathering data are enshrined in law and regulation and, therefore, are stable. “Reportable diseases” are typically enumerated and it is conceivable to build filters into lab systems to “send the data to the question (asker).”
But what of the requirements for situational awareness during an epidemic. Would public health officials want to ask about presenting symptoms, ED diagnoses, lab or micro results, pathological findings? As their understanding of the disease process grows how often would they want to change their inquiries to add data or refine the selection criteria? Pretty darn frequently, I’d wager.
How might it work?
In general, the sources of clinical data (EHRs, stand-alone labs, ePrescribing networks, etc.) would “sign up” to receive queries from requesters such as public health departments, researchers or other carefully identified requestors of information. It is critical that the identity of both ends of the transaction are established mutually authenticated each time data is transmitted. It seems that the security about the institutional asker’s of questions may require a higher assurance level.
Once a relationship has been established the sources of data might receive requests for data from time to time such as “tell me about encounters you have had with high fevers and vomiting as a ratio to the total number of encounters you have had for the same period.” The request would also include (or imply) information on where to send the data and how to associate it with a specific request.”
Requesting aggregates rather than individual data is a two-edge sword. On the one hand, it avoids policy issues around sending individual health information. On the other hand there is no way for the recipient to weed out duplicates from multiple sources so the statistical inaccuracy will rule out fine-grained measurements. Furthermore, because the statistics are generated at the source fine-grained pattern discovery based on sophisticated analyses of millions of records does not seem possible. This is an area where the perfect should not be an effective enemy of the good. Any pragmatic scheme to get even crude data into the hands of public health officials is better than a more precise scheme that would take years to get going.
In the un-PCAST world that we occupy today, it is unlikely that the data-source organizations would respond automatically. Some officer of the organization will likely approve each individual request. However, it would be ideal if that officer didn’t have to schedule the time of a programmer to determine if the request is feasible and, if so, code it up. In other words, it would be ideal if fulfilling the request was automatic and there was a workflow for the officer of the source organization to know about requests, and decide whether to authorize the release.
“Same old stuff” or a new day?
We all know the reasons that this can’t work. The policy issues are difficult but the biggest issue is that EHRs and other clinical data systems have different internal data schemas, so it is hard to frame a request and know that it is compatible with source systems and it is hard to fulfill the request without custom programming.
As that legendary scientist and explorer, Jean-Luc Picard, once said, “things are only impossible until they’re not.” It’s time to decide if we are approaching a cusp of possibility with regard to this issue. We have new resources (more EHRS, a fundamental secure communications infrastructure and standard coding systems in support of meaningful use requirements).
It is time to assemble a group of users and vendors willing to look at this issue intensely, follow the principles of building on available standards and, if pragmatic solutions exist, support them with an approach similar to the Direct Project, which is, “rough consensus, open source code implementations, final specifications.”
Category: Healthcare Providers Interoperability Vertical Industries Tags: Direct Project, distributed query, EHR, Health Information Exchange, Healthcare Interoperability, Healthcare Providers, open source, PCAST Report, public health
by Wes Rishel | May 31, 2011 | 1 Comment
A shoe has dropped.
The HITECH act requires separate rules for accounting for disclosure under HIPAA when the disclosures are made from an EHR. The notice of proposed rule making (NPRM) is now on public display. It will appear in the Federal Register this week. The 60 day comment period closes approximately Aug 1. Enforcement will begin 8 months after the issuance of the final rule. The final rule could be issued as early as Sept 2011 but may be delayed substantially longer.
It removes certain exemptions on accounting for disclosure if the disclosure occurred through an EHR.
Definition of EHR
The NPRM quotes the following from the HITECH act:
Section 13400 of the HITECH Act defines an electronic health record (“EHR”) as “an electronic record of health-related information on an individual that is created, gathered, managed, and consulted by authorized health care clinicians and staff.” Under section 13405(c), an individual has a right to receive an accounting of such disclosures made during the three years prior to the request.
One gets the sense that the Office of Civil Rights (OCR), which develops rules for HIPAA, believes that certified EHR technology provides a control-point where all outgoing electronic information from a hospital or practice can be logged for reporting on disclosures. This ideal is rarely true. Most hospitals have a dozen or more departmental systems from specialized vendors that are not routinely certified as modules of an EHR under the HITECH rules. Frequently the specialized systems are highly integrated with special imaging hardware for specific procedures such as endoscopy or spirometry.
In the era of meaningful use and ICD-10 it might be worthwhile to catalog the vendor products that are likely to require upgrades or special new integration in order to meet the new accounting requirements. Then it would be helpful to provide estimates of the cost and staff expenditures required in comments to the NPRM.
Data is far more persuasive in NPRM comments than opinion.
In commenting, give special attention to the possible enforcement deadline, which could be as early as 1 June 2012.
Category: Healthcare Providers Tags: ARRA, EHR, HIPAA
by Wes Rishel | May 27, 2011 | 5 Comments
Last year I blogged intensively in support of a notion of “simple interop.” The blogs were instrumental in the formation of The Direct Project. Direct provides light-weight security for sending protected health information. The simplicity derives from relying on the fundamental infrastructure of the Internet for routing and security. A provider that is a direct user can send information to any other direct user if it knows the “direct address” of that user, essentially an email-address. In a “simplicity first” approach, we chose not to fold a provider directory into the original product. Since most healthcare is local and most providers have ongoing business relationships with those who will receive the data, we expected that the overhead for learning a new email address and storing it in an address book or EHR table was no higher than keeping track of a fax number. We referred to this as “business-card” discovery of end-point addresses.
Real usage started about ten months after the project started and continues to grow. The next step is providing more widespread discovery of end-point addresses (a 411 service). The ONC S&I framework team has kicked off an intense effort to find a solution that could be included in an NPRM for Stage 2 of Meaningful Use. As with the original Direct project, the hope is to bust through previous expectations of how long something like that would take by “keeping it simple.” One of the complexities one hopes to avoid is creating a single national resource for looking up providers. While that is a valuable goal it is very complex and potentially expensive. One approach is to allow multiple sources (such as the states) to each offer a resource and develop a standards scheme to “confederate” them so that one wouldn’t have to query many different services each with its own user interface.
A Modest Proposal
I have been talking about this with David McCallie, my co-conspirator in the original push for simple interop. We have been looking for a truly fresh approach. We have a modest proposal here. Like the original simple interop approach, this proposal leverages the strengths of the infrastructure that is already in place in support of many non-healthcare usage. It provides for confederation and a uniform user interface in a novel way.
Requirements
On 24 May in A Strawman HIE Directory Solution John Halamka bloggedset forth the longer-term business requirements suggested by the work of the HIT Policy Committee. I am going to restate them in my own language in part to avoid the use of the word “discover.” This word seems to be adding confusion to the email thread that followed his publication.
- Support directed exchanges (send/receive as well as query/retrieve)
- Provide basic searching to find an organization – including demographic information and Direct address. Demographic information may be part of the search criteria or may be returned when a target is found.
- Having found an organization support retrieving information about exchange services (e.g., lab orders or results reports) and the standards required by the receiving system (e.g., mail, CCD, HL7 2.xx)
- Having found an organization support retrieving its security information (that is, it’s digital certificate).
The last requirement is a bit controversial. I’ll get that below.
To these stated goals I would add:
- Provide a reasonable assurance that the information that is found is not bogus.
The Proposal
Anyone can put up a Web page that describes his or her practice. (For reasons explained below small providers will probably rely on their HISP.)
The web page is free-form but contains mircroformat information that identifies various demographics, license level (self-declared), Direct Address and perhaps public cert. (Presumably ONC has the clout to get at least Google and Microsoft/Bing to agree on the Microformats.)
The web page must be protected by an Extended Validation Certificate such as is used for Webtrust. (The HISP can spread the cost of this over numerous small providers.)
The web page is freely available which makes it available to major search engines.
Organizational entities can put as many end-point entities as they want on the web page. (People, systems, common receiving queues, etc.) Or they can use one page per entity. There are no rules other than the use of a specific microformat.
Any person can use a search engine to discover a provider’s direct address and the provider’s public cert.
Presumably various folks would develop free-plugins for browsers that would indicate valid or invalid pages according to the extended validation certificates.
Given a definitive search key, such as a direct address, a HISP can discover the digital certification of a provider. It can validate the source of the information by the extended validation certificate. (It is questionable whether this is necessary, as will be discussed below.)
“Happy Paths”
Low-tech healthcare providers can use Web searches to discover the direct address of providers with reasonable assurance that the provider has managed to convince a HISP of its validity. Existing microformat-based integration with address books seems plausible.
HISPs may compete to improve the workflow for low-tech providers but there is no need for standardization in this area.
EHR-based healthcare providers have access to the low-tech approach, copying and pasting direct-addresses into the EHR equivalent of an address-book. If individual EHR vendors want to improve the workflows they have access to the APIs of the search engines and browsers to build whatever workflow they want. There is no need for standardization in this area as long as it is possible to paste a direct address into an EHR screen for a newly identified provider.
“Unhappy Paths”
In theory anyone can put up a web page with an email address and a digital cert. The extended validation certificate makes this an expensive proposition, but certainly within the budget of an organization that has set out to capture and sell protected health information. This concern can be addressed if there are requirements on the digital certificates that assure that they were issued by a trustworthy organization. The current HIT Standards Committee recommendation is that all certificates be traceable to a certificate authority that is cross-certified with the Federal PKI bridge. Under this or a similar approach, the HISP would refuse to forward Direct traffic to the bogus address because it would not have a qualifying certificate.
Spammers would have easy access to all direct addresses. As above, though, a spammer would only be able to use the direct address if it had its own qualifying digital certificate. Such a certificate could easily be revoked in the light of obvious spam.
Consumers would be confused finding email addresses to which they could not send mail. This can be solved by using a microformat that does not require that the direct address be rendered with the HTML page.
Advantages of This Approach
“Federation” is automatic through search engine technology.
Responsibility for creating listings lies with the provider or the provider’s HISP.
Modest investment and minimal development for HISPs. Virtually no investment required for EHR developers.
Does not require a a top-level domain which, IMHO, would take 1-2 years to get set up if there is serious credentialing associated with the issuance of TLD locations.
Except for some minor microformat work this relies entirely on existing technology that has been deployed at scale. In fact it relies on using the current deployments; there is no need to fund and deploy major new services.
Easily describable for the NPRM.
Easily testable for ATBs (assuming there is something to test).
Future Considerations
ONC could sponsor the development of a simple ontology of types of end points and microformats for describing them. Presumably it would want to address the service offered (e.g., receive lab orders) and perhaps some expression of the incoming standards supported. The actual information would be posted on the Web page by the practice or HISP at their own peril if they get it wrong. However, this is the future (i.e., beyond the NPRM for Stage 2 MU).
At that point standards and certification for EHRs would involve validating that the putative destination for a transaction is valid and can receive a transaction with the purpose and in a format that the EHR can send.
EHRs could also be required to offer compatible targets for inbound transactions.
Filling in Some Details
If the reader is not familiar with microformats please read the link. They are incredibly simple rules for formatting information with a web page so that its content can be understood by programs that accept the HTML web page as data. Try looking up a few recipes that are referenced on the site or some addresses. You will realize how much your smart phones and search engines have been using this technique to make your Web life easier.
In any modern browser if you open up most bank Web sites (e.g., https://www.bankofamerica.com/) you will see a colored padlock that shows up in the browser’s address bar. This is a visible indicator of the extended value certification. While most people (including providers and their staff) don’t know what that means, it would be easy to make plug-ins available for common browser that provide highly visible flags of specious web pages. A specious web page would be one that included this microformat but wasn’t protected with an extended validation cert.
There is substantial controversy on whether the requirement to return a digital certificate is valid. The current Direct software gets this certificate through the Internet Domain Name System (DNS). The most widely used DNS software, the open source ‘bind’ package, supports the current Direct scheme. However the DNS product offered by Microsoft does not. The Hatfields and McCoys of the Direct world characterize Microsoft’s lack of support as being either an insurmountable stumbling block or of little consequence. The open source .NET implementation of Direct works fine because it relies on bind rather than the Microsoft DNS code. Whatever the conclusion of this issue, the main value of this approach is achieved whether digital certs are stashed in the microformat or retrieved through the DNS.
Amended 27 May 1230 EDT to correct a URL.
Category: Healthcare Providers Interoperability Tags: Direct Project, EHR, Health Information Exchange, Health Internet, Healthcare Interoperability, HIE, Meaningful Use, NHIN Direct, NwHIN
