The 2015 Edition Certification and Standards Rule

In case you've been in a cave (or at an HL7 working group meeting) and haven't heard, the Meaningful Use Incentives and 2015 Standards and Certification rules dropped yesterday.  I already had a lot on my plate yester-eve, so my Twitter review didn't start until about 10:30pm (much to the chagrin of of some folks).

Overall, I think this final rule is a win-win.  One of the big changes I was very happy to see was the change from C-CDA 2.0 to the new C-CDA 2.1 that HL7 members developed in response to the proposed rule in record time (see my posts on that story).  I got some very complimentary feedback on my work and that of Bret Marquard on that project, and I want to thank him again for his tremendous efforts in making that happen.

What follows below is essentially an edit of that twitter feed in case you weren't up til 2:00am reading the rule like I was.

First, skip to page 5 (skip the background drivel).  Starting there you will find an overview of what is in the rule.  Highlights include:

1. Updated standards and vocabulary for the new common clinical data set (CCDS).
2. A functionally defined API (ONC is headed towards, but did not name FHIR) for access to CCDS content.  Most of the industry is moving towards FHIR here.
3. A shift from EHR focus to Health IT focus.
4. Capture of sensitive health disparity data was retained, and includes not just gender, race and ethnicity, but also sexual identity, and social, psychological and behavioral data elements.
5. A continued emphasis on privacy and security.
6. More attention to user-centered design.
7. Support for better patient matching (but not as severe as orginally proposed),
8. About 4-5% of the document is devoted to implanted medical device identification, a very hot topic. 
9. It claims to provide more flexibility and time, and I certainly see some of the flexibility in this rule, but have to look at the incentives rule to answer more about "Time".

A few other notes from the Executive Summary:

• The API must support a query of any individual data item in the CCDS, as well as all at once (p7).
• It introduces new C-CDA requirements to improve reliability. 
• It updates the 2014 Base EHR to add smoking status demographics, includes the API and implantable device list requirements.  
• Much of the incentive based material, such as definition of Certified EHR Technology, CQM requirements and meaningful use measurement requirements have moved to the Incentive rule, rather than the 2015 edition rule.
• ONC estimates the total industry cost estimated at $330M +/- $70M (p15), and I might remind you that HITECH came out of an economic recovery bill.  

Skip the next ten or so pages (history of past regulation isn't that useful for most) to start again at page 26.

Not Adopted and Unchanged Material

Proposed criteria NOT adopted includes:

LOINC coding of Vital Signs, Family History using HL7 Pedigree standards, patient list, EMAR, Clinical Decision Support Knowledge Artifact and Service standards, Accessibility technology, Healthcare Provider Directory (HPD), and Electronic Submission of Medical Documents (esMD).

Criteria that is essentially unchanged includes:

CPOE for Meds, Labs and Imaging; drug and allergy checking, drug formulary checks, meds and allergy lists, smoking status, transmission of reportable lab results, privacy and security criteria regarding: Authentication, Access Control, Authorization, and Audit. Also amendments, automatic access time out, provision for emergency access, encryption of data on end-user devices, and accounting for disclosures.

New and Revised:

Pages 29-30 contain a good table describing the previous as well as new and revised stuff, I just wish this material was available not just in a machine and human readable format (PDF), but also a computable one like IETF RFC-4180.  I'm hoping ONC will do that as they have in the past.  For the most part, the remainder of this post addresses the new and revised material, and in some cases, the not adopted material.

Page 34 is simply a one page excuse for lack of use of consensus standards when they applied Direct. I'm grateful for this recognition that Direct falls into that category, and never became a standard even though that was the original intent.

Vocabulary

One vocabulary, they kept the provisions on use of NDC Vaccine codes👎, as is CDC Race and Ethnicity 👍.  One of the big changes the latter introduces is that the EHR must now support capture of multiple ethnicities, something that is not required by OMB, nor was required or supported previously in C-CDA.  We can address that latter need through an extension created for this purpose by structured documents.  ONC and NIST can address how multiple ethnicities can be used in a sub-regulatory way.  As this follows the pattern necessary for multiple race, I foresee no difficulties with applying that process.

There's a useful table of vocabulary OIDs used in Meaningful Use on page 39 (note, that's a useful table of OIDs, not a table of useful OIDs).

Psycho-social Data Capture

On the psycho-social front, I noted that gender identity value set includes Male, Female, trans (male/female), genderqueer, and other categories.  My kids can tell you that this is a very limited set, but it at least begins the recognition that gender identity is an issue associated with treatment disparities.  Elsewhere on the psycho-social-behavioral data capture front, the EHR needs to support it, even though the physician (under stage 3) is not required to use that capability.

Discussion of device identifiers takes up 1/25 (approximately) of the rule text.  The short summary is that yes, you have to store and parse them, but FDA can help.

C-CDA

On C-CDA, you'll have to support read of both 1.1 and 2.1 releases, and output 2.1 content that is backwards compatible with 1.1.  They did limit the requirements to support only the CCD, Referral Note and in the case of inpatient settings, the discharge summary.  Furthermore, systems must be able to support validation and error checking on both releases on import/incorporate/display.  A gold standard sample document is being prepared to a) show implementers how things should be done, and b) ensure that they can produce something like that.  On the topic of relevant and pertinent content, they remind us that providers can decide what to include, but the EHR must have the ability to send all content.  To further support relevant and pertinent, they also require the EHR to have the ability to support display of only a particular section (or sections), set user preferences for display order, and to set the number of initial sections to display.  Note, creating and receiving a C-CDA document are now separate meaningful criteria, which makes it quite nice for folks who are developing systems that just generate the C-CDA to be integrated with others that handle the transmit/receive capabilities.

Patient Matching

Some of the Patient matching requirements remained in the rule, but the CAQH Core rules were not adopted for a variety of good reasons (mostly having to do with the fact that this normalization is done at the receiver side).  C-CDA does support the needs here.
They did note a challenge in that prior address is not explicitly called out in C-CDA, nor is usable period.  However, I will note that since C-CDA is based upon CDA, and those capabilities are still present, just not specifically called out in C-CDA (nor where they in CCD).  So, they can still be used to identify historical data.

Data Provenance and Data Segmentation for Privacy

Capturing and recording Data Provenance using the HL7 DPROV was suggested, but has been dropped from the final rule, essentially as not being ready for prime time (my words, not theirs). The provisions for Data Segmentation for Privacy (DS4P) have been included, but are not required for the incentive rule or the base EHR capability, so DS4P is essentially optional.

Reconciliation

I'm still crying inside that ONC essentially adopts the IHE requirements its RECON profile for incorporation of data, but does not name it.

ePrescribing includes 10 NCPD transactions, including history, but does not require NCPDP structured sig as it is deemed to be a bit immature.

Patient Access

A number of changes to VDT and other patient access requirements really made my day.  View, Download and Transmit are expected to support imaging reports and lab results.  One of the new requirements on transmit is that an EHR must support transmit not just to a Direct address, but also to any e-mail address (unencrypted).  Patients, under current HIPAA regulations, may presently ask that data be disclosed to them via unencrypted email, although that provision is little known.  After a provider has a certified EHR product (to the 2015 edition criteria), docs won't be able to use the excuse that "we don't have that capability" when a patient requests it.  If they do, I imagine this page might get more hits (although it needs to be made clear that access falls under privacy and security).

The API requirements are also noted as being able to support patient access criteria.

API

API requirements have been split up into three separate pieces.  While FHIR was mentioned several times in the rule, it was not named for API requirements.  As ONC states a couple of times: "we decline to recommend a specific standard at this time, although we intend to do so in a future."  

That last statement is a big hint to everyone.  While Meaningful Use may go away, Certification seems to be here to stay.

   -- Keith

---

P.S. The first draft of the bookmarked final rule can be found here, thanks again to Corey Spears. This is just as much as he could get bookmarked so far, expect updates.
P.P.S. You can find the changed tracked regulatory text here.  I extracted (using Acrobat) the proposed and final regs from the PDF into Word, and then applied Word's document comparison to get the edits.  Your mileage from this process may vary.
P.P.P.S. ONC's presentation from today is here.

Balance in Governance

One of the biggest unrecognized challenges to balance in consensus standards development processes is lack of balance in Governance.  What do I mean by that?

Governance is about who decides.  Who decides what the priorities are?  Who decides where scarce resources are deployed.  Who decides not just what gets done, but who does it?

Let's look at several examples of lack of balance in government in standards development over the last decade:

CCR: The CCR steering team was made up of medical professional societies.  The team decided overall direction for CCR development.  Vendors and other participants in the development of the standard were not permitted to be part of the steering team.  This resulted in a great deal of unnecessary conflict in the development process, and in the end, the ultimate death of CCR as an XML standard (the core data elements of CCR live on today though, in CCDA and elsewhere).

ONC/AHIC/HITSP:  While HITSP had a generally balanced process for development and approval of specifications, it was ONC and AHIC who determined what specifications would be worked upon.  ONC set the general direction, and AHIC filled in the specifics. And whether or not the project was viable based on the consensus of the HITSP membership, HITSP still had to deliver specifications to meet the use cases handed down by AHIC.  This resulted in specifications such as Biosurveillance which consumed a great deal of effort, and resulted in previous little change (recall that this Use Case came out not long after the anthrax scares of 2011).

ONC/The Direct Project: ONC decided what it wanted and initiated a project to make it happen.  It was widely touted as a great success, unfortunately, the specifications are still "government created" as they have not yet been taken up by any SDO, so no non-governmental body exists for maintenance, and there are still challenges in deployment.  The decision about what project to work on (a governance decision) was made by ONC.

ONC/S&I Framework: This has been better, but with a lot of variation in how these projects are executed.  The best example of governance challenges are with the HQMF and Health eDecisions. The projects were separately initiated and staffed, with little overlap.  Fortunately, both projects were also done through HL7 governance.  When challenges arose about incompatibilities between models in the two specifications, HL7 initiated a review and rework process that has resulted in much greater harmonization across these specifications.  This is a perfect example why consensus in governance is critical.

Argonauts and HL7 FHIR: This one is fun.  It's greatly touted collaboration of a number of Health IT juggernauts with HL7 on accelerating the development of FHIR.  The project management and decision making about what projects are to be focused on is restricted to a closed group (the original Argonaut members).  Others can participate so long as they do so according to the structures created by the original decision making body.  The end result may well benefit the whole industry, but the decision making about what to do is closed.  For example, how are OAuth2 specifications to be evaluated, and if there are changes necessary to existing specifications, where will those be done? There isn't a consensus group making that decision.

ONC has asked some key questions in their recent publication of the Interoperability Roadmap. Many of these impact governance issues similar to those I've raised above.  

JASON and the EHRnauts

I thought I was done with JASON and the EHRnauts for a little bit, when this query popped into my inbox via Will Ross over at Redwood MedNet.  He points to this bit of wisdom:

From the report:

To the extent that query capabilities are included in MU Stage 3, we are at an awkward moment in standards development: Older standards such as XDS/XCA are mature but inherently limited, whereas newer API-based standards are not yet ready for large-scale adoption. We believe it would be detrimental to lock the industry in to older standards, and thus, we recommend that ONC mobilize an accelerated standards development process to ready an initial specification of FHIR for certification to support MU Stage 3.

I love it when people raise the point about limits, without delving into what those limits are.  It always sounds so authoritative.  Yes, documents are limited.

Here are some of the limitations of documents:

1. You can only operate on what appears within documents.  
2. You have to have some idea about which documents you want.  
3. When dealing with multiple documents, you have to deal with redundancy and ambiguity.
4. Documents are coarser grained than some problems want to deal with.

There are also benefits to documents:

1. A document can be operated on by a human using very little technology (Human Readability), or by a computer.
2. Documents link each fact reported to an encounter or visit, a healthcare provider and and institution (Context).
3. A document provides the complete record of the encounter or visit, not just individual parts that can be interpreted out of context (Wholeness).
4. The content of a document can be retrieved at any point in time in the future in a way that is repeatable (Persistent).
5. A document links data to the organization that gathered, uses and manages it (Stewardship).
6. A document can be signed by a healthcare provider (Potential for Authentication).

Anyone who has studied CDA will recognize where these properties come from.

Now, as to the limits, all of these can be overcome, the question is who does it.  The fundamental organization of data in an EHR around information documented during an encounter isn't likely to change whether you look at a large grained document-centric approach, or a finer-grained data item-centric approach.

You'll only ever be able to find information that has been gathered, or the fact that it hasn't been gathered.  The document based approach means that you need to look at several documents to determine that for a time period, a finer grained approach means that the system you ask for that information must look at all data items in that time period.

You will always have to have some idea about what you want to ask for.  In the document-centric approach, that can be based on document metadata such as who, where, what or when.  Those questions are often asked at the first level of the physician's workflow in their search for more information.  Finer-grained approaches will allow more detailed questions to be addressed that come later in the evaluation of the patient: Did they have this test? If so what were the results? Was ____ ruled out?  When was the last time ___?

When dealing with multiple facts over time, you will have to deal with redundancy, ambiguity and disagreement.  It is quite possible in an EHR today to have one physician assert something, and another deny that same thing, and both may be correct, or they may conflict.  This is true regardless of whether the data items are accessed through coarse- or fine-grained mechanisms.  Documents increase the degree to which this occurs because of the wholeness principle, you get all of the relevant data about the encounter, not just a few small pieces of data.  But you should be able to readily resolve those issues, because you will always have them to deal with as soon as you have multiple data sources.  Documents just make that problem visible sooner, because each document can be (and often is) treated as a single data source, whereas it only shows up in fine-grained access mechanisms once you have more than one data source.

The key issue is that some folks want to get right down into the computer automation of tricky bits, which means that they often don't want what they consider to be the excess baggage of documents. Agreed, we need a better way, and the industry is working on it.

I also love it when I hear "lock in", because frankly, when something better comes along, people will use it, regardless of what the government says or does (consider how mobile has driven healthcare). In most cases, the best thing it can do is get itself out of the way ;-)

To say (as the JASON Task Force does) that "There is currently no industry- or government-led plan or effort focused on ubiquitous adoption of standardized Public APIs." is technically correct.  But let me ask you, where was the plan to adopt HTTP and HTML and CSS for the World Wide Web?  XML and Schema?  MIME and SMTP and POP for eMail?  If anywhere, it was in the minds of the creators of those standards and the implementers. There was no government program driving adoption.

Right now, HL7, CDISC, DICOM, IEEE, OpenEHR, and IHE have all rallied around FHIR as the way forward for a variety of different use cases (see for example IHE's Mobile Access to Health Documents effort).  Major vendors, national programs, industry consortia, and other organizations have publicly announced support for FHIR in products, programs and services currently being developed.  This kind of thing is nearly unprecedented in health care.  To come upon if after the fact and try to impose some US federally crafted plan to make it happen is just a bit ambitious don't you think?  After all, it worked so well the last time with Direct.

My advice is to tread carefully, as ONC has already been doing.  Offer support and assistance, encourage communication among different groups, maybe even fund some development.  However, I think HHS needs to avoid the arrogance of thinking that it could plan this much better than is already occurring naturally in the industry.

I leave you with these thoughts:  The Web took about five years to be widely used, and another five to really mature.  FHIR has been with us for a bit more than two years.  Rather than asking whether we can we afford to wait, consider if it will be worth it to rush.  It won't be too much longer.

-- Keith

P.S.  I was very impressed with the JTF report.  It was a very thoughtful response to the original work.

Worth Waiting For

About 12 years ago I was to have given a sermon at my church.  In planning for it, I asked our rector how long a sermon should be.  He answered with this bit of wisdom: "It takes as long as it takes."  Of course, he didn't realize I was asking about what I needed to do next week, and was thinking I was commenting on the length of his sermon that week.  But the phrase stuck with me, and the next week, when he realized WHY I was asking, we had a good laugh over his non-answer.

It is now October 2014.  This time last year HL7 was hurriedly trying to put the final pieces together for C-CDA Release 2.0, so that we could get it out in time for regulation.  It's still not published yet, although it soon will be, and the reality is that we apparently didn't need it in such a hurry.  Recent discussions on HL7 FHIR and the CDA and C-CDA on FHIR projects indicate that the dates for these don't all line up for the DSTU FHIR Ballot schedule.  There's some discussion about whether or not we should delay it.

I for one am all for taking as long as it takes to do things right.  I'm a bit tired of rushing stuff out to ballot to meet deadlines that were made by people who don't necessarily understand real world healthcare provider upgrade and deployment schedules.  We have plenty of work to do, and the industry has gotten itself pretty convinced about the right way to go.  Now we just have to convince folks that it will be worth waiting for.

Thus ends my sermon for this day...

   Keith

Stages of Standards Development

One of the most amusing things (because if I didn't laugh I might cry) about the Meaningful Use program is the way that executives who have never paid anything more but lip service to standards are now reporting as experts on their effectiveness (or lack thereof) and the related causes.  Reports out of the HIT Standards committee about the need for improvement of CCDA are a perfect example of this.  However, the problems being reported almost certainly aren't the real problems that need to be addressed.

I have a theory about Stages of Standards Development that is fairly similar to Lohlberg's stages of development, but applied to standards and interoperability.

1. We used this standard because we would get punished (or not rewarded) if we didn't.
2. We used this standard because you told us too.
3. We used this standard because everyone else is using it too for this problem.
4. We used this standard because we are actually paying attention to interoperability.

In the first stage, the use of the standard is to avoid punishment.  Application and understanding of the standard is low.  The minimum work is done to pass the tests, and no thought or effort is put into the use of the standard to do anything more than to comply with the requirement.

The second stage is no much different, other than the user of the standard now recognizes authority, and may actually understand that there is a reason for being granted the authority.  So they may pay a little bit more attention to the standard, but don't really yet understand it.

The third stage is when the user of the standard looks around and sees that lots of other folks are using the same standard, and they could benefit from it as well.  In this stage, there are some they can learn from who are at more advanced stages and others who are not.  At this stage, they pay quite a bit of attention to learning as much as they can about the standard to make it work.

In the final stage, they stop worrying so much about the standard, and really start focusing on the intent and purpose of it, which is to enable interoperability between systems.  They stop looking at all the slavish ways the standard can magically solve the interoperability problem for them, and start realizing that standards are a major component of interoperability, but that other things are needed to support it as well.

Meaningful Use will only take us so far over time.  Stage 1 and the 2011 criteria only enabled level 1 and 2 adoption behaviors.  Stage 2 and the 2014 (Release 1 and 2) criteria starts to enable level 3 adoption behaviors, and creates an environment where level 4 behaviors can emerge.  But they do nothing to support level 4 behaviors.  The REC program supported some higher level behaviors, but it too really only stopped at level 3.  The workforce education program may have contributed a bit more to higher levels.  The Beacon program certainly tried to support level 4.  However, most of the money for these programs is well past gone.

Interoperability is a journey.  Standards are an important tool along that journey that are necessary. But most don't even know how long that journey really takes.  We had RFC-822 and before that RFC-561, and even today, after more than 4 decades, e-mail is still not perfectly interoperable. Remember Lao-Tzu: The journey of a thousand miles begins with a single step.  We've taken a few so far, let's keep going.

ONC 2014 Edition Release 2

ONC figured out that it had a versioning problem with it's third release of the Certification and Standards rule.  This one (original entitled the 2015 edition) has been renamed to the 2014 Edition, Release 2.

What's new?  Not a lot actually.  As originally envisioned, there were plenty of changes coming to EHR vendors and users.  As written, it's a much smaller list of changes for everyone, which I summarize below.  A lot of what I complained about in the proposed rule is gone from the final rule. Other issues have simply been put off until stage 3 and 2017. In their own words ONC has "not adopted the Proposed Voluntary Edition. Rather, we have only  adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange."

• Split CPOE into separate criteria for ordering Medications, labs and imaging.
• Decoupled content and transport capabilities for transitions of care
• Shifting the “incorporation” into an updated “clinical information reconciliation and incorporation” (CIRI) criterion.
• Adopted Version 1.1 of Direct Edge Protocols
• Decoupled the transport and content capabilities of the VDT certification criterion.
• Allowed "any method or standard" to be used to "electronically create syndrome-based public health surveillance information for electronic transmission" for ambulatory use.  The net effect here is to enable meaningful users to claim the capability for the purpose of incentives if they electronically transmit surveillance data to public health.
• Included an optional set of data elements (patient demographics, provider specialty, provider address, problem list, vital signs, laboratory results, procedures, medications, and insurance) to support surveillance.  This optional list on an optional criteria, basically serves the purpose of telling people the eventual direction they might go in a couple of years.
• Discontinued use of the Complete EHR concept and Complete EHR certification
• Created an ONC Certification Mark

There you have it, an even shorter summary of the short list of what ONC has added to certification in 2014.

---

I forgot to include Table 3 from the rule, which lists the differences between the various editions. It is quite useful

Table 3. Gap Certification Eligibility for 2014 Edition, Release 2 EHR Certification Criteria
2014 Edition Release 2		2014 Edition		2011 Edition
Regulation Section	Title of Regulation Paragraph	Regulation Section	Title of Regulation Paragraph	Regulation Section	Title of Regulation Paragraph
314(a)(18)	Optional – computerized physician order entry -medications	314(a)(1)	Computerized physician order entry	304(a) 306(a)	Computerized physician order entry
314(a)(19)	Optional – computerized physician order entry - laboratory
314(a)(20)	Optional – computerized physician order entry – diagnostic imaging
314(f)(7)*	Optional – ambulatory setting only – transmission to public health agencies – syndromic surveillance	314(f)(3)	Transmission to public health agencies— syndromic surveillance (ambulatory setting only)	302(1)	Public health surveillance (ambulatory setting only)
314(h)(1)	Optional – Applicability Statement for Secure Health	314(b)(1)(i)(A) and 314(b)(2)(ii)(A)	Transitions of care—receive, display, and incorporate transition of care/referral summaries. Transitions of care—create and transmit transition of care/referral summaries.	N/A	N/A
314(h)(2)	Optional – Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging	314(b)(1)(i)(B) and 314(b)(2)(ii)(B)	Transitions of care—receive, display, and incorporate transition of care/referral summaries. Transitions of care—create and transmit transition of  care/referral summaries.	N/A	N/A
314(h)(3)	Optional –SOAP Transport and   Security Specification and XDR/XDM for Direct Messaging	314(b)(1)(i)(C) and 314(b)(2)(ii)(C)	Transitions of care—create and transmit transition of care/referral summaries.	N/A	N/A

* Gap certification does not apply for the optional data elements listed in 314(f)(7).

---

What Happens when the Funding Goes Away?

There are three ways that standards really happen.  One is when a bunch of organizations get together to solve a mutually challenging problem and develop something, like CDA or HL7 Version 2. The other is when a bunch of organizations discover that a particular piece of technology works to solve a problem and decide to make it a standard (e.g. Schematron or PDF).  The third way is when a single organization decides that a standard should exist and funds the development of it.  Large (usually governmental, but not always) organizations do this sometimes.

The question that concerns me about the latter is what happens when the funding goes away.   I've seen this occur already in some funded "meaningful use hopeful" standards projects (projects hoping to get a line a in the reg at some point).  The interesting thing is what happens when the funding disappears.  Momentum gets lost, sometimes enough that the standard itself might never really get finished, or implemented, or used.

Look at Direct for example.  it is certainly suffering from the lost momentum problem.  Was it worth it?  Given that Direct got the MU mention it was after, it will probably succeed.  But is the artificial stimulus the best approach?  Maybe, but maybe not.  I don't know what other levers to pull, but I'm surely looking for them.

Principles for HealthIT Standards Selection

Last Thursday the Clinical Quality Workgroup met to finish the discussion we started in October on principles for standards selection.  We reviewed the following single slide in detail and verified that these are indeed the right questions to be asking about standards that we recommend as a workgroup.

This is a really nice reduction of our discussions to a very simple, easy to use assessment that any HIT Standards Committee workgroup can use to assess readiness of a standard for use in certification processes. This material is based on past work from NIST (for Smart Grid standards) and IHE (for standards selection used in IHE profiles) and HITSP (e.g., the Tier 2 spreadsheet).  The Clinical Quality workgroup will be using this assessment going forward for its recommendations to the HIT Standards Committee, and I personally hope that other committees adopt this assessment process as well.

Sharing Savings with Patients

The other day, my wife and I had to make some choices about a piece of DME equipment that she needed.  I spent a good bit of time researching various options, and we wound up choosing a piece of equipment that was half the price of other options presented.  It wasn't just the cost that helped us to make that decision, it was also recommendations based on quality and reliability, and we didn't choose the cheapest unit.  But still, we spent about half of what we could have.  We spent all of this time because I want to optimize my use of my HSA.  This has a real financial benefit, but it isn't an obvious one for many.

In thinking about the Medicare Shared Savings program, a thought occurred to me that healthcare providers are getting the opportunity to share savings.  What would happen if in addition to sharing savings with providers, insurers (including Medicare) shared savings with patients.

How would this work?  Payers would need to establish and share with patients the costs they expect to have with respect to care for a specific condition or injury.  They'd also have to share with patients the costs of various care options.  At the end of each year, for each condition or injury experienced by the patient, where the patient's treatment cost the payer less than the expected amount, the patient would be reimbursed a portion of the saved amount.  This is a much more obvious financial incentive that would very likely have a much larger impact on patient behavior.

It would take a heck of a lot more transparency and information than patients have today about the costs of care.  Most insurance calculators that I've seen don't cut it.  What I've seen is that they compute the cost based on the treatment that they expect providers to give, rather than what we as patients get.  My favorite story is the $44 dollar ice bag that we were charged for for one of my wife's PT visits.  After we got the first bill, she told them she'd do that at home during the next visit.  And the insurance calculator never figured that into our (or their) costs.

Imagine what could happen if patients had such an obvious financial incentive to take a more active role in their care.

Clinical Quality Workgroup Call Summary

The HIT Standards Clinical Quality Workgroup met today.  We were tasked by the HITSC with responding to certain sections of the Meaningful Use Stage 3 Request for Comments.

On Retiring Certain Meaningful Use Measures:
The workgroup seemed to be in agreement that after 80%, we should start looking at measures that reflect the use of data captured, rather than just testing for data capture.

On Care Plans:
We should look for use of certain basic data elements in care plans, and continue to promote standardization of care plan data elements.

On Clinical Quality Measures (CQMs):
We should consider redevelopment of quality measures that work with the information models and clinical data that is required under meaningful use, rather than simple retooling of existing quality measures.  We should also consider using HQMF Release 2.0.

On Technology for CQMs:
Data models are incredibly important.  We need to have a consistent data model across Health IT.  One speaker noted differences between the Health eDecisions work and the HQMF work (which was my principle complaint about it).

On having a Core set of CQM's:
This is rather challenging for specialty providers.  One speaker suggested that while we might want to focus on something that gives us big bang for the buck, it might not be applicable to every provider.  We didn't come to consensus on our position on this call.

On getting input for the HITPC and its workgroups:
Attending meetings in DC is rather limiting, should also consider getting input at other venues.  For patients, HITPC needs to go to them, not expect them to come to HITPC.

On use of Patient sourced data in CQMs:
Yes, but... the standards are still under development.  We agreed that it important to annotate the source of data.

On Process vs. Outcome Measures
Not an either/or question, rather an and/both.  There was agreement that measure suites containing related process and outcome measures would be quite valuable.

On Measure Development
It is important to support consistent use of data elements, models, vocabulary and value sets.  We need a measure of quality for quality measures.

That's about as far as we were able to get.  There were some 30 items we were tasked to address, and we were able to discuss almost all of them in the two hourse before we needed to finish the call.

Two new consumer-focused HIT FACA Workgroups looking for members

Submit your application for potential membership on two new consumer-focused HIT FACA Workgroups The HIT FACA Committees are forming two new consumer focused workgroups, the HIT Policy Committee’s Consumer Empowerment Workgroup and the HIT Standards Committee’s Consumer Technology Workgroup.  HIT Policy Committee’s Consumer Empowerment Workgroup will be charged with providing recommendations on policy issues and opportunities for strengthening the ability of consumers, patients, and lay caregivers to manage health and health care for themselves or others.  Examples of issues to be covered include patient generation of their health data, incorporating patient preferences into care plans, and new types/sources of patient data.     HIT Standards Committee’s Consumer Technology Workgroup will be charged with providing recommendations on standards and interoperability issues and opportunities related to strengthening the ability of consumers, patients, and lay caregivers to manage health and health care for themselves or others.  Examples of issues to be addressed include portability of patient data, patient access to and generation of their health data, and incorporating patient preferences for a variety of issues, such as care plans.   If you are interested in being considered for membership on either of the two workgroups, please register at ONC’s Workgroup Application Database.  ONC will be reviewing the applications received by January 14, 2013.  For more information on the Committees and Workgroups, please visit the ONC FACA Website.  Thank you for your interest in the HIT Federal advisory Committees.

Why we don't need more HealthIT Standards Development

I spent a couple of hours yesterday listening to testimony given to the House Subcommittee on Technology and Innovation.  Testifying were Farzad Mostashari, Dr. Charles Romine of NIST, Mark Probst of Intermountain Healthcare, Rebecca Little of Medicity, and Professor Willa Fields, incoming chair of HIMSS.  Brian Ahier summarizes the hearing rather well.

One of the challenges in listening to this hearing for me were comments from Mr. Probst.  His concern is the lack of core, foundational standards, which he believes have yet to be produced.  I've heard this complaint before, and given than I'm deep into standards development, it always concerns me.  It even further concerns me that such a statement could be made when there's been SO much standards work over the last five years, as compared to the five years before that.

Why this is challenging should be clear when you read through what is currently going on after his list of 7 core standards below.  When he fails to point out these activities to lawmakers in his testimony, Mr. Probst fails to educate them on what the industry is doing.  Instead of hearing, "yes we are making progress" as he stated in his testimony, the message that gets communicated is that we haven't done enough.  There is a big difference between not finished, and not started.

I went back over his testimony and his answers to questions, and transcribed several portions of it which don't appear in the written record.  This first part comes from his verbal testimony starting  24'47" in.

Probst: I simply do not believe that the current voluntary approaches to standards definition work.  In my opinion what is needed is a mandate to:

1. Define the set of information system related standards which will be applied to healthcare.
2. Ensure accountability, to appropriately develop the standards and document the standards
3. Set a time frame to define and document the standards, measured in months, not years.
4. Establish a realistic time frame in which the HIT community must adopt a federally supported set of standards, say 10 to 15 years.

I've been working on standards for more than a decade, including some of the "foundational, core standards" of the Internet.  Does XML, XPath, XSLT or DOM2 ring any bells?  These were NOT defined in months, but rather years.  And yes, they were adopted over time, but not nearly so tremendous a timeframe as say a decade or more.  Yes, as Mr. Probst states, "adoption of standards" is hard, but it surely is not something that need take the HIT community so long as 10-15 years.   But we get only months for standards development?  He should come down into the trenches with the rest of us working on these standards.

This next part comes from the subcommittee chair's questions probing on Mr. Probst's remarks.  This discussion starts around 42'15" in the hearing.

Rep Ben Quayle (subcommittee chair): Mr. Probst, I want to get to your testimony, becuase in your testimony you stated that Voluntulary Consensus Built Standards Don't Work in the Healthcare Industry. In previous hearings, we've had NIST here a lot, and one of the main things with NIST, is that it is very consensus driven with the stakeholders, and it has worked very well. Why do you not think that in the healthcare industry, that is the best way to go, and instead come up with a set of standards from a top down approach rather than from a voluntary consensus approach. I just want to get your take on that.

Mark Probst: Well, I think the very fact that we are having this conversation suggests that it hasn't worked.  We've been doing it for a very long time.  That is not to slam HL7 or DICOM or any other groups that have been working on those standards.  There are varying incentives in those groups, the people that form those groups have different rationale for why they want standards, or what standards that they might like.
But again I think the fact that we haven't come to some basic standards like the guage of rail that they did in Australia.  We're dealing with all the discussions around health information exchange and what kind of contraptions we can we put together to move data from one system to another, that loses fidelity and costs time.  I just think that history is a good educator for the future.  And I don't see how we are going to get to standards without some basic direction on some basic core standards.

Quayle: And if we are going to have that direction, how in your estimation do we set those standards so that we can still have the flexibility for technological innovation going forward.  Since that seems to be from past testimony on the consensus building, where we have had some really good innovation, but in the way that you are kind of seeing this and the outlook, how do we leave that flexibility in place so that the innovation can continue to progress.

Probst: What we don't want is standards that suggest everything that we have to do.  But we do need standards, and I listed several of them in my written testimony.  Basic, core, foundational IT standards put in place.  If those are put into place, then innovation happens.Then you have Internet kinds of innovation that can occur, ubiquitously across large groups of people.  That's the gist of my testimony.

Now, let's have a look at those "Basic, Core, Foundational Standards" that he referred to, that we need to work on.  My definition of "foundational" is that which you build upon.

1. Standard terminologies.
2. Detailed clinical models.
3. Standard clinical data query language based on the models and terminology.
4. Standards for security (standard roles and standards for naming of types of protected data).
5. Standard Application Program Interfaces.
6. Standards for expressing clinical decision support algorithms.
7. Patient identifiers.

Are they foundational?  Standards terminologies and patient identifiers certainly meet my definition.  What I find interesting is that he doesn't reference transport at all.  Surely, if you were to continue the analogy to the Internet, there needs to be an "HTTP" over which the "HTML" was carried.  Yes, we have Direct and Exchange.  Perhaps Mr. Probst believes these are good enough. 

We do have standard terminologies for problems (SNOMED CT), labs (LOINC), medications (RxNORM) and medication allergies (RxNORM again), and they have been adopted in Meaningful Use.  Yes, we are missing comprehensive standard terminologies for non-medication allergies, and that clearly needs work.

We don't have standards for patient identifiers in the US.  But standards for patient identifiers do exist.  It's not an issue for standards developers, but rather one for Congress (search for "unique health identifier").  That law is still on the books.

The rest don't fit my definition of foundational.  Even so, much of this is work either already done, or in flight.  And [all too] often, driven by the government agency (ONC) that has a mandate to select the standards.

HL7, ISO and CIMI have been working on Detailed Clinical Models for several years.  The ISO work goes back to 2009 and earlier.  Will a mandate increase the speed in which this work will be completed?  I think not.  Any DCM I have ever seen builds on top of a framework of existing standards including a reference information model (either HL7's RIM, or OpenEHR's Reference Model), and terminology.  Yes, this important work.  But foundational?  This is like saying that RDF, OWL and the Dublin Core are foundational to the Internet.

Standard clinical data query language based on the models and terminology?  We have quite a few of these standards already.  Some use OWL, others GELLO, others AQL (OpenEHR), and HL7 is developing HQMF based on V3 and the RIM.  I've written about HQMF quite a bit as it applies to the ONC Query Health activity.  I agree that this is necessary work.  Will a mandate increase the speed in which it is done?  We are now piloting Query Health after several months of consensus building.  I expect these specifications to be ready for consideration in Stage 3.

On standards for security, e.g., roles and naming types of protected data, I would refer Mr. Probst to the HL7 Role Based Access Control Permission Catalog (circa 2010).  Yes, more work is needed here, but probably more so in the case of PKI deployment.

With regard to standard programming interfaces, perhaps VMR or CTS2 might excite him.  The ONC ABBI project is building a RESTful API to provide patients with access to their health information.  HL7 has also developed FHIR which might meet some of what he is looking for.  I expect the ABBI specifications to be ready for consideration in Stage 3.

Clinical Decision Support languages is something that I've written about before.  Frankly, I'm much happier using the programming language tool that fits the algorithm that needs to be implemented.  Even so, the ONC Health eDecisions project and HL7 are working on this.  I expect the standards to be ready for consideration in Stage 3.

I'm a little tired of hearing that standards aren't moving fast enough, or that we haven't done enough.  Few people in the Health IT industry have the luxury of spending their full time on standards development.  Even I have responsibilities outside of my standards work.  And I know from experience IN OTHER INDUSTRIES, that no other industry moves any faster with respect to the development of standards.  I'll probably get hammered by some of my Health IT colleagues for saying this, but it isn't standards development where the pace needs to increase, but rather in adoption and more importantly, in DEPLOYMENT.  I disagree that HIT Community needs 10 years or more to deploy the standards that we have today.

But to be fair, we also need balance.  HHS needs to realize that in order for there to be innovation, as Rep. Quayle so strongly emphasized, there also needs to be time to innovate with the standards we are adopting.  Without that time, the innovation that HHS and our lawmakers are looking for won't happen until after the Meaningful Use program is over, and that would be a shame.

Those who remember the past are condemned to watch others repeat it.

This tweet (and also the title of this post) from a college buddy had me rolling on the floor laughing this morning.

Now that we are past the elections, I suppose it's time that I jump on the post-election post bandwagon.  Having worked on Healthcare IT through several administrations, I find myself somewhat amused by all the pre-election discussion of what would happen to Healthcare IT depending on who gets elected.

What is clear in the Health IT space is that there will be change. The change I see in the Health IT space is a shift towards business intelligence, mobile technology and patient engagement.  Organizations which adopt patient enabling technology, or more cost-effective mobile computing technology or which are more aware of what their information systems know and can tell them will continue to advance.  Those that don't will eventually find themselves in decline.  The changes are driven by consumers, shaped by experts and championed by politicians.

Yes, a change in leadership will have an impact, and it's not irrelevant.  A new leader can advance or slow a trend, but will hardly ever reverse it.  Once the boulder is rolling downhill, the only successful strategy for a leader is to get behind it.  If you are left in front of it trying to hold it back, your choices are to be run over, or to dodge.

One way to understand where we are going is to understand where we have been.  There are good and very obvious reasons for doing that, but with respect to changing administrations, one reason is a bit more subtle.  Every administration will inevitably revisit some decisions of the previous one, retracing many of the steps.  What I'm very glad for right now is that we have a few more years before we have to rethink what we thought through before only to come to largely the same conclusions.

On the Influence of HITsm on HITPol and HealthIT

Last week was a slow one for blogging for me.  I took most of the week off for the July 4th holiday. I took a break from contemplating laws, regulations, standards for Healthcare IT, and instead spent time thinking about what flavor barbeque sauce to apply to ribs, or which kinds of beers go best with barbeque.

Now that my brief holiday is over, I'm back to thinking about standards again.  One of the things that I've noted over the past 4 years of blogging (yes, I've been writing this blog for four years now), is the increased influence of social media on Health IT regulation and standards.

This week I'll be hosting the #HITsm chat this Friday at Noon Eastern Time, and my topics are all related to that observation.

T1:   What #HITsm activities (blog posts, tweets) have been most influential in how you view  #HealthIT regulations or standards?

For me, this post apparently wound up in someone's inbox with the annotation: See risk #1.  It was one of the most influential I'd ever written in terms of directly measurable consequences.  I've not been the only person to write a post with such impacts.   Many others have as well.  What are some of your most influential posts, or which have most influenced you?

T2:  Where do you go these days to get your news first?  Do you use Zite or Flipboard or other apps?  How do you configure them?

Social media is often days ahead of mainstream news (and also more accurate than some).  How has the use of social media influenced you with respect to current events in HealthIT?  The first regulation I ever read in earnest was the HIPAA Privacy and Security rule over eight years ago, long after it came out in final form.  These days, I'm notified of relevant proposed regulations the moment they hit the wire, and have often read and posted on them before the mainstream media.  How has access to up to the minute, breaking news and analysis in Social Media affected you?  Does it make you life easier or more difficult?

T3: How has government involvement in #HITsm changed your outlook about #HealthIT regulation and implementation?

The US Government has been experimenting with twitter, blogging and other Social Media activities.  Do you read any government blogs?  Which ones?  Which government tweeters to you follow?  Do they follow you back?  Do you feel like it's easier to be heard because of #HITsm? Do you follow the HIT FACA meetings via live tweets?

I truly love it when I write a post targeted to someone in the Federal sphere and they tweet a link to it.

T4: What got you involved in #HITsm?  What made you stay?  How is it different from other media forms?

I started this blog to avoid repeating e-mails, and make answers searchable on the web.  I got started on twitter to chat with friends, but started my second twitter account to promote my blog, and stayed involved because it really worked.  What got you started and keeps you engaged?

Crashing a Party

June 5th Update: Click the link for a summary of what happened at this Not so Secret White House Meeting with e-Patients.

---

Today I get to do something really cool with my eldest daughter Abigail.  She's been learning from me how to be a patient for some time now.  Today, she's sitting in a room in the White House Conference Center with Dave DeBronkart, Regina Holliday, Hugo Campos, Farzad Mostashari, Todd Park, Peter Levin, Lygeia Ricciardi and quite a few other notables.  Literally a who's who in the zoo of patient engagement at the international and national level.  How she and I got to be here is an interesting story.

It starts with a reunion of The Walking Gallery that is happening this evening.  When I found out when it was, and checked calendars, I realized that this was the opportunity I had been waiting for.  So I reserved two places, and got my daughter and I airline tickets to go.

Abby had started following Regina on twitter the day she saw my jacket.  She's been wanting to be part of the movement ever since she heard Regina's story. The story behind 73 cents is that powerful.  My family and I made a point to stop by the mural the last time we were in DC together.

When I told Abigail she was going, she was thrilled.  She began designing her jacket a couple of months ago.  And now she's showing off her latest piece of fashion at the moment, which is hot off the racks from the most fashionable patient designer in Washington DC, to some of the biggest names in the movement in the US.

We had a minor edit to the design last week though.  A few days ago, an e-mail about one of her parting comments gained quite a bit of attention over at e-patients.net.  So much so that Abigail and Regina decided that it needed to be added to her jacket design for Epic Win! which you see to the left here.

Abby tells us a bit about her jacket:  "There is this imposing figure, saying "I'm going to fight for this.  It's important."  The Eagle represents America, we fight for what is right.  The owl is about wisdom and understanding.  He's got a box of medical records next to him that he's getting ready to read.  The swirls just keep going.  This is not a battle that is going to end.  We're not going to give up until we've got it right, until we've got what we want.

Check the box was just something I said at the time without thinking about it.  I didn't really know what it could mean.  But it was a really cool idea.  What if you really could do this, to say "I want to be engaged, help me do this!"  Check the box is about patients wanting to help, to take care of themselves.  Choosing to be engaged."

Abigail is here to learn.  She spent an hour on the phone yesterday with Dave and I talking about Patient Engagement, and Healthcare Standards.  We brought Dave's world and my world together on the speakerphone, while my daughter listened on, fascinated and confused.

But how did we get here?

A few weeks ago I got an e-mail that started off something like this...

On behalf of the White House, the Office of the National Coordinator for Health IT within the Department of Health and Human Services, and the Department of Veterans Affairs, I invite you to participate in an expert roundtable that will propel patient access to health data forward by identifying and prioritizing areas where technical standards and best practices are needed. ...

It was signed by Todd Park and Farzad Mostashari.

I was thrilled... then disappointed when I recalled that I had no travel budget for this trip, and it was probably too late to get an exception.  But then I realized that I would already be in DC that day with my daughter.  I explained the situation to Farzad via a Twitter DM, and asked if she could come to.  She was offered a seat as an observer, which I'm been given to understand are very hard to come by.  So Abby is "crashing the party".

How did I get here?  I'm not exactly sure, but it might have something to do with a discussion I had with Lygeia at HIMSS on educating children, or it might have been some work on Query Health, or it might have been ... who knows?

It's nice for me to not have to crash the party.  But just in case, I think I'll print out a copy of my invitation...

     Keith

P.S.  Do you want to hear something really funny?  Abby knows what the National Coordinator does, but when I had to explain "Chief Technology Officer", she didn't quite get it.  But when I told her who his boss was, she thought that was pretty cool.

Medical Imaging Exchange

As anyone in the imaging market knows, the medical imaging market is not dominated by any vendor even if it quite a bit less fragmented than the EHR market.  Look at these reports on PACS and modalities (e.g., X-Ray, CT, MRI, Ultrasound, et cetera).  It's fairly common for an organization to have one vendor's PACS solution, another's modality, and a diagnostic workstation from a third.

The reason that these different systems work together inside an institution is because they adhere to the DICOM standards.  But there is a little bit more to it.  It is also because someone has taken the time ensure that they are configured appropriately to work together.  Once you get outside the walls of the organization though, you need more attention to interoperability.  The number of systems you want to be able to work with is even broader.

Let's look at a common use case (the one that John Halamka wrote about earlier today):  Getting an imaging study done, and having it be used at a different organization or facility.  The most common mechanism for exchange of the study is to create a CD.  Every time a family member of mine has had a significant imaging study done, we ask for the data on a CD before we leave, and we know to do so as early on as we can to simplify our lives.  Every CD I have ever received has included a viewer on it.  Only one included both Mac and Windows viewers.  Others just included a Windows viewer.  Those viewers are not meant for diagnostic quality viewing.  They are really just simple programs that allow a provider without any other viewing technology to see what is on the CD.  Any provider that I've ever really needed to give a CD to has had better viewing technology than what was on the CD.

Importing a CD from a foreign institution is not 100% successful, because not everyone complies with the  standards.  David Clunie (considered by many to be the father of DICOM) talks about this in a paper he presented at RSNA in 2010.  Most of the CD import failures are attributable to NOT following the DICOM standard, or other relevant specifications. The Great Aussie CD Challenge (pdf) tested more than two dozen CDs in 2007 for standards conformance (an eternity in Internet years), and came to similar conclusions with regard to conformance.  I'd love to see a more recent repeat of this exercise, using newer technology because the situation has improved (PDI was first introduced as an IHE profile in 2005).

This study showed that nearly 80% of CDs can be imported successfully.  There are standards and profiles which could improve the success rate (and which were used in the CD challenge previously mentioned).  The IHE Portable Data for Imaging Profile was strongly recommended by this Johns Hopkins study, in Australia (as a result of the challenge), and by the AMA.

This report shows the number of organizations that support PDI in their products.  It is an amazing list, which includes all of the vendors previously named in the market share reports at the top of this post.
What it doesn't show and is even more important is how many provider organizations are actually using those capabilities. As Dr. Clunie's paper indicates, it is very likely that organizations aren't configuring their systems to USE the AVAILABLE standards and profiles.  One question that they need to address is what the value is for them to do so.  As John Moehrke points on in this post from last year, getting your "Damn Data" seems to require a mandate to do so interoperably.  This isn't an implementation issue with respect to standards, but rather a deployment one.  I've implemented PDI in 2008, and actually done so over top of the XDS-I specifications.  It was one of the simplest standards-based integrations I've ever done.  Getting someone to want to use it?  That's a different story.

Exchanging data on CD isn't ideal.  There are a number of issues beyond dealing with the data in a standard format that also have to be addressed, many of which Dave Clunie points out in his RSNA slides.  Others are addressed in this 2008 Radiographics article by Mendolson and others.  These include things like patient identification, translation of procedure codes used at different organizations, bandwidth and storage issues, et cetera.

Ideally, you'd think it would just be a matter of transmission of the study from the organization where the study was done to the organization where it is going to be reviewed.  Pragmatically, that doesn't work where we live because the value of that "network" isn't perceived by anyone other than the patient, unless the imaging center and the reviewer are somehow financially connected. Payers do see the value, and where I live, the possibility that a payer network would be established to support such an imaging exchange is certainly viable, but has yet to be realized.

Point-to-point exchange (e.g, via Direct) wouldn't really have worked in one case for one of my family members, because we didn't know who the specialist who was going to perform the surgery was until long after the image was taken (but reading the CD was really simple).  You need something like the network in Philadelphia and New Jersey, or in Canada described in the Radiographics article above.  These networks are built upon the IHE XDS for Imaging protocols.  Both IHE and NEMA are also working on the next generation of web-service enabled protocols to support more advance image sharing.

John Halamka proposes the use of The Direct protocol to exchange images.  The Direct project was designed to support clinical data which is several orders of magnitude smaller than imaging study data.  This article documents the size of some typical imaging studies (see Table 3).  These range from 15Mb to as much as 1Gb (for CT Angiography).   Moving forward into the world of advanced digital imaging for pathology, you could get into the terabyte range (that's more than a 1000 CDs, a hundred DVD's or a double handful of Blue-Ray disks).  Clinical data, such as that in a CCD takes from a few Kb to maybe a couple of Mb if someone has abused the standard to provide a full data dump.
 
Anyone who's had any experience sending multi-megabyte files over e-mail will probably realize the limited viability of Direct for anything other than simple studies (e.g., X-Ray or Ultrasound).  The reality is that providers using the "simplest of EHR systems" probably won't have the storage capacity available to deal with medium-to-large studies.

One of the rationals for the way DICOM is structured is that you don't need all the data all of the time. Studies are large, but what the provider often needs to view is much smaller.  The tie-in to transport in the DICOM standard was to address this issue, and transport only what is needed when it is needed for viewing.  That's a much more efficient use of network bandwidth, and still gives providers what they need, which is, according to the AMA, access to the complete diagnostic quality study data.

With regard to proprietary data, and viewers:  There is no need to physically separate proprietary data in the image stream, but there is a need to tag it so that a "vendor-neutral viewer" can process the data, and DICOM does that.  Every proprietary data item in a DICOM conforming object is clearly tagged as such, and if you read the Vendor's DICOM conformance statements, those tags are documented.  And if they conform to IHE's PDI profile, they will also have a DICOM conformance statement.  If the system conforms to the DICOM standard, you don't need to understand the proprietary data to view the image.  There are really good reasons why some systems use proprietary data, and store it within the DICOM study.  But that data should not impact a standards-conforming viewer.

We don't need a new standard to address most of what John complains about in his blog post.  What we need is for organizations to actually USE the standards which are already widely available, and to configure their systems to do so.  That would address a large part of the existing problem.  Canada has certainly shown with their deployment that XDS-I works for regional imaging exchange.  Regarding the companies that John mentioned on his blog, all three support XDS-I in their solutions.

The one case where a new standard is needed is in the interchange across distributed networks of DICOM study data.  That is work that DICOM has already started.  I should note that the DICOM standard applies to regulated medical devices. I will happily leave the development of the new DICOM standards to experts in diagnostic imaging.  I don't think throwing a lot of non-expert volunteers at the problem will make that work go any faster, or produce better outcomes.

   Keith