The US Realm Authority

The US Realm is something that I've been on about for a while (see this and this to start with), and some of my more recent thinking on this topic crystallized during the HL7 Working Group meeting after release of the NwHIN RFI.  One of the problems with the NwHIN RFI is that it needs a way to develop specifications, policies, et cetera, that it can incorporate into CTEs. 

What appears below is a straw-man proposal for one way in which we could establish a US Realm.  Note that the US Realm is NOT THE SAME as the NwHIN Governance Authority, but clearly plays an important role with respect to the NwHIN and its governance.  In fact, the NwHIN can delegate much of the operational portion of creating and identifying standards, and validating implementations to the US Realm Authority.

This simple image above shows many (but not all) of the possible stakeholders in a US Realm Authority.  All possible stakeholders would not readily fit onto one slide.  You might argue I've included some that shouldn't be present, or missed others that should be.  That's not the point.  If you can identify organizations that should be added, feel free to comment.  If there are organizations that shouldn't be present, tell me (and my readers) why.

With a few exceptions (Governmental Organizations and some testing bodies), most organizations are membership-based.  Private organizations representing specific healthcare providers, vendors, payers, et cetera also have a stake in the US Realm, but can be represented through the stakeholders shown above, and by so doing, we remove some of the dangers and possible accusations of dominance that could be perceived.

Note that the NwHIN Governance Authority is separate from the US Realm Authority.   The US Realm Authority for Health IT assumes broader scope than that of the NwHIN.  Other laws and regulations govern the use of Health IT and standards in addition to those granted ONC under the HITECH Act (e.g., the Social Security Act for one).  Separation of the NwHIN Governance authority allows a structure to be created that can support broad Health IT standardization without exceeding the scope of any single mandate.

Classification of Stakeholders

There are six different classes of stakeholders represented in the diagram:  Government, Medical Professionals, Consumers, Industry, SDOs and Validating Bodies.  Stakeholders are classified by either:  Who they represent (Government, Medical Professionals, Consumers or Industry), or what they do (SDO & Profilers and Validation & Testing Bodies).   Industry includes both Payers and Health IT Vendors (the distinction between those is beginning to blur). Many organizations could fit into more than one classification based on what they do.  For example, IHE, CAQH/CORE, and Continua create specifications and validate conformance to them.  HL7 creates standards and certifies developers that implement them.

 Structure of the US Realm Authority

The US Realm is made up of member organizations similar to those listed above. The Board is made up of representatives of each of the groups shown above, and includes representation from appropriate segments within the categories (e.g., physicians, nurses, and information management professionals; payers and Health IT industry; etc.).

Members pay a nominal fee for membership (e.g., $2000) which demonstrates their commitment to the US Realm.  It covers some of the costs of operations, but is not so large as to make membership an obstacle to participation.  The US Realm has two operational committees addressing Requirements and Architecture. Delegates and alternates to these two committees come from each member organization, and should be selected using a process that is representative of the organization’s membership (for membership-based organizations).  These committees review and make recommendations on proposals for the development of specifications addressing security and privacy, interoperability and policy.

Committees may create workgroups focusing on specific topics or areas of expertise, and may delegate review to those workgroups.

Project Sponsorship

Proposals are created through a sponsorship process.  Any organization (member or non-member) can sponsor a proposal to the US Realm via submission of appropriate proposal details and a nominal sponsorship fee (e.g., $5000).  The sponsorship fee demonstrates commitment to the proposal development process and goes towards the management of the project if it is successfully awarded.

Proposal Process

A proposal is submitted to the US Realm with appropriate details, including scope and deadlines for delivery.  It is reviewed with the sponsor by the Requirements committee to ensure alignment with US Realm goals, and to flesh out requirements of the proposal.  It is also reviewed with the sponsor by the Architecture committee to ensure technical feasibility of the proposed deliverable, and to ensure technical alignment with existing efforts.  Upon acceptance by these committees and the sponsor, the proposal is submitted as a Request for Proposals to the member bodies.  If rejected for reason by Requirements or Architecture committees, or if the final proposal does not meet the needs of the sponsor, the proposal fee is refunded to the sponsor (encouraging the US Realm to come up with workable solutions).

Contents of a Proposal

A description of the problem to be solved.  A collection of required items necessary to meet the needs of the proposal.  A collection of optional items are nice to have, but which are not necessary for a solution.  A collection of issues which are to be addressed in responses by respondents.  Evaluation criteria by which responses will be judged.

Proposals may include requests for development of: Standards, Policies, Education, Certification Criteria, Pilots, Reference Implementations

Proposal Responses

Member organizations have some time period (e.g., 60 to 90 days) to respond to the RFP, with a response that addresses the requirements of the RFP in whole or in part.  Members may work with other member bodies in development of a response to the RFP, and are encouraged to do so.  Responses are evaluated technically by the Architecture committee, and with respect to requirements by the Requirements committee, in conjunction with the sponsoring organization. The responses are developed into a final project plan, which may or may not contain all components proposed by the responders.  All responders need not be awarded components in the project plan.  The project plan must be agreed to by the responders who are being asked to deliver components, the sponsor, and a majority of the architecture and requirements committees of the US Realm.

If agreement on a project plan cannot be reached, the sponsor’s proposal fee is retained by the US Realm (encouraging sponsors to commit to a solution).

Nothing prohibits a sponsor from funding resources to develop responses within member bodies in addition to sponsoring a proposal.

Project Execution

Upon reaching agreement with the sponsor and awarded responders, the project commences, and is managed by the US Realm and performed by the organizations awarded various components of the plan.  The sponsor pays a management fee to the US Realm to cover necessary management activities for the project, including coordination across member organizations, organizing meetings of participants, et cetera.  The project management fee is set based on the project timeline and size.

The US Realm will assign one overall project coordinator and may appoint additional project facilitators to support various components of the project.  The project coordinator will report monthly on the status of the project to the project sponsor and the board.