Tweet

I've been using twitter for quite a while now to communicate with close friends in the standards world. Because I like to see what's going on elsewhere in Healthcare standards, I also started following several healthcare standards tweets and newsfeeds. That's gotten me a number of requests to follow me on twitter, except that my tweets on that account are intended to be personal and to a select group who understand my humor and sarcasm.


So, just like I have a private and public blog, I now also have a private and a public twitter account. If you want to follow my public twitter posts, just follow me here: http://twitter.com/motorcycle_guy. You'll get links to my latest posts from this blog, as well as the occasional short message.


The number of different ways that I communicate electronically:

1. Work e-mail
2. Personal e-mail
3. Public Blog (http://motorcycleguy.blogspot.com/)
4. Private Blog (I use Live Journal)
5. Private Twitter
6. Public Twitter (http://twitter.com/motorcycle_guy)
7. Facebook (used just so I can view others Facebook posts)
8. Work Blog
9. IHE Wiki
10. HL7 Wiki
11. Work Phone
12. Cell Phone
13. Home Phone
14. Skype (while traveling only)
15. Linked In
16. Google Groups


Can you say information overload.

IHE Profiles and HL7 Conformance Testing Tools

This week I'm reviewing a new introductory HL7 Version 2 class that we've been developing for internal staff and our customers. We've had quite a bit of help from staff and volunteers at HL7 in the development of this class, thanks to Karen Van Hentenryck of HL7 and Peter Rontey of the Veterans Administration.

One of the tools we run through in the class is the HL7 Messaging Workbench. This tool can be used to sniff and parse HL7 messages and validate them against an HL7 Conformance profile. It can also be used to create a conformance profile. One of the things that I'd like to see the IHE Testing and tools committee do is to develop appropriate conformance profiles that can be used inside this tool to validate instances of HL7 messages. This would enable people to use the common HL7 Version 2 tools to test implementations of IHE profiles. Numerous profiles from IHE use these messages, including PIX and PDQ from the IT Infrastructure Domain, LWF (Laboratory Workflow) from the Laboratory domain, and SWF (Scheduled Workflow) from the Radiology Domain.

After we create the conforming message profiles in IHE, we could also register them with the HL7 Version 2 Conformance profile registry. This would enable people to quickly find and download the material and use it to test IHE profiles.

Finally, we can make use of the NIST developed Message Maker tool to support generation of test messages according to the published conformance profiles.

If you haven't looked at these tools, and you need to test HL7 messages, you probably should. You can find these fairly easily on the new HL7 Web Site. At the new home page, click on Tools in the Participate box. On the Tools and Resources page open V2 Tools in the tree. By the way, if you are looking for Messaging Workbench, you can find it under the name "Project Workbench".

A triangle has three sides

A triangle has three sides and three angles. Because of several properties, It is necessary and sufficient to know only:

• The lengths of the three sides, or
• the lengths of two sides and the measure of the interior angle, or
• the length of one side and the measures of two other angles and their relationships to that side.

Which of the above is the best model for the triangle? This question has no correct answer.

The complete model of a triangle includes the measure of the three sides and of the three angles. Any model which functionally supports the exchange of sufficient information to determine these features is an adequate model, and functionally equivalent to any other model. The only value one model has over another is its ability to be expressed and exchanged based on available information. If I tell you the three sides of a triangle, can you readily compute the three angles? If you remember more trigonometry than I do, possibly, but if not, then no. If I gave you two sides and the interior angle, and you remembered the formulae for cosine, sine, and tangent, you might be able to derive the formula for the third side, and the two other angles. So, given the context of a limited amount of trigonometric ability, the better transmission might be two sides and the interior angle.

A similar example appears in the expression of the Interval data type. An interval has a start, end, middle and width. It is only necessary to know two of these to establish the correct values for the other two. What is the best model for transmission of this information? This question also has no correct answer without some sort of context. If start and end are commonly available data items, then why transmit anything else. In fact, I find it rare to see information system that deals with intervals as anything other than start and end point in time. The second most common model I find is start and width. I use the convention that all intervals are communicated using start and end, UNLESS only width is known, in which case, that is the only attribute transmitted. This leads to very clear and unambiguous communication. Computationally, I only need to do arithmetic, so I don't even care about how much math is necessary.

Moving one layer up, a similar case appears when dealing with the patient, subscriber and payer participants in a policy act. This is another case where we have a three way relationship. The patient is related to the payor through a subscriber by virtue of the policy. There are implicit or explicit relationships between each of these entities. The patient is a member of the policy. The subscriber is related to the patient. The payer has relationships with both. It is only necessary to know: The relationship between the patient and the subscriber, and the subscriber and the payor to determine the third relationship, between the patient and the payor. Once again, the question of which model is best is specious. The complete model includes all three relationships connected by the policy.

Most HL7 models do not typically include all of these relationships. However, this is extremely useful domain knowledge. This is not just a flaw in HL7, but appears within other standards as well, including those competing standards.

It would be useful to show these relationships within HL7 models more completely. I'd like HL7 D-MIM diagrams to reflect this domain knowledge directly. This would enable more complex decision support because the domain knowledge could be used to infer relationships that can be determined by available data.

At the rim of the dam or the edge of a precipice?

One of the joys of HL7 Version 3 are the many different ways that you can say the same thing depending upon the context of your message. Let's look at a laboratory test result for example. Using the HL7 RIM, this will be encoded as an observation. Using the 2008 Normative Edition there are at least 7 ways within the published standards to say the same thing. These seven different ways appear in the following HL7 Version 3 standards:

1. Care Record
2. Clinical Genomics Pedigree
3. Clinical Document Architecture
4. Clinical Statement
5. Common Message Element Types
6. Public Health Reporting: Individual Case Safety Report
7. Periodic Reporting of Clinical Trials Laboratory Results

The picture below shows how these HL7 standards support this concept slightly differently in each case.



I've shown how the names of the XML Element, and the constraints on the content of the Observation class vary using a bold red font, or where the RIM attribute is missing, a red background. You can get view the same thing here in this PDF.

Each standard has constrained the HL7 RIM Observation class differently. Arguably, there's a reason for this, but I challenge anyone to determine why. I can certainly accept that each of these standards had different requirements, and therefore constrained the model of observation differently. But nowhere in the standard are these specific requirements expressed.

One conclusion that you could draw from this collection of variances is that no one body is in charge of HL7 standards. Another conclusion that you could draw is that the development process doesn't enforce concistency across HL7 domains. Another is that by failing to document requirements, we are allowing our modeling efforts to introduce unnecessary inconcistencies across domains. All of these are fair challenges to the HL7 development process.

I would propose two changes to the HL7 development process to improve the situation:

Provide Architectural Oversight

HL7 has an Architecture Review Board that was reconstituted a bit more than a year ago. The group's charter can be found here. The Technical Steering Committee was also restructured not too long ago, and it's charter is here. From my perspective, the TSC provides strategic direction, the ARB tactical. I would hope that both these groups would be involved in helping to move HL7 in a direction where these kinds of inconcistencies eventually either dissapear from our work products, or can be explained based upon requirements.

We are currently in the process of some strategic realignment within HL7 (i.e., the thing formerly known as SAEAF). I'd like to see some of that realignment pay some attention to how different views and levels allow us to bring more consistency to the HL7 standard. We have to many artifacts pushing towards implementable messages that should be a a higher level of specification.

DICOM has Working Group 6 whose role is to "maintain the overall consistence of the DICOM standard". While working group 6 it is arguably a choke point on the development of the DICOM standards, I am not one to argue that having more standards is better. I'd rather have better standards. I think we need something more like that within HL7.

Make requirements Mandatory (or at least strongly recommended)

I've seen other standards organizations include a stage for formal requirements definition in their process. We could certainly ballot requirements in HL7 as informative documents prior to undertaking any large project. The HL7 Templates work group is presently developing Business Requirements for a template registry. I'm finding that effort to be very interesting, and the end results will be extremely useful.

None of us would undertake a 6-18 month software development effort without requirements. Yet all too often I see our own standards development efforts do exactly that. We mistakenly assume that usecases (storyboards) will cover it, or that the D-MIM is sufficient. The D-MIM should be a realization of the domain analysis model. The domain analysis model should be a reflection of the requirements of the domain. If we don't understand the requirements of the domain (or at least the subset we are playing with), then we don't have any business trying to develop standards for it. If we do understand these requirements, then documenting them should not be difficult.

All too often engineers want to get right to coding, or in the HL7 world, into modeling. Having stated and agreed to requirements will help to set the scope for the development effort. If the models are derived from and expressions of requirements, let's see the requirements. It would be a lot easier to validate a model if I understood the requirements that drove it. Most of the time that I have negatives on a ballot it is because the model doesn't meet my requirements. So, let's put in more effort up front. If we do it right, developing the model should be a cake walk.

Requirements are reusable design artifacts. Having developed and documented them once, you can use them over an over again for similar cases. Having them documented means that you don't have to have the same arguments over again about why X, Y or Z should be included into a representation. I would be able to look at inconguencies in the use of the Observation class in the above standards and trace these back to specific requirements.

SOAP vs. REST and Common Data Transport

Recently there's been several discussions across many fronts on Common Data Transport which has re-energized the SOAP vs. REST debate. Although I don't specialize in infrastructure, I have developed both SOAP and REST-ful web services and would like to add my observations.

Arguments for both abound:

For REST-ful web services:

• can be called by a web page
• can be called from an XSLT Stylesheet (a restatement of the above, but with really useful ramifications)
• are easy to implement using off-the-shelf programming languages and libraries. A REST-ful webservice call can be implemented in a page or less of Java code in a single class.
• Can also be implemented using web page technologies such as ASP, JSP, PHP, et cetera.

SOAP Web Services:

• Have standards based and machine readable interface definitions (WSDLs) that can guide code generation. Most application development frameworks support SOAP.
• Support strong data typing in the information exchange.
• Support routing of web-service calls.
• Layers security into the protocol (e.g., WS-Security)
• Supports reliable messaging
• Are already supported by many healthcare standards

As usual when selecting tools, I would suggest that you select the right tool for the job. Let's take a specific example. Recently IHE created a specification for Sharing Value Sets. This specification is intended primarily to support an EHR's access to a collection of coded terminology. The profile oroginally suggested SOAP, and for various reasons, continues to include SOAP as part of profile. Some of these reasons are based upon the strengths of SOAP, which include the standards-based interface definition, strong data typeing and layering of security that are not readily addressed by REST.

However, there is one use case where this service can strongly support testing efforts that demands a REST-ful interface. IHE uses Schematron to test conformance of content to a specification. Many schematron implementations rely on XSLT. The interfaces defined by the SVS profile cannot easily be called if they support only a SOAP interface. The resolution by IHE was to support both REST and SOAP in the profile, and in noting that this was a "secondary" use of the profile, made REST an option. This was an easy decision because we obtained the benefits of both protocols for the different use cases, and the requirements of the two use cases were in fact different. The latter use did not have as strong a need for security or routing of the request. Testing efforts are done in a very different environment as is loading of vocabulary subsets into production EHR systems.

Yes, SOAP is more complex than REST, but with that added complexity comes added capability not present in the REST-ful framework.

My own answer to this debate is similar to the answer I give on any "religious war". My father told me regularly to pick the right tool for the job. Not everything is a nail, screw or bolt, so you need to have a toolbox that contains hammers, screwdrivers and wrenches. The guidelines I learned from my father were Hammer to nail, screwdriver to screw and wrench to bolt. Yes, you can hammer in a screw, or use a wrench to pound in a nail, but I've rarely been successful in tightening a bolt with either a screwdriver or a hammer -- for that I need at least a pair of pliers, and if I want it to stay fastened, a wrench.

The whole notion that there is "one-best-way" to communicate information flies in the face of everything I've learned over the last 40 years about tool selection. What is needed is not a common data transport, but rather, a common set of guidelines that we can use to understand how to best select a transport method for the problem at hand.

Coordination?

There are days when I feel as if I'm at the butt of some massive Federal joke. This is one of them. My day started early to work on completion of some pending IHE publications, when I recieved an e-mail titled CORE Problem List Subset of SNOMED CT® Now Available the content of which you can find in the link. This is great work, but isn't coordinated with the national agenda around interoperability.

ANSI/HITSP has already selected the VA/KP Problem List Subset of SNOMED CT® which contains the controlled terminologies identifying problems used for medication labeling. This was felt to be a good subset by ANSI/HITSP since it clearly identified a set of problems required for patient care.

If you've clicked both links you probably can understand my frustration, given that these overlapping subsets are both available through the National Library of Medicine.

The rationale for creating the CORE subset was, I understand, to create a smaller subset of SNOMED CT® that could be used by institutions that want to get started with SNOMED CT®, but did not want to deal with the entire terminology. I'm pleased with the rationale, however, the end result is that now there are two subsets of SNOMED CT®, both created with the assistance of Federal Agencies (VA and FDA for the first, and NLM for the second), which overlap. This creates a massive interoperability problem in the use of SNOMED that ANSI/HITSP will spend in my estimate at least 400 committee member hours of time upon.

How is one to harmonize these two within ANSI/HITSP? I see two options: 1) create a new subset that is the union of both, and 2) create a new subset that is the intersection of both. Neither of these is desirable. The former creates a bigger subset that does not meet the requirements of institutions that wanted as smaller subset to begin with, and the second creates a subset that is about 70% smaller in size that the CORE subset, and doesn't allow the full detail of problems associated with medications to be exchanged.

Why should ANSI/HITSP be required to resolve these issues. Don't we have an office somewhere nationally that can coordinate these activities? This should not be a problem that ANSI/HITSP needed to solve. Instead, this should have been coordinated as part of a national strategy for the use of SNOMED CT®.

I realize that the current Office of the National Coordinator under HHS is not responsible for creating this problem, but I would certainly like that office to resolve it.

Here is my back of the napkin proposal:
1) Create an NLM Project to support the maintenance of the SNOMED CT® subsets used for federal programs.
2) Include within this project the requirement for managing the subset used for medication labeling.
3) Include within this project the requirement for managing a smaller subset that can be used for healthcare interchange.
4) Ensure that the entire subset is available under the same terms and with the same ease of distribution as the VA/KP subset is presently.
5) Ensure that the technical interoperability issues between the two subsets are addressed (for example, the smaller subset should be able to accurately but less precisely code everything in the larger).

Keith

ARRA: Short Term Tactics or Long Term Strategic Plan

Today I gave a brief presentation to a class covering "Key Standards in Health Informatics" at Northeastern University. While the capstone of my presentation was meant to be the HITSP Capabilities of IS 107, I spent far too much time on my "Brief History" slide to do the HITSP capabilities justice. However, I found that I really enjoyed putting the History slide together and presenting on it. The slide covers some key events over the past 10 years that help to formulate where we are today. My timeline is not complete, I'm missing key dates (e.g., the ONCHIT-1 through 4 RFP dates), and there are significant gaps in other areas, and I could go back even further if I hadn't placed a self imposed 1-decade limit on it. However, it's enough to fill a Slide at 12 point type, which argues that it is already too much. I reproduce the content of that slide below:

Nov 1999

IOM: To Err is Human: Building a Safer Health System

Nov 15, 2001

NCVHS: Information for Health: A Strategy for Building the National Health Information Infrastructure

Jul 18, 2003

HL7 EHR System Functional Model Draft Standard for Trial Use Begins

Jul 31, 2003

IOM: Key Capabilities of an Electronic Health Record System

Apr 27, 2004

EO 13335: Incentives for the Use of Health Information Technology and Establishing the Position of the National Health Information Technology Coordinator

Jul 2004

HL7 EHR System Functional Model Draft Standard for Trial Use Published

Jul 2004

CCHIT Formed by AHIMA, HIMSS and NAHIT (The Alliance)

Jul 21, 2004

The Decade of Health Information Technology: Delivering Consumer-centric and Information-rich Health Care

Nov 9, 2004

ONCHIT RFI: Development and Adoption of a National Health Information Network

Jan 17, 2005

13 Member Collaborative Response (AHIMA, AMIA, ANSI/HISB, CITL, CfH, eHealth, HIMSS, HL7, EHR(V)A, IHE, Internet2, Liberty Alliance, NAHIT)

Sep 13, 2005

American Health Information Community formed as Federal Advisory Committee

Sep 2005

ONCHIT-1 – ONCHIT-4 Awarded

Oct 2005

ANSI/HITSP Founded by ANSI, HIMSS, Booz Allen Hamilton, and the Advanced Technology Institute

Aug 22, 2006

EO 13410: Promoting Quality and Efficient Health Care in Federal Government Administered or Sponsored Health Care Programs

Oct 26, 2006

CCHIT Recognized as a Certifying Body

Jan 2008

HITSP Specifications Recognized

Jan 2009

HITSP Specifications Recognized

Feb 17, 2009

ARRA Passes

Jul 8, 2009

HITSP IS 107 EHR-Centric Release for Implementation

Jul 17, 2009

Meaningful Use Defined

Jul 21, 2009

Standards Committee Meets to Identify Standards for Meaningful Use

I spent a good 20 minutes on this slide showing how we got to meaningful use today. Going through this history you can see how

The IOM 8 functional areas are tied to the HL7 EHR Functional Model, CCHIT Certification Critiera, and the ARRA 8.

The National Health Information Infrastructure became the National Health Information Network

Programs such as CHI and HISB were rolled into ANSI/HITSP.

Executive Order 13335 and 13410 become keys points in ARRA and HITECH, to the point of using almost the same language.

You might find it instructive to go back through some of this historical material for yourself and see where we've been and how it's influenced (or failed to influence) where we are today, and more importantly, where we will be tomorrow. I reread various pieces of these documents today, and found the review to be very illuminating.

Keith

P.S. One of the students remarked during her presentation on ICD-10 that followed mine that "... the costs exceed $1B dollars, but that doesn't sound like so much after hearing Keith speak." I'm not sure what she meant, but I thought it significant enough editorially to include the comment here.

Hello again, it's me, stirring up the pot.

One of the difficulties I have in writing regularly in this blog is that I only have so much writing time in a week, and the last few months have been extreme with regard to the consumption of that time. Another problem that I have is that I've had this blog post article rolling around in my head for the past four months but it's just not ready to come out yet. However, another topic that's been rolling around decided to squeeze it's way past.

As you probably know as a from looking at my blog, I'm a standards geek. I've been involved in a number of activities in HL7, IHE and HITSP and at the pace we are going today, I'm getting ready for the looney bin. Over the last three years the pace of standards activity in the US has picked up at such a pace that I'm reminded of a Frank Herbert short story called the "A Matter of Traces". If you don't know the story, it introduces the Beauru of Sabotage in a small part is played by a Herbert character that shows up in a number of his books, including Whipping Star (which I haven't read), and The Dosadi Experiment (which I enjoyed thoroughly).

However tempting being a Saboteur sounds, the current pace of standards development hasn't quite reached the point of needing such an institution, and I instead have another suggestion to address the pacing, equally appalling to some. If you were at the HITSP panel meeting last week, then you already heard John Halamka's brief pep talk about what is to become of ANSI/HITSP when it's contract expires. Clearly there is still a need for an organization like ANSI/HITSP in today's world, and it would be a waste to throw all that organizational knowledge away. It seems likely that there will be a request for continuation of these activities that the government will have to send out for bid at the expiration of HITSP's contact, and that the organizers of HITSP would be well placed to go for another round.

I agree that we need to retain HITSP, but my current thought is how to deal with it in a new structure that would provide several benefits missing from the current organization. Let me first outline my thoughts, and then discuss some of those benefits.

First of all, I have no complaints about the current holders of the contract, and feel that they are doing a very good job. I'd keep the same crew, but expand the scope a bit. But, how, you ask, does increasting the scope of HITSP reduce the workload that could shortly bring many to burnout. Read on:

The new organization would bring several functions current executed by several SDO, PEO and related organizations under one roof.
* Identifying healthcare standards for national use
* Making harmonization proposals to various SDOs for subequent balloting.
* Representing US interests to international organizations such as ISO, HL7, IHE, IHTSDO, OASIS (and others to detailed to list).
* Promoting the development of US National Standards for healthcare that could be passed on to international SDOs for balloting
* Maintaining US Realm Vocabularies and Extensions to international standards and profiles
* Providing educational material
* Supports Certification efforts through the creation of testing tools.

This is a fairly tall order, but it could be done. Let's look at how many of these functions are handled today.

1. ANSI/HITSP currently is in the position of identifying healthcare standards for use in the US. There are six technical committees and several others that perform non-technical functions (Education, coordination with other organizations) made up of over 400 people, many of whom are involved in multiple standards efforts. The HITSP Foundations committee is strategic, making long term harmonization proposals. This organization meets quarterly for 4 days (3 days face to face, plus one day for the panel). The committees meet weekly consuming about 2 - 4 hours a week.
2. US National interests to ISO TC215 are currently represented by the US Technical Advisory Group (USTAG) to TC 215. This is an organization that is made up of about 20 key members (I participate but not in any key roles), many of whom participate in several other SDO actitivities. Currently this organization meets about 4 times a year for 1-2 days at a time. Let's have the USTAG functions be subsumed by one committee of this organization.
3. US National interests are not directly represented to HL7 in any coordinated way. An HL7 US Affiliate has yet to be formed to perform that function. The role of an HL7 Affiliate organization is to vote on HL7 standards, and be the keeper of the national realm. Details can be found in the current affiliate agreement. The keeper of the realm establishes the realm vocabulary bindings for the HL7 standards and develops realm specific standards localization. Localization is a process which allows the realm to extend or limit the scope of a current HL7 standard to meet realm specific needs. The current de facto keeper of US realm vocabulary bindings is the ANSI/HITSP Care Management and Health Records TC, which has established bindings for use in HL7 standards used in the US. The current de facto promoter of US realm standards development is HL7 itself, a problem that has been especially noted among HL7 international members. There is no organization that can presently localize HL7 standards for US use.
4. US National interests are not directly represented to IHE. IHE is in the process of forming IHE USA. The role of a National Deployment Committee is described in the IHE Principles of Governance document. You will note that a key function of the national deployment organization is to support testing and deployment activities within that country. For the US, these activities are currently executed by IHE International, and testing is very kindly and ably supported by NIST and members of the IHE Testing and Tools committee. IHE testing tools are currently used and enhanced by NIST to support HITSP interoperability testing. Another function of the National Deployment Committee would be to take responsibility for National Extensions to IHE profiles. The current de facto keeper of national extensions is distributed among various committees in ANSI/HITSP.
5. US National interests are represented to the IHTSDO by the National Library of Medicine. This is all very well and good except that these interests are one step removed from standards developers who need to interact more directly with the IHTSDO.
6. Other vocabulary services are provided and managed in the US by the National Cancer Institute (a division of NIH which also manages NLM).
7. Management of the HL7 US Realm Vocabulary bindings is presently under the management of HL7 International because their is no US realm.
8. Some portions of US national interests in standards are managed by ANSI, which according to their web site: "...oversees the creation, promulgation and use of thousands of norms and guidelines that directly impact businesses in nearly every sector..." and "...is also actively engaged in accrediting programs that assess conformance to standards ..."
9. Testing tool developement is currently handled rather ably by NIST for IHE, HITSP and HL7, but could certainly benefit from participation by others.
10. Education is provided by the various SDO and PEO organizations on their work.

As you can see, the workload is rather spread out, in a somewhat disorganized fashion, across a variety of governmental and non-profit organizations. People like me who develop healthcare standards for a living wind up traveling quite a bit (I'm out for more than half this month on three separate trips), and having to coordinate amonst many different organizations.

So, what's the plan? I'm not a business plan sort of person, but I can give a rough napkin sketch of how I'd like to see this problem solved:

1. Some group of non-profits bands together to form a body to accomplish all of these tasks. Current suspects in my mind include organizations like ANSI, HIMSS, HL7, IHE International, RSNA and AHIMA, which all have a stake in this game.
2. They form an organization which has the following arms:
* National Standards Selection and Harmonization
* National Standards Development
* Standards Education and Certification Testing
* Localization of International Standards and Profiles
* Representation of US National interests in healthcare to standards bodies (not just Healthcare standards, because healthcare also needs other standards -- workflow, business process management, IT infrastructure, et cetera)
* Conformance Testing and Tools Development
3. They propose a contract that would involve collaboration with US Federal Healthcare interests (e.g., ONC, NIST, FDA, CDC, VA, DOD, NIH, NCI, NLM, CMS, and HHS) to perform the various functions I described above.

How would we all benefit from this:
1. Administrative functions across numerous organizations would be collapsed, reducing overhead. I would expect an organization like ANSI would play a key role in this area, as they have so ably done for ANSI/HITSP.
2. Coordination and communication among these functions would be vastly improved due their being combined under one organization.
3. Organzations with strong education programs like HL7 and IHE that participate in this effort could extend their expertise in this area. Regional extension centers could take advantage of the reach of these organizations to educate providers on interoperability and standards.
4. Strategic planning could be done in a way that promotes faster development of nationally useful standards and profiles, and would take guidance from the Standards and Policy committees. When strategies are set for these activities independently, it takes a great deal of work of key people to ensure that these strategies are aligned. There have been many tactical failures because of strategic misalignment over the past three years, and more yet to come if we up the pace.
5. The effort and expenses of so many volunteers across so many organizations could be greatly reduced by the increase in coordination and a reduction in necessary travel to work across many of these functions in so many different places.
6. The saved time needed to coordinate across these bodies would be better spent creatively resolving real problems in healthcare, rather than trying to coordinate among disconnected bodies.

How much would this cost? I don't know. I suspect that it would be somewhat in excess of a million dollars a year, but would be less than 2 million a year.
How could this be funded? I believe a substantial portion of this would need to be Federally funded initially. Some of that could be made up through grants by various interested organizations. Some revenues could be retained from fees retained for training and testing activities, but those would likely be break-even or slightly lower than that.
There may be a way to obtain funding by having an annual conference that brings in revenue from outside the membership, but I'm very frankly opposed to having members of this organization pay to travel, spend time to contribute, and then have to pay to participate in the real work. We wouldn't have gotten the participation in HITSP that we did in the last 90 days if there had been a fee to join. If there needs to be a membership fee, it should be very low (e.g., <$100 per person) to make it possible for participation by as broad a stakeholder group as possible. I also believe that the organization should make it possible for students enrolled in accredited programs (medicine or related fields) to participate for free.

There are a lot of details I've missed, and key organizations that I've likely annoyed because I haven't included them in the above list. For these mistakes I apologize in advance. I cannot keep up with it all, and I've only talked about what I know, not what I don't. If I didn't include you, it's not because I don't think you could contribute, I either don't know who you are or how you can, please don't take offense.

I also realize that there's more idealism than realism in this idea. I'd like to see the ideal become real, rather than let reality intrude on my temporary a vision of perfect world. Some day I want to go to my doctor and have him use what we've all worked so hard on. We're so very close.

Any way, if you think this is an interesting idea, don't talk to your local congressman. Instead, speak to the leadership of your SDO, PEO or related organization. We've been pushing a giant boulder uphill from all sides for the last five or so years. I'd like to see us all get behind it from the same direction and crest the top of the hill. If you think the idea stinks, let me know why and let us see if there's a way to make it better.

Time to go back to work, I have two documents to complete before Tuesday...