Cool Toy of the Week

For Christmas, I got an Getting Started with Arduino Kit. You write software in the C/C++ (a language I know well) to program the Arduino Micro Controller.

My first project extended from Blink.  It was basically a binary clock using six LEDs to show the time (in binary).  The clock had three display modes: Hours, Minutes and Seconds.  You control the display mode by clicking the first button to cycle through each mode.  You can also hold down both buttons to set the clock.  That zeros the seconds.  By depressing button two, you advance the hours.  Pressing button one again takes you to minutes, which you advance again using button two.  Finally, you return it to the running mode by pressing the first button again. It's an interesting experience, and I went through several different gyrations on how to use the buttons to set the clock, and to use the LEDs to indicate which mode you were in before I arrived on the ones I used.

I had an Erector Spykee - Micro Robot that is operated by remote control that I got a few years back for Christmas that I wasn't using.  I decided to take it apart to and learned how to connect up the IR receiver inside it. After a bit of playing I figured out that the red wire goes to +5V, the yellow to Ground, and the green wire has the signal. I tried to read the signal using the analog input, not realizing how the IR worked. I managed to read it anyway, and figured out to some degree how to decode the signals. After a while, I looked around and found this library, which I then augmented to read the IR signals generated by the silly little remote.  That gives me two continuous buttons and four toggle buttons which I can now use to control my Arduino remotely.  I may have to work that into my first useful project to give me some override controls.  The robot also had a few LEDs, a small motor with a forward and reverse drive, and an 8ohm speaker that I will be using with my new toy.  I can use the motor later when I need to make a mobile robot.

Now I'm planning my first "useful" project.  My plan is to create a device that, upon sensing the remote control signal that turns the TV on, will tell my children to finish their homework.  It can use the IR sensor to detect the "power on signal" for the TV.  Once that is detected, I'll send a WAV file to the speaker.  After an hour, it will send out another signal to turn the TV off again.

To do that requires a bit of finagling.  The Arduino has a Pulse Width Modulated signal that gives be eight bits of signal control, but I have to add a low-pass filter to the circuit to turn that into a voltage to control the speaker.  This web-site helped me to figure out what resistor/capacitor combination to work with during my last shopping trip at Radio Shack  While I was there, I picked up a $14.00 SD Card Shield so I could store the audio of me telling my kids to finish their homework first on an SD card.  That way, I didn't have to encode it all, but could read it off the card, and use different audio messages as I needed.

One other thing that I'll need for this project is an IR transmitter, so I can send the Power Off signal to the TV after an hour, and tell my kids to go outside and play.  This should be a hoot.  I stopped by Best Buy to purchase a cheap SD card, and found a $5 calculator that I'm going to take apart for the LCD display.  I'll probably need a controller for that display.  I think that will be used in my second project.  The cool thing about this first project is that I can build it in pieces.  I first did the IR stuff.  Next I'll build the speaker/filter circuit and play with that.  Then I'll play around with the SD card reader.  And finally, I'll put it all together.

What a cool toy.

With apologies to Clement Clark Moore

Twas just days before Christmas,
when all through the house
Not an HID was stirring, not even a mouse.
The phones were all laid in their chargers with care,
In hopes that all T-cons could wait 'til next year.

The geeks were all nestled all snug in their beds,
While visions of RTs danced in their heads.
And ma w/ her facebook, & I gave my last tweet,
were just settling our iPads for a long winter’s sleep.

And then, there on twitter, I heard of a spoof
of a Christmas poem marked with a W00T!
As I drew up my tablet, and was pulling it down,
it popped up in FlipBoard with hardly a sound.

OMG it was funny, that silly elf,
I ROTFL in spite of my self.
And laying my finger on the button to close,
I went back to bed, happier than I rose.



Happy Christmas to All, and to all a good-night!

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.

HealthIT Standards Predictions for 2013

Yesterday I talked about where I'd been last year.  Today I'm going to cover where I think things are headed in the US (at least for me).

1. We'll likely see a new S&I Project on Patient Generated Data.
2. eMeasures will make significant headway in transition to HQMF Release 2
3. Clinical Decision Support standards will become more important.
4. EHR adoption through Meaningful Use will slow down
5. Plans of Care, Care Plans, and Patient Plan of Care will attempt harmonization

S&I Framework Project on Patient Generated Data

This should be fairly obvious.  HL7 is balloting a specification for Patient Authored Docuements.  The HIT Policy Committee has held a public hearing on the topic.  There have been a few rumblings internally within S&I Framework staff and ONC.

The key challenge for this project will be differentiating between information coming from patients directly, and data coming from home health monitoring devices.  My advice is to attack these as separate use cases, but from the same project.  The data coming from home health monitoring devices is rather different from self-reported information on symptoms, allergies, social and family history, et cetera.

The HL7 FHIR Protocols that I've been using for ABBI also have a simplified method by which patients (or devices) can post data to a PHR.  The key issue is not transport protocols, but rather content.  I suspect that we could use the CCD 1.1 in C-CDA to record patient generated content just as readily as it is used for provider generated content, and we could also use the HL7 Patient Authored Documents specification being balloted now.   As for medical device data, I suspect we could look at the HL7 Personal Health Monitoring Report, and work from IHE Patient Care Devices and Continua for possible content solutions.

eMeasures in HQMF Release 2

I know the folks at MITRE have already been looking at transforms from HQMF Release 1 format to Release 2.  There's some interest in specifying HQMF R2 for Quality Measures in MU Stage 3.  A long term result of this effort would be to propose HQMF R2 as a required standard for the 2016 Edition EHR certification criteria.

We've done quite a bit of work on HQMF Release 2, and I suspect it's "nearly ready" for prime time.  However, the most critical effort at this point will be to deliver eMeasure specifications in HQMF R2 for use by pilots, get implementer feedback, and either tweak it, or develop an IG that makes it ready for use in the 2016 criteria.  Without that, I expect ONC will be scrambling to make it happen anyway, and the quality of our quality measurement tools will suffer.

Clinical Decision Support Standards

If you've been paying attention, you are already aware of the Health eDecisions work going on in S&I Framework.  Use Case 1 is finishing up, dealing with content formats for CDS rules, forms and order sets.  This is now being balloted in HL7.  They will soon be moving on to Use Case 2 (of much greater interest to me), which is how to integrate CDS web services with an EHR.  You can see that they haven't gotten very far on this use case.  Again, looking at Stage 3 proposals, it seems obvious that its about time for this work to really heat up.

My goal here will be to make sure that the proposed standards link up well with HQMF, and C-CDA specifications for content.  The link between quality measurement and CDS has already been made.

EHR Adoption Slows

Logistic Growth Curve (courtesy of Wikipedia)

Also easy to guess if you've been paying attention.  As I show in this post, there are three stages to technology adoption, exponential growth, linear growth, and saturation.  I think we are about halfway done.

If you look at the current data on the HealthIT Dashboard, you can see a logistic curve (shown to the right) embedded in the data.  There are some outliers for sure, but I suspect this has more to due with seasonal (i.e., Fiscal year-end) adjustments.  I'm not enough of a data analyst to figure out what those should be, but the pattern seems clear enough.

Care Planning

The topic of Care Plans, Plans of Care, and meeting the needs of the patient via patient centered medical homes, patient centered care planning, et cetera is heating up.  Something has to shake this loose.  We've had a care plan section in CCD (and now in C-CDA), and their predecessors since 2005.  HL7 has a workgroup named Patient Care, and in IHE, I'm planning chair for the Patient Care Coordination domain.  We've been working on this for several years in the SDO community, but it has yet to take hold.  

The content of a care plan is fractal and interlinked.  Certain kinds of care for this condition affects goals and activities for that one.  Tracking that sort of linkage in what we have today is certainly feasible, but little is, I think, really known about what is needed to do that.

The real challenge with care plans is not so much what to put in them (as far as I can see), but rather how to organize and manage them.  In other words, it's not a content issue, but rather one of governance.  And that governance is created by multiple care providers: doctors, nurses, and allied health professionals; covering general practice and specialties; in the home, and in acute and long-term care settings; by payers, ACOs and PCMHs.  Everyone has a use case to address, and frequently, an axe to grind.

I expect to see some motion on Care Plans next year, but it may be sideways.  I'm not sure if we'll see real progress until 2014 or later.  Perhaps ACOs and Medical Homes will help this along, and perhaps not.  Current drivers right now in S&I Framework are coming out of the long-term care community, but their use cases don't address everyone else's requirements.

I think we will need to assess and prioritize the need for care plans by the various axes [pun intended]. I think it likely that there is more value in some kinds care plans for a given type of healthcare provider, specialty, care setting or stakeholder.  We should be looking at working on the high value (in terms of costs of care) care planning activities.

We should also start using what we have today in C-CDA to report the basics (goals and interventions linked to conditions), and see where that takes us.  We can figure out how to move beyond that limited level of detail when we have more implementation experience.  After all, the key point of standardization is to standardize what works or what is best practice, and as far as care plans go, I don't think we know the answer to either of those questions.

---

So there you have it, my predictions for 2013.  It seems pretty obvious to me, but that may also be from knowing where to look for the trends.

The year in review

If I had to sum up this year quickly, I'd say for me it was about Quality Measurement, Patient Engagement, and Meaningful Use Stage 2.  Most of my posts have been related to these topics.  This was also the year I took serial writing seriously.

January started year 2 of Meaningful Use.  In January, I didn't go to the IHE Connectathon for the first time in nine years.  I'll be back again this year.  For fun, I wrote The Characters in a HealthIT Standards Meeting.  In January, I was deep into planning and designing transforms for HQMF and Query Health.

February started the month that Consolidated CDA 1.1 was finalized by HL7, after several months of work with IHE, HL7 and S&I Framework.  Early in the month was an IHE meeting in Paris.  My family came along for the ride, and we learned quite a bit about communicating with French speakers.  Of course there was HIMSS, and the almost anti-climactic announcement on the Meaningful Use regulation the day after most everybody has already gone home.  ONC and HHS, stuck in their process, couldn't say much until too late.  I coded, and subsequently demonstrated transforms for HQMF and Query Health at HIMSS.  I spent a good bit of time reviewing the rules.

In March, I started a four-part post which starts here and is completed here about having too many definitions of summary care record in the rules.  It got fixed in the final rule, but there is still yet room for improvement (maybe in the 2016 edition).  In case you weren't aware, the data required for "data portability", and for transfers of care is defined identically in the rule.  HL7 began forming its Mobile Health Workgroup. 

I began my series on Health IT Standards 101 in April (and still have to finish it, although I expect it to be a never ending story).  For fun I wrote Four Career Lessons from the Incredible Hulk.  I issued an Ad Hoc Harley to Jeff Klann for his ability to pick up where I left off on Query Health.

May is the month for one of three regularly scheduled HL7 Working Group Meetings.  We spent a lot of time talking about FHIR, CDA, Templates and the NwHIN RFI at that meeting.  The NwHIN RFI resulted in nothing significant^* happening with respect to governance out of ONC in 2012, but there were some good discussions going on here and elsewhere.  It remains to be seen what will happen in the US.

June is another good month to read some more posts about HQMF and Query Health.  At the beginning of the month, I got to take my daughter to a not so secret White House meeting called the Patient Access Summit.  And my daughter joined The Walking Gallery.  She also wrote her first post for me for this blog.  June begins the summer of standards work that I typically engage in.

July was a slow month for the blog, which usually means a heavy one for other activities.  July is when we meet to deal with the public comments and produce the trial implementation content for IHE Profiles.  I finally got around to starting my series on moving from C32 to C-CDA at the end of the month.  A good friend and colleague, Glen Marshall, retired this month.  He got the first lifetime achievement Ad Hoc Harley.

In August, ONC finally kicked off the ABBI Project, which has become one of my bigger "volunteer" efforts.  Of course, I love the acronym, and so does my daughter.  We often joke that ONC gave it that name to suck us in.  She and her younger sister even did a 180 second ad for it.  I continued my series on moving from C32 to C-CDA in this month.  And of course, we got the final rules this month, which led to another series of posts.  In August, I attended the HL7 board meeting where we approved making the IP free.  Only the rest of the world wasn't to know until nearly a month later.

September was kicked off by this huge announcement from HL7.  I've been working towards that since I was elected to the board, and will continue working on it in my second term.  I began playing quite a bit with OAuth in this month, even implementing an OAuth 1.0 Provider.  The test methods for Meaningful Use Stage 2 began to show up this month in waves.

October is the month that my ABBI prototype was moved to the cloud.  I spent a lot of time on ABBI in this month. Just for fun, I built a go-cart in a couple of days.

In November, continuing with one of this year's themes, I created a slide called Hashtag Soup: Relating QDM, HQMF, eMeasures, QueryHealth, QRDA, SIFramework and MeaningfulUse Stage2.  That slide got picked up an used by an ONC staffer for an educational slide deck.  Elsewhere, I spent half a day listening to, and responding to testimony to a House subcommittee on Meaningful Use and Meaningful Results.

December isn't over yet, but I've already been to an IHE Meeting, the mHealth Summit, and the ONC Stakeholder Meeting this month, including the ABBI Town Hall Meeting.  IHE USA announced it's new certification program, and well, there's just a lot going on.

^{* Just days before the year ended, ONC announced a grant on Governance.}

2014 Edition MeaningfulUse Test Methods Approved by the National Coordinator

2014 Edition Test Method Approved by the National Coordinator The Office of the National Coordinator for Health Information Technology (ONC) is pleased to announce the release of the 2014 Edition Test Method (Test Procedures, Test Data, and Test Tools) for EHR Certification. After a comprehensive public review and comment process, the 2014 Edition Test Method was finalized and formally approved by the National Coordinator on December 14, 2012. The 2014 Edition Test Procedures, Test Data, and Test Tools are now available for use in testing and certifying Electronic Health Record (EHR) technology under the ONC HIT Certification Program (formerly referred to as the Permanent Certification Program). ONC thanks all the dedicated individuals who provided valuable feedback and suggestions on the draft materials. To access the 2014 Edition Test Method, please visit the 2014 Edition Test Method webpage. Questions may be directed to ONC's Office of Certification via email at: ONC.Certification@hhs.gov.

Are you a startup, or an upstart?

I often get to work with entrepenours.   Many of them have interesting ideas, and all of them are passionate about them.  The difference between the ones I want to listen to, and the ones that turn me off is in their approach.  If you start your pitch by telling me everything I've been doing is wrong, and I should use your product, and do business your way, you've just insulted me, and I probably won't listen much more.  But if you tell me that you've discovered something new that can improve how I accomplish what I need to,  my ears perk up.

The ABBI Hour (or two)

I've spent the last couple of days at the ONC Annual Meeting.  Yesterday morning was filled with a joint session between the Beacons and S&I Framework folk.  The afternoon was an S&I Framework Round Table, followed by the ABBI Town Hall Meeting.  I covered the morning session in yesterday's post.  I'm not going to cover the S&I Framework Round Table since it was basically a report out from the various S&I Projects, and either you care and already know, or you aren't that interested.  What I will cover today (as promised) is what we talked about in the ABBI Town Hall meeting.

First of all, I'm not sure what the difference is between the "Round Table" and "Town Hall" meeting format.  I think they just pulled these names out of a hat.  The ABBI Meeting certainly had the flavor of "Town Meeting" though, especially if you'd had any experience with that form of government.

Farzad Mostashari kicked off the ABBI Town Hall meeting with a rather personal story.  [FYI: Everything I'm telling you here Farzad cleared with his parents, and was also stated in public in a room full of 1300 people this morning].

It starts with this tweet from Presidential Fellow Henry Wie MD (which Farzad retweeted) just before Thanksgiving:

RT @henryweimd: On T-day, show older family how to get their Blue Button health data; eg myMedicare.gov Could save their life someday
— claudiawilliams (@claudiawilliams) November 21, 2012

And he did sign up his father and mother on Turkey day.  Then he looked at the nearly unreadable text, and decided that he needed to get them hooked in with an App that would make sense of that. So he downloaded the winning app from the Blue Button Mashup Challenge (from ABBI committed participant Humetrix).  He had to e-mail some folks at the company to resolve an issue, but got it worked out (all on T-day).

The next day, his father complains about serious eye pain.  Great, he thinks.  This is going to be a miserable Thanksgiving Holiday.  He and his parents are going to spend half the day or more at an ED in a hospital, that doesn't have an Opthamologist on call, and with no access to provider records from physicians in their home state (MA).  But, now Farzad can look at the diagnosis code that the physician provided for a previous procedure on his father's eye, or even better yet, look it up on the Internet.

As it turns out, he winds up finding an Opthamolagist who can see his father the same day using another App.  And his father, upon being asked for the history of this problem, can hand the Doctor his cell phone and say, here it is.

OK.  If you thought Farzad was over the top about the value of Blue Button before, you should see him prance about now.  There is nothing like a personal story that will make it hit home.  I've been through this hassle (One of the stories on my jacket is about the 3 extra days spent in the hospital, uselessly waiting on data that wasn't available until Monday morning).  Guess the date.  Yep, my step-father also went into the hospital the day after Thanksgiving when he was visiting me.

Farzad wondered why his parents medicines weren't also in the CMS download data, but then realized that they weren't enrolled in Part D.  So, he made sure to enroll them in that as well.

This kind of solution is what ABBI is about.  But better than a file of text that has to be parsed out, ABBI will use the same standards that are in Meaningful Use.

Next up was Ryan Panchadsaram (Presidential Fellow), to discuss some of what we've accomplished in the project thus far.

There are three aspects of ABBI: Liberation of data, fidelity of data (through structured content), and automation of access.  The last part has been described as the "set it and forget it" feature.

There are two different forms of ABBI that we've been working on: PUSH, enabling providers to transmit to patients using Direct (not hitting a meaningful use goal unless you count push to a patient as a download), and PULL, enabling patients to view or download the content (either counting towards patient engagement metrics in MU Stage 2).

Ryan started off with a shout out to me on some of the work I've been doing here.  Then he described some of the accomplishments of the four workgroups: Content, Push, Pull, and Payer (which I'll get into in a moment).  In describing how I've been working on the Document Bits, Ryan stumbled and it came out "Documents Bitch".  Which led to this tweet.  I embrace it.  Yes.  most of my standards work has been about documents for the last decade (and more).  And I embraced Ryan as the room burst into laughter.

Following Ryan (and that was difficult at this point), was Henry Wei, also a Presidential Fellow working on the project.  He was up to the task though, reminding all that we record the calls, and that it is a good idea to go on mute before using certain facilities.  That gained another brief bit of laughter, and we got back to the meeting.

Henry's been keeping up with the payer group, who have been working diligently to develop a standard to enable patients to get access to cost data, which could be a real game changer for cost transparency.  While they are pretty much all-in on developing the standard, there is a great deal of concern that they won't be so keen on sharing it (I'd make the point to them, that to win the pot, you have to show your cards).  Will they be brave enough?  That's a good question, but I think some of them get it, and will.

On the standards, at least one participant has been pushing the payer community to something like a JSON representation of the 835.  They are calling this 835ish.  I like the name, but will have to see how the results come out.  I could probably automate the representation based on the X12 standard content (oh joy, more PDF scraping), but I think I'll let the payer community work that out.

So now we get to the real fun part, which was where the meeting definitely felt like a town meeting.  

We were given three questions to address:

For Push, the question was stated something like: How do we figure out what Direct addresses to white list?

I was aghast.  I don't want to be forced to use any address other than the one I've already set up for this purpose.  I've got an e-mail address.  I have a secure certificate.  And when I give my provider my e-mail address, I can also send him a signed e-mail to ensure that he's got my certificate.  After all, this is the way that certs get passed around today.  There are certainly ways to automate this.

The reality of this is that the question was badly stated.  What I suggested above certainly will work with Direct.  A direct address is an end-point.  It could be to an e-mail client, or it could be to something like HealthVault.  For end-points used by non-tech-weenies like me, what/how should we create a "trust-bundle" and manage that?  And still, I don't see the problem.  Provider A's trust-bundle could well be different from provider B's.  This only seems like a way to cut out possible end-points.  Rather than assume that all end-points are bad unless proven otherwise, why not consider the opposite, and let the eco-system police itself in some way.  We'll see where this goes.  I expect that whatever solution they come up with, if it shuts out innovation or patient access, will be corrected by hactivist patients, and the eco-system will adjust (just as the Internet did, first with HTTPS, and later with PayPal and the like to support secure payments).

What is this trust-bundle thing?  Well, imagine it this way:  Every browser is configured with a set of root certificates that it trusts.  There's a bundle.  This bundle of root certificates manages what X.509 certificates are acceptable to the brower to ensure trust in a secure site.  We want to understand what the "initial" configured rules are for the bundle for Direct endpoints.

On the idea of White List, Farzad asked:  Is bar too high? too low? Do we need a bar?
Doug's question was perhaps more pertinent: Or should we go to the bar?

I'm of the opinion (if you haven't figured it out), that a White list (or preconfigured trust bundle) for patient owned Direct addresses sets the access bar for providers implementing portals higher than we've already set it for via HIPAA/HITECH for providers enabling patient data access through a portal.

Next question on the table was for Content:  How can we set content expectations to be consistent with MU Stage 2/CEHRT 2014, but meet providers where they are today?

I think we agreed that

1. ABBI should recommend best practices for content,
2. But allow for use of any content available.

Farzad talked about even sending "Open Notes".  I'm not sure that everyone gets that the eight structured document types in Consolidated CDA can serve two purposes:

1. To document an encounter for your "Clinical Notes"
2. To act as a summary for that encounter for Meaningful Use.

And so, you could have your cake, and eat it too, OR, as I keep telling people, use the document you are already creating in your existing workflow, to act as the visit summary.

Finally, for PULL: What is needed besides working code; what will it take for organizations to implement pull? 

I restated the question to the room:  How many of you here are data holders that would want to share data using ABBI PULL.  Peter Levin failed to raise his hand, but I think he meant to.  Nobody else in the room in the afternoon was a data holder.  My conclusion is that we were in the wrong room, and needed to head over to HIE or Beacon Communities to ask the question again.  [FWIW:  I went fishing today among ONC grantees and programs, and got a few bites.  I may just have to change my business card to read "Standards Coordinator" rather than "Standards Geek"].  Maybe I can convince Microsoft to use their CCD APIs to implement something that works.  (Sounds like an IHE MHD Hackathon adventure).

The last major comment in the Town Hall that I remember was the person who said:  Consumers need to be the ones with ALL of the choices when it comes to ABBI.  I agree.

We closed with #ABBI Hour, at a nearby pub, just as Doug suggested.

What happened at that meeting you missed in DC today

I'm in DC for the ONC Annual Meeting.  Today was "invitees" only. Tomorrow is open to the public.  Invitees today included the S&I Framework crowd, although most of us didn't get the message that this morning was important too.  Fortunately, I got here early enough to take advantage of it.

While preparing for my flight a few weeks ago, I happened to discover that my daughter (Abby, or @amaltheafairy on twitter) was free today.  So I booked her a trip for today's meeting as well.  Seeing as she was there when the ABBI project was conceived, it seemed relevant for her to hear how things were going.  She'll have a report of her observations for me to post later this week.  She's back at home now, ready to go back to school, after learning a ton at today's meetings.  We arrived Monday night, and went to her favorite DC restaurant (Sushi Taro).  After a wonderful Omakase, she had desert combining flavors from her two favorite international destinations, France and Japan: A Green Tea Crème Brûlée.  One word: Awesome.

This morning we walked from our hotel over to the meeting (about a half mile).  The registration desk was such a classic representation of how these various projects communicate with each other.  For each different group, there was a very nice padded box holding printed name tags.  We had registered about three weeks ago, but her tag would have been in one box (Stakeholders), and mine would have been in another (Science and Technology).  I personally would have just put them all together in alphabetical order.  After all, there are plenty of Beaconista's who are also involved in HIE's, and some involved in S&I Framework and so on.  But for some reason, we each had a separate box.  To add to the confusion, they couldn't find either of ours, so we registered again.

For the Science and Technology program, this morning's agenda was a join session between S&I Framework and the Beacon programs.  I don't think anybody said anything about this to S&I Folk (but since I've been busy in the last two weeks, I can't say they didn't on one or more of the forty calls I could have been on, or the half dozen I'm usually on but didn't dial into).  Last week was IHE and the mHealth Summit, so I took only a few calls that week.  I heard from at least one ONC staffer (and S&I lead) that they weren't even aware of the joint session.  It's a shame really, because in a room full of Beaconista's with interest in S&I Framework, there were perhaps 5 of us who were from the "volunteer pool".  There were a few more than just 5 S&I volunteers present later, but most were coming for the afternoon S&I report out, or the ABBI Town Hall (which was widely discussed in the ABBI project).  If the goal of this morning's meeting (as reported by one ONC staffer) between Beacon's and S&I was to break down silos, someone at ONC should have notified all the silo owners.

We heard from two different Beacon programs first.  Kicking off the program was Dr. David Kendrick, of the MyHealth Access Network.  They've been doing some cool things with patient portals, and CCD documents.  One of their early challenges was the quality of CCD documents being generated by Certified EHR systems.  Even now, while the situation is much better, it still isn't perfect.  Part of the issue seems to be with how products are installed and configured.  So rather than getting the most that they are capable of, providers were barely getting the benefits.  Dr. Kendrick reports having to rework a number of CCD outputs from different products.  The number of products he has to deal with in his area is also rather large.  He reported 30-40 products, but someone later corrected the figure to 52 separate EHR products.

One of the points that David made early on in his presentation, is that 10-20% of the effort is in the technology.  The rest of the effort involves politics, policy and people issues.    I've had similar experiences, where 6 months goes by to work out consent policies, and they are implemented in software in less than 6 weeks (often using the IHE BPPC specification).  And it isn't that there aren't enough standards, but rather, that more work is needed in their implementation.  To quote my manager, "The trouble with standards is that there are so many to choose from."

One of the challenges still encountered is closing the referral loop: Making sure the provider making the referral gets back a report on the results of the referral.  A proposed solution is to treat the referral as an order.  I'm a bit challenged by that prospect, simply because I'd like to be able to make my referral choices based on quality, cost, and availability.  That's information I don't have when my provider gives me a referral, and it still takes too damn long to get.  I might keep my providers recommendations in mind when making my selection.  IHE PCC took on a profile this year to address coordination of orders with patient documentation, which may help.

Doug Fridsma stopped by to talk to the morning group, and introduced himself as "Chief Geek" at ONC.  Amusingly enough, while my current business cards say "Standards Geek", I've been seriously thinking about changing my title to "Standards Coordinator" because that seems to be what I do these days.  So, I'm happy to let Doug claim the Chief Geek title.  He made the point to the Beacon group that the key point in S&I was to test Health IT interventions, just as we test other interventions in healthcare.

Jim Younkin, IT Director at Geisinger Health System also harped on the CCD variation.  They just rolled out a solution that allows patients to upload their own information to the portal.  More than 1700 users have signed up for the patient portal there.  My daughter had a great question for Jim:  Can patients correct their data in KeyHIE?  How does that work?  I rephrased it a bit, and Jim handled the answer well, even though it wasn't what she (or I) wanted to hear.  They don't have enough experience yet to know how that works.  But, Jim tells us, Geisinger has had a portal for quite some time for its patients, and they've enabled patients to ask questions about their Dx, and they do, and providers handle it.

Following the Beacon presentations, we heard a QUICK review of what is going on at S&I, starting with Direct, and going through Transitions of Care, Lab Results Interface, Query Health, Provider Directories, Data Segmentation, Public Health Reporting, electronic submission of Medical Documents (esMD), Longitudinal Coordination of Care (LCC), Laboratory Ordering, and the Automate the Blue Button Initiative.  There have been so many projects this year that I found this image I found at the airport tonight rather relevant:

After a little coordination from John Feikema, we slightly rearranged presentations to let Jacob head off where he needed to go.  I like "Feik", but even more, I like his job.  He gets to tell Doug where he needs to go, and Jacob when to stop talking.

Jacob Reider gave a pitch for Health eDecisions, and I heard from him the group's definition of CDS that happens to be the best definition I've heard ever (for CDS):

CDS is the user facing representation of clinical guidance.

Jacob then went on to describe the various components of CDS, including artifacts.  What's an artifact?  Basically, a CDS component you can use (like those I describe here).  E.g., a rule set, list of things to order (order set), or even a form (or template).  One of the challenges in clinical guidelines (and in converting them into artifacts with actionable logic), is that you need to go beyond could/would/should and move into can/will/shall.

After Jacob was finished, we got to hear from other S&I Projects.

Abby and I tromped on down to the Workforce Development meeting to say hi to Regina Holliday, who was busy painting today.  I got back upstairs in time to listen to Michael Buck's pitch for Query Health. He made several key points.  One is that we need Query Health because people don't trust the government (or anyone else) to aggregate data for them.  So we need to be able to send the question to the data.  Another is that we have questions in New York city like "how many patients are you seeing now (a few weeks after the hurricane), vs. a month ago (before it)" that are a) Very relevant to public health, and b) aren't (and wouldn't be) addressed in any quality measure.

Today's meeting was full of TLAs, FLAs, and worse.  I could barely follow the Longitudinal Coordination of Care discussions, and when CEDD came up (only the fourth acronym that thing has had), I explained it thus on twitter:  CEDD = The list of things that you can ask for in Query Health.

One of the key contributions (yet to repeated well in other S&I Framework projects) was the operational workgroup in Query Health.  As David mentioned earlier, technology is 20%, the rest is other stuff.  The operational workgroup addressed the other stuff in Query Health, including delivering policy guidance to the 4 pilots that it is running.  That's a big head start for this kind of stuff.  ABBI could use a little bit of operational guidance too.

Following the S&I overviews, we broke out into four sessions.  The best laid plans of ... went by the wayside.  We didn't quite unconference the discussion time, but came close.  I spent all my time in the Health eDecisions workgroup, and was perhaps the only volunteer present from that workgroup at a table full of Beaconista's.  It's a darn shame, because I haven't been following that project nearly as well as I should.  Since my daughter was next to me, I simply targeted my explanations of what we were doing to her level of understanding, and the folks at the table seemed to get what the project was doing.  We had some good discussions, but not nearly as much cross-fertilization as Jacob wanted, mostly because we lacked the S&I participation.  A shame, really, because a lot of great discussions could have started here.

After the discussion section, we broke for lunch.  The Beaconistas headed off to a separate meeting, and we planed to resume with the S&I Round Table, and ABBI Town Hall Meetings.  Abby and I went back to find Regina, took her order for lunch, grabbed nearby Chinese, and headed back to deliver Regina her lunch.  We invited Regina back up to "our" room to paint during the ABBI Town Hall (Regina was there an the conception of ABBI also), and she agreed.

The S&I Round table was disappointing.  Besides the fact that we'd already heard much of it in the morning (though most everyone else in the room had missed that crucial part, and thus the opportunities with the Beacon Communities), it was mostly the ONC project coordinators reporting out.  I really wanted to hear from (and see) more of the S&I Community.

I must have heard the phrase "not trying to boil the ocean" three times or more.  Doug must have used that phrase while putting the fear of the National Coordinator into project teams or something.  The other phrase I keep hearing is "like mint.com" in reference to ABBI.

A couple of quips made it into my twitter stream while this session was going on:

• Are you a start up, or are you an up start?
• Public Health = Silos of Excellence
• LOL! This mandatory slide (slide of model) included to show relevance of informatics modeling to this problem #ONC2012
• Current speaker tells ONC that we (S&I Framework) need: Governance, governance, governance, governance, governance ... [followed by scattered applause in the room]
• A care plan is not a care plan is not a care plan. Consensus still being developed here. Rishel's law applies.

Tomorrow's post will cover the ABBI Town Hall.  That was interesting enough to deserve a post of its own.

An mHealth Value Model

I spent a couple of days at the mHealthSummit 2012 in DC this last week.  A short summary of my impressions have already been posted.  What I want to do this morning is talk a little bit about the definition of Mobile Health (or as some like to call it, mHealth).

My definition is short and tweetable:  #mHealth is Connecting Healthcare without wires.

What I found at the summit was that while this definition clearly describes what vendors were offering, there was wide variety in the value mobile access provided. There are two ways in which you can look at it, the first is the barrier removed by mobile access, and the second is by what it connects.  The two are quite related:

Value	Barrier Removed	Connecting
▂	Wires	People to Devices
	A lot of what I saw simply exchanged wires for a radio and a mobile power source. This removes physical barriers, but not much else.  Some of the wire removal allows activities to be monitored outside the healthcare environment, which also eliminates the distance barrier. This leads to the next level.  At some point, I think we'll stop calling this "mHealth".
▂ ▃	Platform Variation	Developers to Mobile Devices
	One barrier introduced by Mobile is variation in platform.  We have Apple, Android, and basic Web (with HTML5+CSS) on the mobile device as different ways to create your application.  A number of vendors are working on making it possible to build one app for multiple platforms.  The audience for these tools is pretty limited.  Little of this is related to specifically to healthcare.  The few offerings I did see with any focused attention to healthcare in this spaced touted their "HIPAA" qualifications.  A reminder to you all:  HIPAA compliance is a property of an organization, not a product.
▂ ▃ ▅	Distance/Time	People to People
	Instant/unwired communication, including text, audio and video eliminates barriers related to time and/or distance. A good bit of this is simply a matter of hooking up a keyboard, speaker or camera to a radio, sometimes with a design intended for use in the healthcare environment. Some of what I saw didn't take the last step.  The more Healthcare oriented design that goes in, the more I feel comfortable fitting these offerings into the "mHealth" space.
▂ ▃ ▅ ▆	Ignorance	People to Information
	There are several levels in here. Web application that have a mobile friendly input/output is the most basic level. SMS access to information is very big in emerging markets where smart phones aren't ubiquitous. This has more value, I think, than simply mobile enabling a web site. One site connects your phone's camera (via an eTag) to a map of nearby an automated external defibrillator, which begins to move into level 4.
▂ ▃ ▅ ▆ ▇	Silos	Information to Information
	This is the highest level, and few mobile applications are there yet. Many are just creating new silos (e.g., Like my FitBit, which uploads to a website where I have to pay an annual fee to get access to the analyzed data, and have no access to the raw data). There are some PHR applications which connect your data with other data sources (e.g., MedLine Plus Connect), but these are still pretty limited.  This level has the highest potential value to both patients and providers.  BTW: If you make me type it in, you aren't thinking about my error rate on phone keypads, and I hardly count it in this space.

These "levels of value" shouldn't have any ramifications of "good" or "bad".  Removing wires can be very useful, especially when doing so eliminates significant risk for patients, enables care that couldn't be provided previously, et cetera.  My purpose in building this classification system is to understand the impacts of mobile health on the "cost curve" of healthcare.  I don't see offerings at level 1 having as much an impact on the cost/quality of the care that I get, as offerings at level 5.  Your mileage may vary.

HL7 Offers Free Ambassador Webinar on Standards for Interoperability Tuesday, December 11

Health Level Seven® International

For Immediate Release

                                                                               

Contact: Andrea Ribick

+1 (734) 677-7777

andrea@HL7.org

HL7 Offers Free Ambassador Webinar on Standards for Interoperability Next Tuesday, December 11

          Ann Arbor, Michigan, USA – December 6, 2012 – Health Level Seven® International (HL7®), the global authority for interoperability and standards in healthcare information technology with members in 55 countries, will present a complimentary Ambassador webinar on current standards used for interoperability next Tuesday, December 11, from 11:00 am - 12:00 pm EST.

          This webinar provides an introduction to current interoperability standards. The focus is on the principles of interoperability, exploring why standards are vital, why interoperability is difficult and why models are key to making it simpler. Historically standards have focused on either syntax (interchange formats) or semantics (terminology), but both are always needed. HL7 Version 2, Version 3 and CDA^® focus on syntax, while ICD, LOINC and SNOMED CT^® focus on semantics.

         The webinar will be presented by Tim Benson of Abies Ltd and author of Principles of health interoperability, HL7 and SNOMED, 2nd Edition Springer 2012. He is trained as a mechanical engineer and has spent his career in health informatics. Benson founded one of the first GP computer suppliers, which developed the Read codes that evolved to become one of the two sources of SNOMED CT. He also led the first European project team to assess the need for open standards in health informatics and has worked with HL7 for over 20 years.  

          This webinar is free and open to anyone interested in healthcare IT or standards development. To register for this free webinar, please visit http://www.hl7.org/events/ambassador20121211/.

HL7 Ambassadors present standardized presentations about HL7 as speaker volunteers. They are available to present at local, regional or national conferences. Please contact HL7 at +1 (734) 677-7777 if you would like to schedule an HL7 Ambassador for an upcoming event.

About Health Level Seven International (HL7)

Founded in 1987, Health Level Seven International is the global authority for healthcare information interoperability and standards with affiliates established in more than 30 countries. HL7 is a non-profit, ANSI accredited standards development organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. HL7’s more than 2,300 members represent approximately 500 corporate members, which include more than 90 percent of the information systems vendors serving healthcare. HL7 collaborates with other standards developers and provider, payer, philanthropic and government agencies at the highest levels to ensure the development of comprehensive and reliable standards and successful interoperability efforts.

          HL7’s endeavors are sponsored, in part, by the support of its benefactors: Abbott; Accenture; Allscripts; Centers for Disease Control and Prevention; Duke Translational Medicine Institute; Epic; the Food and Drug Administration; GE Healthcare Information Technologies; GlaxoSmithKline; Hospital Corporation American (HCA); IBM; Intel Corporation; InterSystems Corporation; Kaiser Permanente; McKesson Provider Technology; Microsoft Corporation; NICTIZ National Healthcare; Novartis; Oracle Corporation; Partners HealthCare System, Inc.; Pfizer, Inc.; Philips Healthcare; Quest Diagnostics Inc.; Siemens Healthcare; the U.S. Department of Defense, Military Health System; and the U.S. Department of Veterans Affairs.

          Numerous HL7 Affiliates have been established around the globe including Argentina, Australia, Austria, Bosnia and Herzegovina, Brazil, Canada, China, Colombia, Croatia, Czech Republic, Finland, France, Germany, Greece, Hong Kong, India, Italy, Japan, Korea, Luxembourg, Mexico, Netherlands, New Zealand, Norway, Pakistan, Puerto Rico, Romania, Russia, Singapore, Spain, Sweden, Switzerland, Taiwan, Turkey, United Kingdom, and Uruguay.

For more information, please visit: www.HL7.org

Harmonizing IHE PCC with HL7 Consolidated CDA

How do you harmonize a US Realm CDA Specification with a set of International profiles when:

1. Requirements of the US Realm specification clearly won't work in other countries (Canadian providers neither have, nor care about the US National Provider Identifier for example).
2. Every unique identifier already coded into the profile needs to be changed,
3. Versioning of templates wasn't designed in as best as it could be.
4. Vocabularies used in one country (e.g., LOINC) need to be changed to those used in another.

These are just a few of the issues that IHE PCC has been struggling with since the release of the Consolidated CDA, and yet, these are also issues that we are committed to resolving.  Either PCC contributes nothing to users of IHE profiles in the US, or PCC must adapt itself to the latest version of the HL7 CDA templates, without alienating existing implementers of the PCC technical framework in South America, France, Italy, China, Korea, Australia and elsewhere.

It's a tricky challenge, and we will very likely take it on in several steps this year.  That decision gets made tomorrow morning.

The first step is to allow for forward motion in templates defined in the PCC technical framework.  For example, the template for the IHE PHR Extract Document (1.3.6.1.4.1.19376.1.5.3.1.1.4) requires the presence of the following templates (among others):

• Allergies Section (1.3.6.1.4.1.19376.1.5.3.1.3.13), 
• Conditions Section (1.3.6.1.4.1.19376.1.5.3.1.3.8), 
• Medications Section (1.3.6.1.4.1.19376.1.5.3.1.3.19)

 The current interpretation of this requirement is that if you have:

<ClinicalDocument xmlns="urn:hl7-org:v3">

  <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.4'/>

  ...

Then later in the document you must have:

  <section>

    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.13'/>

    ...

  </section>

And:

  <section>

    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.8'/>

    ...

  </section>

And also:

  <section>

    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.19'/>

    ...

  </section>

By making a small change to the technical framework in a CP, allowing a version identifier to be stored in extension, we would now allow:

  <section>

    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.8' extension='2' />

    ...

  </section>

Note, however, that this is NOT truly a backwards compatible change.  What could break?

A system assuming that documents asserting conformance to a template by inspecting only the value of the root attribute wouldn't detect the introduction of the extension attribute.  They would move forward expecting conformance to a prior version of the template, and in certain situations, that assumption could fail (e.g., if we were to adopt the new mechanism to represent Concerns using a code attribute instead of a nullFlavor value).  If those systems didn't validate conformance to the templates, they could be expecting information to appear where it no longer does (again, the new Concern model).  That could cause a software failure.  Alternatively, if they do validate inputs,   but don't recognize the new templates, they wouldn't be able to process the communication.  However, the validation error would be detected and could be corrected by updating the software to address new content requirements.

In my reviews of changes from CCD version 1.0 (and HITSP C32) to CCD version 1.1, there are very few cases where the locations of clinical information content has been altered with respect to the CDA Content model.  So, it seems that this could work in the real world.

After this CP, we would then need to create a set of templates that represent NEW versions of the existing PCC templates.  These templates would include new requirements for related templates as they were introduced by Consolidated CDA, and would retain existing PCC content restrictions unless they conflicted with (as in, couldn't work with), the Consolidated CDA templates.

This set of changes would allow IHE PCC to publish a technical framework which would allow a CDA document to be produced that:

1. Conformed to PCC requirements
2. Conformed to Consolidated CDA requirements. 

This is NOT possible today.

There are a few other changes we'd like to make.  Right now, IHE PCC specifies a number of value sets used with templates.  The most common example are the codes used to record vital signs.  Instead of directly specifying the value sets, what we would do in the PCC TF would be to reference Concept domains.  Thus, the "Vital Sign Value Set" referenced in the original PCC TF would become the Vital Sign Concept Domain.  References to the Vital Sign Concept Domain would be resolved through realm bindings.  A Vital Sign Value Set using LOINC (the same value set currently specified by PCC today) could be bound to the Vital Sign Concept Domain for US Realm use.

To validate a CDA document conforming to a PCC template, we'd have to look at both the template definitions, and to the realm bindings.  This is doing nothing more than utilizing the realm binding mechanism that HL7 Vocabulary has already adopted for Version 3 standards (CDA is a version 3 standard).

In PCC, we'd also need to refactor some of the Consolidated CDA requirements into Universal (and thus template) constraints, vs. Realm specific (and thus Concept Domain) constraints.  Some countries simply won't adopt the same sets of vocabulary as we have in the US.  

We will also have to address this issue for certain classes of identifiers.  For example, rather than using the US National Provider OID in the template, we'd indicate that the assigning authority must represent a legal value in the realm binding's national provider ID namespace, and define "Identifier Domains"  similar to the way that Concept Domains are defined. 

Some constrained types found in CCDA may also have to be addressed through the Realm mechanism, including for example, postal address requirements.

Fortunately for IHE PCC, much of our existing body of final text templates has already been transcribed into MDHT, as has the Consolidated CDA content.  We should be able to compare related templates between the two, and perform appropriate refactoring.

Having completed this effort, what would you have to do to adapt an implemetation of a profile from the IHE PCC technical framework for use in an environment like the US where Consolidated CDA is the representation?

Here's how I think an implementation of a PCC profile would need to change to support both the PCC TF and C-CDA if we had this today:

1. Remove all code that generates HITSP template identifiers.
2. Remove all code that generates CCD 1.0 template identifiers.
3. For each IHE PCC template identifier generated, add the new version identifier to the extension attribute.
4. For each Consolidated CDA template in the PCC->C-CDA crosswalk found in the Consolidated CDA guide, add code to generate the new template identifier to the output.
5. Tweek generation of the "Concern" act to use the fixed code value specified in C-CDA (and version 2 of the IHE templates).
6. Fix representations of not known and known not in various places in your code.
7. Tweek a few other things (a list that has yet to be established, but which I hope to extract from MDHT algorithmically once I get rolling).

Unfortunately, we don't have this today, and MU implementations of C-CDA will be implemented well before we do.  So let's look at this another way, how could you implement the PCC TF functionality on top of your existing C-CDA implementation:

1. Add the new PCC template identifiers associated with C-CDA templates to your output.
2. Adapt your code to follow additional PCC TF constraints (e.g., required linkages from entry to narrative text).  This also is a list that I expect we would be able to extract from data recorded in MDHT.

This is NOT going to be the most fun project I've ever worked on, but it is necessary.  In the end, I expect we'll have a body of computable data, stored in MDHT, that will also assist IHE PCC implementers in creating new PCC template instances and validating content of instances against the text.

While all of this goes on, there will be new work going on in IHE and HL7 generating CDA templates.  As we establish new best practices going forward (e.g., concept domain use before localized value set definition), I'll be updating them here, and promoting them to other groups working on CDA.

Breaking News on IHE Certification

The following release found it's way into my inbox this morning. I got the paper copy yesterday at the IHE Interoperability Showcase at the mHealth Summit yesterday. If you want to learn more about it and are at the summit, stop by the Interoperability Showcase at #MHS12 and ask for Mike or Elliot.

-- Keith

---

ICSA Labs is very excited to join Integrating the Healthcare Enterprise (IHE) USA in announcing a new partnership to offer an IHE Certification track as a part of the 2013 IHE North American Connectathon and related testing events.

Earning IHE Certification will allow vendors who have developed advanced health IT the right to claim that their products have been tested and verified by an independent third party for interoperability and conformance to IHE technical specifications and profiles, utilizing an industry approved and recognized process that is based upon the stringent requirements of ISO Guide 65 and ISO/IEC 17025 that are used to test and certify health IT products that meet Meaningful Use requirements for the EHR Incentive programs today.

This is a major milestone for the healthcare industry. In addition to complementing Meaningful Use initiatives, IHE Certification by ICSA Labs will extend the availability of secure and interoperable health IT, advancing beyond the existing mechanisms that are required by the Office of the National Coordinator for Health IT under the Meaningful Use program.

More details will be announced shortly, including how vendors and heath information exchanges can sign up for testing and certification, beginning as early as January of 2013.
The text of the announcement follows.

---

ICSA Labs – IHE USA Certification Program Industry Announcement For Immediate Release

IHE USA is pleased to announce a new program that will provide industry-accepted certification to complement existing testing of conformance to IHE integration profiles. This new service will be delivered through a strategic partnership between IHE USA and ICSA Labs, and will commence at the 2013 North American Connectathon being held January 28 through February 1, 2013 in Chicago.

IHE USA and ICSA Labs both share the goal of accelerating the adoption of usable, secure, and interoperable health information technology, to further the goal of improving patient safety and delivering higher quality of care. To that end, these organizations have formed a collaborative partnership to advance the state of the industry. IHE Certification will provide purchasers of health IT products independent third-party assurance that there is a credible, repeatable process that ensures quality, and that these products will exhibit the robust capabilities for optimal data exchange and security that are demanded by our industry.

Founded in 1997 by the Healthcare Information and Management Systems Society (HIMSS) and the Radiological Society of North America (RSNA), IHE is a global non-profit organization that enables the collaboration of healthcare providers and industry leaders to work together to improve interoperability and exchange of health information. IHE utilizes a proven framework for standards based interoperability of health IT systems, which is being adopted and implemented worldwide by regional and national deployment affiliates such as IHE USA. Globally, IHE is founded upon a fully cooperative partnership model with over 500 member organizations that contribute over 2,000 individual volunteers to participate in IHE committees. IHE volunteers have a diverse background including clinicians, ambulatory practices, hospitals, medical societies, academic medicine, researchers, and vendors from across the globe. IHE has been testing conformance and interoperability of health IT systems for over a decade at annual events known as Connectathons, where teams of specialized technical experts monitor the testing of more than two hundred different participating systems. The ability to officially certify products for both interoperability and conformance will significantly extend the value for those systems that are successfully tested at the North American Connectathon, sponsored by IHE USA.

ICSA Labs brings to the partnership decades of experience as an independent and well-respected testing and certification entity, providing services for product certification of antivirus software, VPNs, firewalls, mobile applications, as well as FIPS cryptographic module validation, and malware analyses. ICSA Labs currently offers certification and testing under the authority of the Office of the National Coordinator's (ONC) Certified Health IT Program for Meaningful Use, and is designated as an ONC Authorized Certification Body (ONC-ACB), fully accredited by both the American National Standards Institute (ANSI) as a certification body, and by NIST as an Accredited Test Lab (ATL) for Health IT the National Voluntary Lab Accreditation Program (NVLAP).

“Implementing products certified to the IHE profiles will allow healthcare providers and hospitals to leverage more complex workflows, mature and scalable standards, and robust data exchange requirements as they build upon foundational standards that have been nationally recognized in the U.S.,” said Joyce Sensmeier, President of IHE USA and Vice President of Informatics at HIMSS. Certification will also be expanded to cover areas that have not been a focus of the CMS EHR incentive program to date, such as PACS imaging systems, Health Information Exchanges, and personal care devices. “This certification is meant to complement the existing ONC Health IT Certification program for Meaningful Use,” added ICSA Labs Managing Director, George Japak, “which was primarily designed qualify providers to receive monetary incentives.” The certification to IHE profiles, which also provide significant underpinnings to the ONC specifications, will offer decision makers the critical information and necessary confidence to properly evaluate the wide array of existing health IT products offered for purchase today.

Participants that are registered for the 2013 IHE North American Connectathon will be able to register for certification testing as an “add-on” track. Testing for Certification Track participants will be conducted by accredited Certification Testing Monitors, who will conform to the rigid requirements set forth by the ISO 17025 standard for the competence of testing and calibration laboratories. Results will be formally evaluated by the independent ICSA Labs Certification Body, which will grant certification based on requirements set forth by IHE USA, and the general principles covered by ISO/IEC Guide 65 for organizations providing product certification. Certification will also include industry-standard system surveillance activities that ensure that certified products continue to perform as tested in the field, as they are updated and enhanced over time.

Certified products will be published by IHE USA, as well as in the official ICSA Labs product directory. Three tiers of Certification will be awarded based on:

• Tier 1: Conformance to IHE profiles
• Tier 2: Demonstrated interoperability amongst disparate systems
• Tier 3: Validated Implementations of deployed certified technology

ICSA Labs will also partner with IHE USA to offer certification services in conjunction with the new testing events slated to launch shortly: Projectathons and Virtual Connectathons.

“Certification will be a voluntary process… those certifying against the IHE profile specifications will not be doing so to obtain incentives, but rather because this is considered best practice to advance quality and patient safety in our nation,” added Sensmeier.

Vendors interested in learning more about having their products certified to IHE integration profiles should contact IHECert@icsalabs.com

About IHE USA

IHE USA (http://www.iheusa.org) is a not for profit organization founded in 2010 that operates as a national deployment committee of IHE International®. IHE USA serves as a voice representing U.S. health IT interests and key partners in national health IT efforts for fostering the national adoption of a consistent set of information standards to enable interoperability of health IT systems. Learn more about IHE USA and their role in advancing health IT in the U.S.

About ICSA Labs

ICSA Labs, an independent division of Verizon, offers third-party testing and certification of security and health IT products, as well as network-connected devices, to measure product compliance, reliability and performance for many of the world’s top security vendors. ICSA Labs is an ISO/IEC 17025:2005 accredited and 9001:2008 registered organization. Visit http://www.icsalabs.com and http://www.icsalabs.com/blogs for more information.