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.

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.

The ARRA has put us closer to that position than I imagined was possible. Working backward, item (c) is to be achieved by various HITECH programs and the meaningful use incentives; and item (b), the  end-to-end responsibility is at the level of the ONC, not a subordinate  entity tasked with that purpose. Achieving (a) is the topic of this blog post.

ONC has managed to work miracles (when compared to the normal course of government work) to meet  Congressionally mandated deadlines for other programs, but specifyin standards required a more ad hoc approach. At the same time ONC (and particularly Doug Fridsma) have been working in the background to adapt an approach to (a) that has worked in the Department of Homeland Security. This is called the National Information Exchange Model.

Sidebar: to avoid adding wind to any Web-based firestorm here, I would like to say that there is no reason to believe that the program will be run by DHS, will force DHS developed standards on healthcare or well give DHS any legal or pragmatic access to an individual’s healthcare data other than what it already has. ONC is simply adopting and adaption parts of the DHS standard-developing methodology. Ideally the methodology comes with standards-developing tools to implement it.

The final contract for NIEM in healthcare was completed last Saturday. Doug gave a summary presentation at the HIT Standards Commitee meeting that included this slide:

NIEM Overview

These preparations have proceeded without the transparency that we have become accustomed to from ONC. As we begin to learn about the program I will be looking for the answers to these issues.

1. To what extent has the NIEM methodology and tool set had to adapt to the ginormous complexity of codes and value sets that is table stakes for the healthcare standards game?
2. Can the tools and methodology adapt to XML representations that were not created specifically for the purpose of representing standards under the toolset?
3. I can understand why ONC did not want to give a single contractor exclusive knowledge of and influence over the development of these standards. I can also understand why ONC did not want to use potentially vulnerable internal positions to fund the work. But I still have to wonder if using five contractors is a manegable proposition.
4. The program calls for trial implementations. This is good and similar to parts of the unusual approach being used in the NHIN direct program. However, what we really need is an active feedback loop that extends through early real-life implementations. It is hard to see how that level of feedback can be achieved in this approach … but I have been surprised before.

As of now this particular work is being met with a good deal of skepticism, including my own.

That being said, I have been impressed with many examples of innovation that have come from ONC.

In a time when red meat passes for a formal gown and “caterwaulablogging” is as routine as waving howdy, I pledge to express my concerns openly and with as little verbal plumage as I can muster, in hopes that I am contributing to the evolution of these ideas towards the vision I set out two years ago (and the evolution of my own views).

The question is how SMTP as the preferred transport mechanism reconciles with the EHR certification criterion (in the IFR) that requires certified EHRs to use either SOAP or REST for HIE (i.e., §170.202 Transport standards for exchanging electronic health information).

Just sign me “Puzzled in Peoria”

Dear P in P,

First, let’s be clear. I speak for no-one. What I am saying hear does not cite an official position of the ONC, it is not a consensus position of the NHINDirect org, and so on. I speak as an individual who is a self-avowed cheerleader for NHIN Direct.

The certification requirements do not limit healthcare organizations to using the standards on which software is certified. They really only say that if a healthcare delivery org buys or builds software and wants to get incentive money for meaningful use the software has to be capable of using the standard (i.e., pass certification tests).

For example, MU requires a provider to get 50% of the lab results in structured form. An HDO could meet the requirement by sending CDs by courier and still qualify for the MU incentive money, as long as they uses software that could have accepted data according to the certification requirements were it asked. Certainly all the people that currently receive data through sources that do customized links to their EHRs are not going to have to re-implement their interfaces in order to get MU incentive money.

Part of the positioning of NHIN Direct is that it is metaphorically a “try before you buy” opportunity. ONC is facilitating activities that produce specifications  they might choose later. The “buy” would happen, for example, if a stage 2 certification rule were to incorporate the actual specs developed by NHIN Direct. The “try” is what happens when NHINDirect participants put the interfaces in place and actually begin to use it. If the “try” shows rapid uptake, the “buy” is more likely to happen.

It is also important to keep in mind that NHIN Direct is not directly comparable to existing standards that are certified. It is designed to encompass cases of “clinician to clinician” (rather than “clinician’s EHR to clinician’s EHR” over email and “physician to patient” (via PHR). It is also designed to require less elaborate governance and less complex technology because it sidesteps many of the consent issues that encumber HIEs.

(signed) Abigail van Bureaucrat

Dear Abby,

The convergence proposal accepts SOAP and REST at the edge as inputs from the EHR, so the convergence proposal is completely consistent with the IFR as written.

(signed) Halamka from the Hub

Dear H from H,

OMG! How cool. Wish I’d thought of that.

BFF Ab van B’rat

Revised 26 June 2010

Wes – are you detecting a split between EMR vendors and HIE vendors? From where I sit, the HIE vendors should be fairly neutral about what gets picked, as long as there is a single standard and not multiple \standards\. It is fairly easy for HIE vendors to implement IHE/SOAP (most of us have done that already) and SMTP/REST.

I suspect that the real pushback might be coming from the EMR vendors, who have recently started adopting IHE based integration and from what I have seen, they are beginning to see incremental results from substantial efforts. Their fear may be that a change in fundamental standards (from SOAP to REST) may obviate their current investment and will instead require them to refocus on building to new specs. Their core competency is clinical EMR development, not interoperability and therefore this is an acquired taste at best.

Secondly, there is a concern in some corners that NHIN Direct sets too low a bar and as a result undermines the Meaningful Use effort and the REC funds that are supposed to foster broader and more meaningful EMR adoption. A \mailbox\ type solution that is built using NHIN Direct principles and without a roadmap to getting to the level 1 Meaningful Use criteria can dilute those efforts.

We are not certain about how to address that concern. I know that this issue came up at the Seattle face-to-face meeting, but didn’t seem to have been resolved to a level that can be messaged to the community as a whole.

Vendor Split
My observation is the opposite of the split you described. The participants that seem to derive a substantial portion of their revenue stream directly or indirectly from the state grants favor an approach that is as close as possible to protocols in NHIN Exchange. Two very big EHR vendors put their support squarely behind the simpler approach and two others, while hesitating to add to the polarization in the room, have worked actively behind the scenes to shape the simpler approach to be more palatable to a broader group.

Bar Too Low
It is inaccurate to describe the simpler approach as “mailbox only.” It would be better to describe the approach as “mailbox inclusive” and recognize that the advocates of the simpler approach argue for permitting structured data, passing NHIN Exchange metadata through NHIN Direct without requiring that every participant handle unencrypted personal health information, and includes an approach to dealing across participants that are at different levels in terms of their ability to deal with structured data.

My own recommendation in Simple Interop: The Payload has been to include both human readable and structured data to give receiving systems the most options. This table provides one summary of the alternatives. “Best possible” means that the receiving system uses whatever capabilities it has to interpret the document.  ”Full XDR” means payloads fully compliant with all relevant NHIN Exchange standards as to metadata and payload. “Not Full XDR” allows for a wider variety of payloads and, perhaps, not the metadata that is required in NHIN Exchange.

NHIN Exchange and NHIN Direct Side by Side

I suspect that there is no way to reconcile the two camps on the “Bar Too Low” issue. One side believes that the only thing that prevents chaos is a highly controlled approaches limited to participants who have implemented very specific protocols and operate according to a predetermined model of what health information interchange is. The other side believes that if you create a little bit of enablement that can be rolled out widely the market without the delays inherent in HIE governance will move towards immediate realization of real business value and discovery of easy incremental steps that will constitute disruptive innovation in the best sense of the phrase.

Writing separately, Arien Malec (the NHIN coordinator) has characterized the split as between EHR vendors and others, rather than Sean’s big vs. small categorization. It is hard to tell the difference because only large EHR vendors have the resources to put into big group processes like NHIN Direct has become.

Sean and Arien are lumpers and I’m a splitter. If you look at the assumptions that are driving the participation I saw nine different points of view:

• A better way to make standards. The lesson taken from testimony at the HIT Standards Committee was that assembling a small group of players with a common vision, strong leadership and a plan for early implementation works better than the more ponderous “design by ballot box” approaches of large standards efforts. “Rough consensus and move to code; intermingle completing the consensus with writing code.” A consequence of this approach is that the work product will be judged later by whatever consensus process is necessary to adopt it as a standard; the work product is not preordained to get that far.
• Discard and start again: the EHR market is basically broken and needs to be replaced by products that great innovators could produce if they weren’t constrained by a regulatory process and standards process that is way too willing to embrace complexity. NHIN Direct must lay the groundwork for this.
• The Long View: the primary goal of NHIN Direct is to start a long term process of incremental architecture towards enabling the business innovation. Increment number one should be “messaging” across EHRs and non-EHR users, but that is only a start. The approach must enable future growth of the security infrastructure and the behaviors that can be enabled among participants that go way beyond simple delivery of messages.
• The RESTful Long View: everything that that long-view guy said plus a commitment to the ultimate architecture being RESTful.
• Top-downism the path for health information exchange has been set down by the grant program. Without such an organized approach attempts to interoperate are doomed to failure. NHIN Direct should be limited to those areas that can help the master plan succeed, but it should not create an alternative path to interoperability.
• Minimal Value: EHRs are at least adequate to meet the needs of improving healthcare. The basic problems of interoperability have been solved by IHE, the HIE grants and prior NHIN work. The only reason for NHIN Direct is to get hospitals connected to EHRs owned by community physicians faster than can be accomplished by standing up HIEs.
• Deadline Fatalism(1): the rules of the game are set by the ARRA; this effort is only useful if it allows are clients to more quickly achieve EHR-to-EHR communication in order to qualify for incentives earlier.
• Deadline Fatalism (2): like #1 but it also includes supporting hospitals in communicating with physicians who do not have EHRs that qualify for incentives. This will be important for transitions of care and potentially for meaningful use requirements in Stage 2 or Stage 3.
• There’s gotta be something better, sooner. The vision of nearly universal EHRs communicating through a ubiquitous set of HIEs that are interconnected via the NHIN too far in the future. These folks want to see something a little better than the fax machine as soon as possible. They will be happy if it helps compliance with meaningful use, but the requirement is much more basic and the impact more profound than simply helping to earn incentive money.

The size and diversity of the NHIN Direct is making it more difficult to hold to the “better way to make standards” view.  We have become a group of strange bedfellows where the strangeness is stronger than the fellowship.

The size of the group is partly a result of the attention it has received from ONC. Otherwise, we wouldn’t see the “top downists” and the “limited value” folks who basically believe that the main challenge is to execute on an established direction.  Many believe that the outcome of the NHIN Direct group is automatically destined to be a standard recognized in federal  regulations. ONC has said the opposite but they haven’t been heard or understood.

If those that don’t believe NHIN Direct is mission critical fall way, would any of the established EHR vendors continue to participate? If so, it would be because they fall into the “Deadline Fatalism (2)” or “There’s gotta be something better, sooner” categories.

To their credit the HIT vendors have come a long way in offering to adapt the IHE standards that are used in NHIN Exchange. They have offered a “pure push” approach. They have offered to remove any protected health information from the unencrypted portions of the messages available to HISPs.  The main sticking point seems to be whether the secure backbone protocol is SOAP, WS-* security, supported by the interface discovery capability in UDDI.

Unfortunately, the RESTful Web services movement was founded as a reaction against some of the assumptions inherent in the SOAP/WS-*/UDDI approach. RESTful Web services is a different approach for dealing with complexity. There is substantial justification for this but, but the basic notions of how to design  RESTful Web services is still evolving. The team working on NHIN Direct didn’t get beyond some very simple test code and didn’t demonstrate the deeper values of the RESTful  approach. I personally think those values can be achieved but this will take much longer than the REST advocates believe.

(This debate about RESTful vs traditional Web services sounds a bit like the Astronomy society deciding whether Pluto is a planet. But it is more like cosmologists arguing a theorem. The outcome can profoundly shape future directions.)

Frankly, there is not enough evidence in the world to put to bed the argument about whether the WS-* approach is good enough or better, or whether RESTful Web services  is the way to go. Absent evidence people will back their instincts and their instincts will be guided by their experience (they work they have already done), the amount that they will have to work to adopt a new approach and which of the nine points of view (above) they have.

If it goes to an approach of achieving decisions that are not consenuses (e.g., simply voting) then the process becomes one of which side can muster the most votes. One of the factors that shaped this effort was complaints about the HITSP experience wherein a number of participants felt steam-rollered by a few that they perceived to be an organized bloc with a particular agenda. I am not endorsing this view, just pointing out that thoughts like this are the inevitable outcome of a decision process that is not a true consensus process .

A Path Forward
I have rewritten this blog several times now. The trend has been from trying to find a path to reconciliation towards trying to have purposeful “disreconcilation.” Instead of having the group make a decision the decision is going to make the group.

The group must be reduced to a working size of folks can roll forward enthusiastically instead of feeling put upon because this is a diversion from their important work. So I would urge those who really think that NHIN Direct is unnecessary or unimportant to drop out. We can arrange for better communication beyond the group on what is going on than we have achieved so far, so those folks shouldn’t feel that they lose their insight into what is going on by dropping out. If you like what you see or find more industry acceptance than you imagine, we are doing everything we can to make it easy to get back in again later.

Among the members who do feel that the NHIN Direct idea is needed, we need to split into two or three groups. There still may be a substantial group that supports SOAP+UDDI for the backbone. If so, they should be a group with whatever governance they favor and their own process for getting to a working body of open source code and unfettered, comprehensible specifications. Perhaps IHE would like to host this effort since it so strongly builds on existing IHE work products.

Those that support “RESTful but maybe SMTP” or “SMTP but maybe RESTful” may become one or two groups according to whether they have enough appreciation of the combination of short-term and long-term views to have enthusiastic agreement. If this is one group it should favor an initial implementation using SMTP with a security infrastructure that will also support REST. It should look for another opportunity to use REST for a behavior that is different than pushing packaged messages around.

The deciding rule for forming groups should be to establish the minimum number of groups where the members of the group can work enthusiastically rather than feeling dragged along against their better judgment or when other work is more important.

With one or two smaller groups we can get back to proof by code rather than design by the ballot box.

This not ideal. Maybe all the groups will fail. Maybe they each will continue to split until there is no critical mass. Maybe they’ll all succeed and we’ll have “many standards to choose from.” Those would all be bad outcomes. But the current path is not tenable and the most likely path is that one of the two or three groups will be better able to prove their approach in the next few months and will end up with a strong enough case that others join in.

Isn’t that how the Internet was built?

(Last revision 13 June 2010 10:25 pm EDT)

This question gets to the heart of the confusion that some states or stated designated entities are experiencing with the introduction of NHIN Direct into the mix. I wrote this fellow back, outlining the relative value propositions of HIEs and NHIN Direct. It is clear that the two notions are complimentary even if there is still some need to work out the rough edges. Here is what I wrote.

The hospital that is evaluating its need to participate in a state HIE needs to answer the following questions.

How long will the hospital and community physicians be satisfied with the following assumptions that will probably be baked into NHIN Direct:

• We will be sending information but not offering clinicians the opportunity to look up a patient and retrieve their information.
• We will be sending the information to a practice without sending the practice’s patient ID number
• We will send out structured lab information from our lab using standard LOINC codes
• We will independently determine whether it is appropriate to send each transmission to a specific provider.
• We will send all information with only a very general usage agreement in place.
• We will accept inbound information without our patient ID so each such input will have to be matched by the receiver.
• We will accept information without assurance as to whether coded information is standard.

Most of the hospital CIOs that I talk to say, “I’d be happy to live with those restrictions in order to get started reaching out to physicians in my community sooner. I know that practices that I send info to would be willing to live with them as well.”

This is a fair trade-off. However, it provides clear limits in supporting care transitions in that the sender has to know to whom the patient is transitioning – or the receiver has to make a special request for information that must be manually approved by the sender.

Furthermore, it is unlikely that community physicians will remain satisfied with this approach if an HIE is available that supports both the hospital and the practice or if HIEs are linked in a way to provide the connection.

The value that HIEs typically add include

• Maintaining a common patient index
• Providing the trust mechanism, software interfaces. access control and consent mechanism that enables lookup up information
• Developing a common trust agreement that all parties can accept.
• An interface to consumer advocates that will assert their role protecting the interests of the patients.
• A common software channel and active support to enable multiple data sources (e.g., labs and hospitals) to send results to multiple recipients and provide both senders and receivers a single point of contact for troubleshooting.
• Mapping imprecise recipients data (e.g., taking a physician name as the recipient of the lab result and determining whether to deliver the result by fax, on-line lookup or structured transmission to the EMR).
• Aggregating data at a community or state level for measuring quality, epidemiology, and other programs.

The only thing that an HIE has to do to compete with NHIN Direct-based communications is exist.

How, then should an HIE deal with the fact that by the time it comes to an operational state a great deal of communication may be going on under NHIN Direct? Easy: join it instead of fighting it. Be prepared to bring practices that are already using NHIN Direct into the fold without having to immediately change what they do. Add immediate value by forwarding patient results and notes with the practice’s patient ID. Provide shims for labs that cannot get to standard approaches. Allow them to begin to look up patients (using new interfaces) as soon as their EHR is ready. Allow them to use a portal to look up patients and have the results sent to them through NHIN Direct.

To really seize the initiative the HIE should become a provider of NHIN Direct services to physicians that don’t yet have an EHR or have an EHR that is not yet capable of dealing with NHIN direct. Operators of such a portal are in an ideal state to gradually introduce services that add value as soon as they can make the software and business agreement arrangements.

After looking into this I confess that I have added to the confusion. As I have learned, a big part of the confusion is because people don’t mean the same thing when they say “web services.” It’s a bit like a fan from Manchester, NH and a chap from Manchester, England arguing about “football.” For example:

1. To some a web service is any service that can be obtained computer to computer using HTTP.
2. To some, a web service must at least use SOAP.
3. To others, it ain’t a true Web Service unless it is architected like the diagram below
4. Finally, there are those that also require the WS-* protocols.

Web Services Architecture

The Wikipedia article cited above attempts to clarify the set of choices by describing the world as being divided into two camps “RESTful Web Services” (number 1, above) and “Big Web Services” (all other combinations, including numbers 2, 3 and 4). This probably represents the main two camps in the nerd wars very well, but it is clear that the advocates of the RESTful style of architecture would not gladly accept into their camp everyone who confines their use of protocols to HTTP. For example, those that use only the HTTP commands but hide other commands in the URIs are mere pretenders, trying to make their approach look RESTful-ish but not legitimate claimants to all the benefits outlined in the Fielding dissertation.

Rather than some up with a taxonomy of names I think a better approach to Simple Interop would be to look at the capabilities needed to support  computer-to-computer communications outlined in Simple Interop: Issues Associated with Automatic Processing and, for each item on the list, answer these questions:

• Is this capability that Wes dreamed up really necessary for simple interop?
• Is it being done already enterprise-to-enterprise  healthcare apps on the Internet?
• If not in healthcare is this capability being provided broadly in other enterprise-to-enterprise apps that use the public Internet?
• If the capability is used, how much is based on standards and how much is defined ad hoc pair wise or in larger groups by the dominant trading partner?

Almost by definition any encrypted, reliable communications with scalable authentication (X.509 certs) based on “just HTTP” is going to match up with the fourth bullet.  To adopt a bilateral or  dominant-partner specification we need to have some consensus that would permit ONC to recognize it as a standard. I hope to find an approach that is, at least, used with a bunch of trading partners in production. If so, perhaps others will agree that adopting it would be the most expedient way to roll out simple interop to support the meaningful use interoperability measures.

I am explicitly staying away from a separate question, “what standards are available?” My rule is, if you want to pick something that will roll out quickly, pick something that has already been rolled out.

Digression on the term “Computer to computer messaging.”
This term also creates confusion. Aren’t all communications computer to computer? Isn’t a user in a Web browser or a thick client using a computer? What we are really trying to describe is a message that is sent without oversight by a user. So a lab technician approves the instrument result for the last test in a battery and then instantly moves to the next test in a different battery for a different patient. Sometime later the LIS transmits the results to the physician’s EHR, but there is no person in the lab watching it.

This is a lot different than the situation where that same technician is using on-line banking to change his postal address. Typically after one pushes the submit button the browser window goes dead until the bank has sent back another page saying it has accepted the transaction. In the latter case we have a person watching to see that things went well and, presumably,  willing to push Submit again or start over if some disruption in the Internet connection causes the transaction not to succeed.

Another term we have though of is “unattended messaging.”

Recently I combined all the ideas in a single PPT presentation. You can download it by clicking here to leave the Gartner Blogs web site and then clicking on the link to the presentation.

It will come from my personal web site for two reasons.

• I offer it under a creative commons license that allows you to use it as you wish, including incorporating it in commercial material.
• Gartner’s policy for blogging is not to post files in formats that might be dangerous. My laptop seems well protected by and my web site is maintained by a seemingly reliable ISP but I urge that you use the same precautions that you would or should when downloading any Office document — just in case.

There is some new material in the presentation that is not in any of the previous blogs on the topic. This includes:

• An idea about structuring the roll-out into “quick” and “extensive” phases with the quick phase hopefully sufficient to meet the minimum interoperability measures for Stage 1 of the criteria for receiving the meaningful use incentive. The “extensive” phase is more scalable.
• Discussion of the relationship to disease registries.
• Expanded use cases cast in terms of the meaningful use requirements.
• A discussion of business opportunities for open source and proprietary providers of technology, hardware and services.
• Some open issues are cited.

After you have reviewed the presentation I would love to hear your comments added to this blot posting. You are free to re-use the presentation as you wish, but I would appreciate a comment here, an email or a tweet letting me know how you are using it.

We did use C-DEMS (open source) as our registry but have used PECSYS from Aristos the last 5 years or so. It is proprietary, but allows us to customize (we have great programmers). We are also implementing an e-referral system called IRIS across the whole county and will use it to create a master patient index (the Holy Grail of regional health care data).

Over the past year EHRs have struck in Humboldt with a vengeance, mainly in the FQHCs and other safety net clinics. Open Door Community Health Centers (6 sites) are on EPIC via the Portland-based Oregon Community Health Improvement Network (OCHIN).  The tribal clinics are on NexGen. Mobile Medical has ECW. One large private practice is on Allscripts (Eureka Internal Medicine) and another (Eureka Family Practice) has Practice Partner. There a few others in the specialists offices… so now we are at 41% penetration by physician count (not by practice, as the small offices haven’t yet succumbed). EHRs have only helped the registry because we have figured out how to extract data by creating reports that access the “back end” and pull out what we need (mostly weekly, some more often). We may be the first to solve this without very costly real-time interfaces. So the registry is alive and well (and results continue to improve dramatically – our IPA ranked in the top group for statewide P4P (one of 2 IPAs to achieve this in a world of well-resourced staff model multispecialty groups such as Kaiser, Sharp Rees-Stealy, Health Care Partners, and the Palo Alto Medical Foundation).

We believe we can reach most of the physicians not on EHRs. Our plan is to get them to turn ARRA incentive $ over to us. We will do (or subcontract for) the installing, training, system maintenance. [The project approach will get them] to meaningful use. … I’m hopeful the model will become more patient-centered and system-focused, rather than viewing practices as stand-alone entities.

The model for small practice EHR installation comes from the Tulare initiative undertaken by the California Health Care Foundation (CHCF). We will borrow their approach.

What lessons should I take from this new information? First off, I am prouder than ever to be in this County and to have this opportunity to sneak in some boosterism.

I would argue that it was the early community health and P4P successes that engenders cooperation that will create the specific kinds of interoperability that impact patient care. This shows that interoperability begets interoperability. Such begetting is not a technical phenomenon; it is a social one. Achieving some success makes it easier to talk about more efforts. If Alan is successful in getting physicians to assign incentive payments to cover his program it will be in part because of pre-EHR, IT-enabled successes.

I will be delighted if the Simple Interop approach enables other communities to build P4P and other capabilities without tying their success to universal roll-out of EHRs and the creation of a full formal HIE.