Healthcare Standards: May 2012

Thursday, May 31, 2012

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.

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:

@motorcycle_guy Insane. Applies intraenterprise framework to decentralized cross-enterprise ULS world.
— Arien Malec (@amalec) May 30, 2012

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).

Achieve Adoption of Health Exchange (We could probably skip this one as it is obvious).
Triple Aim: Improve Care, Improve Population Health, Reduce Costs
Inspire Confidence and Trust
Empower Individuals
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.

Tuesday, May 29, 2012

ONC NwHIN Governance RFI

I've been reviewing the ONC NwHIN RFI on Governance for the past several working days (starting about a week ago). There are some 65 questions that are asked by the RFI, and a few questions that it raised but doesn't ask. The first question that crops up in every venue where I've discussed it is What is the NwHIN?

The RFI states that the NwHIN is: “the set of standards, services, and policies that enable secure health information exchange over the Internet.” Later, it indicates that ONC intends to use the regulatory process “to establish structures, processes and initial requirements that would be necessary for the governance mechanism to operate.” It further indicates that ONC would retain certain responsibilities to ensure … proper implementation, but would also seek to delegate … certain other responsibilities”. Other discussion reflects on the need for “rulemaking every two years”, alternating with “with regulations published for EHR Incentive Programs…”

It isn’t really clear what responsibilities ONC is planning to delegate, and it appears that it plans on holding onto as much of its regulatory authority as possible. It would appear that ONC plans to adopt a two years cycle of regulation defining the standards, services and policies that would define the NwHIN for the next two years.

In the end, the NwHIN would appear to be whatever ONC says it is. How is this governance?

Let's look at a definition of governance first. If you are an HL7 co-chair (or if you happen to have a copy), dig out the copy of SOA Governance that you got at the last Working Group Meeting, and turn to page 122. You can see clearly near the bottom of the page that Governance is "not just a means by which the organization makes decisions, it is the means by which an organization makes decisions about decision-making." It is, as the authors write: "a meta-decision system".

So to answer my own question, it really isn't governance to set the rules (as the RFI tries to do), but rather to set the rules that set the rules.

The building blocks of a Governance system identify precepts that define the rules for decision making, people (and in the NwHIN case, organizations) that make the decisions, the processes for coordination, and the metrics ensuring compliance (same book, page 127).

The CTEs in the NwHIN RFI are based on certain precepts, but those precepts have not really been well identified. Clearly, trust, transparency and security are all important. So is cost reduction, consumer protection, and innovation and efficiency. But what are the precepts of NwHIN Governance? How do we weigh benefits and disadvantages for a particular exchange mechanism (e.g., what if exchange mechanism X increases security, but reduces efficiency)? The precepts would help us make these trade-offs. Shouldn't we start there?

What are precepts governing the NwHIN? A synonym for precept is principle, and the United States Conformity Assessment Principles published by ANSI is a really good example of the kinds of principles we should be trying to espouse in the Nationwide Health Information Network. In fact, many of the principles we could just outright adopt with respect to conformity assessment, or even better yet, given that ANSI has done a fine job, perhaps even delegate the authority to establish principles for conformity assessment (the NwHIN RFI calls this validation).

I happen to love Principle 13(h): Bilateral or multilateral agreements (MLAs) among conformity assessment bodies or their accreditors should incorporate the use of the least burdensome, time consuming, and costly form of conformity assessment that is recognized and accepted as meeting the needs of all stakeholders.

One of the things I really like about ANSI's discussion of Conformity Assessment is that it recognizes that there are several different levels of "validation". Each of them provide a different level of assurance, and consequent costs. Let's look at a couple of examples:

Self Attestation: This is the lowest cost mechanism, and is the same kind of assurance that you have when I tell you that my Atom Feed is compliant using this logo:
Voluntary Testing: This is a higher cost mechanism, involving third parties, but does not provide a "certification" of compliance. It only demonstrates that something has passed a test. Click the button above to test this site's Atom feed. It's a third party test, and you have an even higher level of assurance especially since you can perform it yourself!
Certification: I'm not going to bother to certify this site's atom feed. The value in it for me is marginal, and to my readers as well. The infrastructure is made by a well trusted company for whom it is beneficial to be "atom-compliant". But if I did, that would provide an even higher level of assurance. It would also cost me something that I don't have a budget for (my entire web-presence is based on free tools).

Of course, conformity assessment is only one component of NwHIN governance for which we need to establish precepts. Another place where I'd like to see some principles developed is in the creation and adoption of standards. On the creation side, I'd refer you to another ANSI document: ANSI Essential Requirements: Due process requirements for American National Standards.

One of the biggest questions I have about the RFI is "who decides?" (Recall the earlier discussion about people in SOA Governance.) There's going to be a lot of jostling for increased importance of organizations in the decision making process as a result of this RFI. One important precept should be that no significant decision is made without the involvement of all effected stakeholders, including governments, providers, vendors and patients (Nothing about me without me!). In fact, the first three principles in ANSI Essential Rules are Openness to all affected stakeholders, lack of dominance by any one stakeholder, and balanced participation by all stakeholders.

I think some of these principles could be very difficult for ONC to apply to themselves. Can you imaging ONC being put into a position where it is but one of many stakeholders in this national process? In order for ONC to give up some of its dominance, it has to trust in the process, and so must the other stakeholders. If ONC sets up too many rules at the outset, it could alienate other stakeholders in NwHIN Governance.

On the metrics side, I think one of the very important points made in SOA Governance is that metrics are used to verify compliance with precepts. In order for metrics to be effective, they must be objective. I applaud some of the recent efforts of the HIT Standards Committee NwHIN Power Team in attempting to come up with objective criteria (see Appendix A of their presentation last week). Karen Witting make a point that some criteria are inherently subjective (e.g., ease of use) in this guest post over at John Moehrke's blog. She also makes the point that it is important that we have a model of governance that people can trust.

I have some thoughts on the Interoperability and Security side that I'll share later this week on a trusted model of governance might look like.

Friday, May 25, 2012

Check the Box for ePatient

My children are at it again, this time my eldest daughter who is 14. The last time we were at the pediatrician's office, she told them to "Check the Box for ePatient" when we stopped by to request her records. It's a pretty simple request, but I'm sure they didn't really get it. But I think they could.

I thought a little bit more deeply about this last night. As a marketing campaign to patients, this has viral potential. "Check the Box for ePatient" is about as easy as "Click the [Blue] Button", and it's a way to easily communicate to your provider that you want to be engaged.

Now, having checked the box, what will the provider do differently? Actually, there shouldn't be anything different in the way they treat you as they would any other patient, but play the game with me. What do you as a patient expect out of a provider having told them you want to be engaged? And what is different about you from their other patients? What should they be able to expect from you?

Thursday, May 24, 2012

Dealing with Age in QueryHealth

We discussed some of the challenges around time on the Query Health Technical call today. We agreed that we needed to look at some specific use cases in order to generate appropriate guidance about how to represent different cases. One of the cases we needed to look at was age of the patient (which I've extended just a bit to Person for a particular reason).

Age of the Patient with respect to the Measure Period
The most common case in dealing with age is in filtering patients by age for the purpose of computing a measure. We've already established that the Measure Period defines a default filter for events that are being queried, and that this can be overridden within the various criteria.

A question that results is that when there is a filter on age, does that mean: Was the patient within this age range at any time during the measure period, or was the patient within this range at the start (or end) of the measure period.

In developing measures, I believe CMS and/or NQF has established the rule that it is the age of the patient at the end of the period (e.g., see NQF Measure 59).

In CCD, a template was constructed to represent Age at Onset which ties the age to the beginning of the time period typically associated with a diagnosis (but could be any observable condition).

The idea described in the Query Health implementation guide is that observations whose effective time overlaps with the measure period are within the scope of the query.

So, start, end, overlap? Three different ways, and all make sense in some context. Which should we choose.

Given that the measure period is of a fixed length, you could associated the age criteria at either end without any loss of functionality. But overlap and begin/end don't work the same way? Or can they?

Specifying an age criteria that indicates that at some time in the measure period the patient must be at least 18, and must not yet be 75 satisfies the case where the patient must be at least 18 and not older than 75 on December 31st. But it misses patients who are 75 on January 1st of the year (it catches every other 75-year old). Changing the observation to <= 75 would catch those, but depending on the precision of the comparison, would let others through. If the age comparison is done to the precision with which age is specified (years), then it lets through patients who were 75 and some fraction of a year old on January 1st, and will thus be 76 at the end of the measure period.

However, the way that HL7 interprets boundaries is not dependent upon the precision at which the boundary is specified, as Grahame Grieve points out. So, we could address age in during to mean what we want.

If you say in Query Health that you are interested in patients whose age is between 18 and 75 inclusive in the age observation, you will get patients whose age will be at least 18 years, and will be no more than exactly 75 years at the end of the observation period. So, we can stick with the idea that all acts that overlap with the measure period are within the possible scope of acts to be considered when evaluating the measure, and still deal with age being specified in an "unbound" age criteria, because the default time range is "within the measure period".

Age of a Person with respect to a Specific Event
Which brings us to the next issue. Often there are cases where you want to suggest a criteria where age is tied to some specific event, such as at diagnosis or condition. As I mentioned previously, CCD created a template to associate an age with a condition or diagnosis.

Age at onset is simply a special case of age with relationship to a particular event, be it an encounter (e.g., age at admission, age at discharge) or another other event.

One case of special importance that also needs to be considered is that age of another person might also be relevant, especially with respect to family history. If you have one parent who was diagnosed with diabetes before age 50, your relative risk for the disease greatly increases, and even more so with two parents. So you might also want to be able to represent age of any other individual as well.

Fortunately, the CCD Age Observation works in both of these cases. I think want we want to say is that the criteria subject to an age restriction (e.g., an encounter or an observation) is the subject of an age observation criteria element which specifies the age range. In the case where the age applies to someone other than the patient, the outer observation criteria should indicate who the subject is (e.g., the patient's mother or father), and the inner age observation will be understood via context to apply to the same person.

Wednesday, May 23, 2012

More Better Data

Machine readable data is what we want to exchange in HealthIT. More standards need to have good machine readable data underneath them. I need more better data.

One of my work items after the HL7 WGM was to see about kick-starting a bunch of FHIR resources. I looked at CCDA and CCD but couldn't easily extract the information that I wanted out of the data. There weren't easily accessible business names or definitions (even in the Trifolia database).

But I did have a source which I could use which provided business names and definitions. I pulled up original versions of HITSP C154, C83 and C80 that I had, saved as Filtered HTML, converted (using tidy) to XHTML, and then extracted the entry data and associated data element definitions, and merged data element definitions with entry structures. I performed data extraction using XSLT and my knowledge of the very regularly structured table formats to get to the most useful stuff (I could have gotten to a lot more)

So now I have 20 or so resources that I'm hoping to be able to use to kick start some discussions on FHIR.

Tuesday, May 22, 2012

A Team Sport

I started looking at FHIR in earnest today.
I started looking at the NwHIN RFI in earnest today.
I'm meeting shortly on Meaningful Use standards.
I just responded to several emails about potential future ONC projects.
I looked at my list of things to do for Query Health.
I looked at my list of things to do for HL7 CDA/Blue Button stylesheet project.
I still have one out-of-cycle HL7 Ballot to comment on.

I just spent a week expanding my brain only to find out when I come back that I haven't expanded it enough. It's still to small to keep track of everything that is going on.

Thank God that there are so many others that I can trust in this industry to keep the pieces together. Standards is nothing if not a team sport, and we've got a great team across the industry.

Thanks.

Monday, May 21, 2012

Who Should Represent Patients?

One of the challenges I always have with patient representation in national initiatives is that most organizations that claim to represent patients don't seem to represent me very well. That's one reason why I was thrilled when Lygeia Ricciardi was named to the (self-proclaimed) role of Consumerista at ONC, because she had the chops, but was also independent of organizational influences.

The challenge for me is that many self-anointed patient/consumer advocacy organizations really don't advocate for what I want.

I'm not a privacy advocate. While concerned about privacy, I'm not fanatical about it, and I'm probably more well-informed about the risks and dangers than most folks.
I'm not retired (or even close).
There's a lot of other categories that I just don't fit.

Recently, the GAO announced an opening for a patient/consumer advocate on the HIT Policy Committee. Today, I saw this blog post by Andy Oram on O'Reilly Radar: Putting the Patient Back into Healthcare recommending Regina Holliday for the position. I couldn't have said it better than Andy did.

I confirmed today via telephone that letters of recommendation can be sent via e-mail to HITCommittee@gao.gov

To make life simpler, I've written simplified letter of recommendation which you can send (or edit and send) with a few button clicks. I strongly recommend customization. My own letter in support of Regina for this position was similar to what you see below.

-- Keith

P.S. As always, the opinions on this blog represent my own, and not those of my employer or any other organization I might represent.

Update a few short minutes after I posted this:
Ted Eytan submitted a similar letter.
ePatientDave is also willing to serve in that role, and is seeking support (you can STILL use the button below and just alter the text in the body to show your support for Dave). Either way, patients win!

Click here to open the text below in your e-mail application:

Government Accountability Office
441 G Street NW.
Washington, DC 20548

Dear Sirs and Madams:

I am writing in support of Regina Holliday as a patient advocate on the HIT Policy Committee. Regina has heard, painted and told hundreds of patient stories and would be an excellent independent voice for patients on the HIT Policy Committee.

Sincerely,

Friday, May 18, 2012

Status Update, HL7 Working Group Meeting

HL7 created a new membership category for care givers that was announced this week.

Meetings on FHIR have been getting standing room only attendance throughout the week.

Structured documents will be balloting several items related to quality measures:

An update to the HQMF based on Query Health
An implementation guide on HQMF used with the Quality Data Model from NQF
An update on QRDA to support aggregated quality reporting (QRDA category II and III)

The first draft of CDA R3 will go out in a for comment only ballot.

A project scope statement for patient authored CDA documents has been developed and will likely also be balloted.

Canada Health InfoWay might be looking to develop a CDA implementation guide for the CDA Header, much like the General header in CCDA and the French DMP.

We may yet see a separation of presentation from the modeled data in CDA R3 which paves the way to use of XHTML for narrative (without microdata).

Templates is moving forward, and I've provided input on an exchange XML format based on a metamodel.

Mobile health is in the forming stages, but also getting traction.

The HL7 policy advisory committe is working on an HL7 response to the NwHIN RFI.

HL7 will be putting on a special education track for meaningful use at the September WGM.

Wednesday, May 16, 2012

HL7 mHealth Workgroup Meeting

The newly forming HL7 Mobile Health Workgroup met this afternoon in Vancouver to discuss the workgroup charter. I went to the meeting today, and there's another one tomorrow. I won't be able to attend tomorrow because I'm teaching about Templated CDA.

What follows are a few high points of the discussion. There's probably a lot more discussion that the workgroup needs to have before they are able to develop a charter and start getting to work.

One of the challenges that the group faces is defining the scope of their activities. The discussion led me to tweet about the distinction between healthcare devices that are mobile, and mobile devices that are used for healthcare. From my own perspective, healthcare devices that are mobile is not where the challenge lies. Instead, it is the mobile devices that are being used to support Healthcare. To explain one problem, I whipped out my iPad, showed my blood pressure results in one app, and then my weight in another. Those two chunks of data are so much more powerful together, but even though they reside on the same device, I have to do some serious hacking to make the data appear in one place.

We have hundreds of thousands of apps, but no mobile apps that can put the data together from these separate mobile apps in meaningful ways (except in proprietary clouds). We have the ability to put all that data into the cloud, but I'm still stuck with the device maker's web interface to access and combine the data in meaningful ways. There out to be an app for that, but the problem is that there are no standards that enable that capability. And the cloud isn't helpful either if everyone has to have their own cloud, and the various clouds don't talk to each other. After all, a cloud that cannot interact with other clouds is nothing more than a fancy way to put a silo in the sky.

Someone asked what the distinction is between mobile and distributed. Again, from my perspective, mobile means it moves with me. Distributed can be a part of mobile, especially when the device interacts with the cloud, but in my case, there's no cloud. All the data is on my device. But distributed can be "bigger iron" with more capabilities than the mobile devices have.

Someone pointed out that mobile devices are getting more capable, with better technology stacks, et cetera. But, we cannot simply wait until they have the world's best technology stack before we address the need for standards. If we do, someone else will have already solved the interoperability problem, and that is part of HL7's mission. If we fail to solve it, we fail ourselves and our industry. It was well put by one observer who said: We need to foster a community of exchange and accessibility.

In order to define what the scope of the Mobile Health Workgroup is, we need to understand what the scope of mobile devices is. We have devices with simple bluetooth, GPS and simple accellerometer capabilities, more complex apps that fit into a smart phone platform, or connect to it (e.g., to capture blood sugar results), and other apps that work in a tablet platform. Each of these devices has certain capabilities. Ideally, we'd find a taxonomy of mobile device types and related capabilities that could help us understand the space.

One of the issues that the workgroup discussed was the issue of security. Mobile devices have a much different risk profile than other systems. They are easier (and more desirable) to steal, harder to protect, et cetera. It's much easier to lock down and manage laptops and servers than it is to deal with mobile devices, as John Halamka points out here. Someone suggested that the Mobile Health Workgroup should perform an assessment using John Moehrke's Risk Assessment white paper. John and I will both point out that was a collaborative effort, and that a lot of the content came from a Canadian Ad Hoc Harley winner. It is very nice to see John's efforts to promote that effort pay off.

Once we have found (or created if really necessary) the taxonomy of devices and capabilities, we can perform a risk assessment that will help inform future mHealth efforts.

There's still quite a bit of forming and storming that needs to occur. I don't expect a charter by the end of this week, but certainly before the next Working Group Meeting. This is another place I'll need to pay attention.

Overview of the NwHIN Governance RFI: Tomorrow, 5/17 at 11:30 a.m. EDT

Overview of the Governance RFI

The Office of the National Coordinator for Health Information Technology (ONC) is a cooperative agreement partner of National eHealth Collaborative (NeHC).
On Thursday, May 17, 2012 at 11:30 a.m. EDT, National eHealth Collaborative's NeHC University will present a program on the newly released Request for Information (RFI) on governance of the nationwide health information network. To help you get informed about this long anticipated announcement, NeHC University will host ONC's Director of the Federal Policy Division Steve Posnack to provide a first look at the RFI and answer questions.
We invite you to register and join NeHC University's overview of the governance RFI. *(free of charge).
Learn more about NeHC University programs! Questions? Email NeHC University at university@nationalehealth.org.

*Please note that the NeHC webinar platform has the capacity for 1,000 attendees. Please log in early. If the webinar is full, you can call-in using the information in your confirmation email and download slides from the program webpage on the NeHC website to follow along in real time.

Newbies guide to HL7 Committees

I'm an HL7 Mentor. That means I get to wear a red ribbon that says so at the working group meeting, and make a point to talk to people who have the first timer's ribbon as the meeting. Being a mentor at the meetings is easy, because I know my way around the meeting, and can make introductions and get to tell people where to go (to find out more about ___).

But I also get asked quite often how to get involved in HL7 activities. Usually the question comes in via e-mail or through this blog, and is generally in the form: How do I find out what is going on, or who do I talk to? Often the question doesn't include "about X", and so I have to follow up with "What are you interested in?" before I can answer the question.

Here are a few tips about how to figuring out what is up. There are about 40-odd work groups in HL7 (other SDOs call these technical committees). Most work group names are fairly self explanatory to initiates, but novices are often challenged to find the right work groups.

In the lists below, think about filling in the blanks in this sentence:

I'm an ___ specializing in ___.

Using the answer in the first blank, find your general case in the headings below. Under the headings are the committees that you might be interested just based on your general category. Underneath those headings are specializations, which also indicate work groups that might be of interest based on general category and specialty.

A couple of notes on committee names and why they show up where they do:
EHR deals with functional requirements for health records, be they EHR, PHR or otherwise, which is why PHR vendors might find EHR interesting. If you are interested in FHIR, you want to check out MnM who is running that project.

A final note: This should be turned into an interactive form, and it should cover IHE, S&I Framework and many other activities. Oh boy, another great summer project for someone with time on their hands.