Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Wednesday, May 30, 2012

Applying SOA Governance to the NwHIN

It looks like it's NwHIN Governance week here on the blog, my apologies to those who have other interests.

Having been gifted with a 663 page book covering principles of SOA Governance, I'm now seeing if I can apply the material to ONC's NwHIN Governance RFI.  I'm probably insane to try this as Arien Malec points out:

He is so right.  There are a lot of impedance mismatches here, but also lots of common features.  Methodology has to vary, but many of the same problems remain, so I'm going to see what can be borrowed anyway.  Of course, there's not enough time to do real justice to this application, but here's what I've learned thus far:

The SOA Governance definition of governance as a meta-decision system is useful (as I mentioned yesterday).  The four components of precepts (principles), people, processes, and metrics are applicable.  People needs to be extended to organizations because we are no longer within a single enterprise.

Precepts can be structured in the form of objectives, policies, standards, guidelines and metrics.

Starting with objectives, I went back to a set of core program objectives for ONC, Health Exchange and NwHIN that are already well established (and even have a well-defined governance process for adoption and revision).
  1. Achieve Adoption of Health Exchange (We could probably skip this one as it is obvious).
  2. Triple Aim: Improve Care, Improve Population Health, Reduce Costs
  3. Inspire Confidence and Trust
  4. Empower Individuals
  5. Achieve Rapid Learning
In fact, the CTE's in the RFI clearly descend from either #3, #4 or #1 above.  I think #2 has to do with the CTE prioritization process, and it isn't clear where #5 fits in yet.  But these are high level program objectives, not (as I discover quickly) the detailed objectives serving to establish precepts of governance.  So I need to dig deeper.

SOA Governance talks about the Governance Program Office.  That's a useful construct.  I've used the term "NwHIN Governance Authority" (NGA) elsewhere to talk about the same construct.  The NGA is responsible (and has the authority delegated through ONC) to develop and manage NwHIN Governance.  It can ensure that governance is aligned with national goals through alignment with incentives and regulatory processes.  It will need to collaborate with other stakeholders involved with the NwHIN, which leads to a federated model of Governance over the NwHIN.  That's probably the only model making sense in an ultra-large scale system.

Some stakeholder groups may be delegated responsibility to deal with certain kinds of exchange, so long as they adhere to an overall set of principles (see my previous post for some details on what those might look like).

The first step that the NGA must take on is development of the precepts.  I have some ideas as to what those might be, and existing work already applies.  In fact, using that, and the ONC program objectives to Reduce Costs, Inspire Trust, and Achieve Rapid learning, I have precept #1.  This is really just an example of what a precept could look like from NwHIN Governance.

Objective:  Where existing governance processes already exist in the market, NGA shall seek to use these, improving them where necessary by closing gaps within its own scope of operations and by participating within governance of external organizations.
Policy:  The NGA will use procedures already adopted by industry for creation or adoption of standards, policies or practices where available.
Policy:  The NGA will provide input to organizations developing standards, policies or procedures to faciliate alignment across industry.
Standard:  Standards, policies or procedures adopted by the NGA shall be created through existing consensus standards bodies or voluntary collaborations by those bodies, using the procedures established by those bodies for the creation, consensus development and implementation of standards.
Metrics: Number of Standards, Implementation Guides, et cetera, which are reused by NGA.  Number which are created at the behest of the NGA.  Number which cannot be created outside the NGA due to lack of interest or other issues.  Governance changes of other organizations requested, adopted, unadopted.

There are a lot of other principles that need to be established, but developing these is not something that occurs in a single brain overnight, fully-formed.  I have a few thoughts, organized loosely around the SOA project life-cycle:
  • Adoption Planning -  What CTE's should be included in NwHIN and how we prioritize them
  • Inventory - What are potential sources of CTE's and how we find them
  • Assessment and Risk Analysis - How we  objectively compare what exists against CTE requirements 
  • Development -  How a CTE is developed in collaboration with NGA
  • Testing - How a CTE is attested, tested, and/or certified, and what level of assurance is required.
  • Deployment and Maintenance - (Self Described) 
  • Usage and Monitoring - How effective are CTE's in the wild
  • Versioning and Retirement - (Self Described)
A lot of the effort can take place outside of the NGA (See Precept #1 above).  The key things that the NGA is responsible for are in bold above.  Everything else can probably be delegated to other bodies.

In tomorrow's post, I'll discuss one possible way of accessing the SDO landscape from the NGA for the purpose of developing some CTE's.  It won't cover policy/business practices because I'm a standards geek, not a policy wonk, but I think a similar principle could possibly work there too.

1 comment: