American Health Information Community

Consumer Empowerment Workgroup Meeting

June 19, 2006

**Disclaimer**

*The views expressed in written conference materials or publications and
by speakers and moderators at DHHS-sponsored conferences do not
necessarily reflect the official policies of the DHHS; nor does mention
of trade names, commercial practices, or organizations imply endorsement
by the U.S. Government.*

> **[\>\>Gail McGrath:]{.underline}**
>
> Hi, everybody. This is Gail McGrath. I guess we\'ll start by calling
> the meeting to order. So we\'ll do that, and then I think Matt is
> going to give you a preview of the call-in features. Are you going to
> do that again, Matt?
>
> **[\>\>Matt McCoy:]{.underline}**
>
> Sure; it would be really quick. Want to do that right now?
>
> **[\>\>Gail:]{.underline}**
>
> Sure.
>
> **[\>\>Matt:]{.underline}**
>
> Okay. As we\'ve done the last couple calls, everybody who is in the
> Workgroup has an open line; just please keep yourself muted when
> you\'re not speaking, and if you\'re following along with the Web
> \[inaudible\].
>
> The only other thing: if you\'re listening along as a member of the
> public, you will have an opportunity at the end of the meeting to call
> in and make a comment or ask a question, and we\'ll post the number
> for that when the time comes.
>
> **[\>\>Gail:]{.underline}**
>
> Great. Thank you, Matt.
>
> Let\'s do this, before we get started: I\'d like to know who\'s on the
> call, so let\'s go ahead and introduce ourselves.
>
> **[\>\>Matt:]{.underline}**
>
> Okay. I\'ll just run down a list of the people we have on the phone to
> save time with this, and then I\'ll let Kelly introduce anybody who\'s
> in the room at ONC. In addition to our Co‑chair Gail McGrath, we have
> Ross Martin from Pfizer, Rick Ratliff is sitting in for Kevin from
> SureScripts today, David Lansky from Markle Foundation, Robert Tenant,
> Rob Kolodner, and I think we might have a few more Workgroup members
> calling in, but \[inaudible\] just gotten in, and we might have a few
> more joining us as we get going.
>
> Kelly, are there some Workgroup members there with you?
>
> **[\>\>Kelly Cronin:]{.underline}**
>
> Yes, we have Davette Murray from the Department of Defense and Justine
> Handelman from Blue Cross Blue Shield Association.
>
> **[\>\>Matt:]{.underline}**
>
> Okay. Gail, I think that\'s it for right now.
>
> **[\>\>Gail:]{.underline}**
>
> Great. Okay, thank you.
>
> I don\'t know how many of you were at the AHIC meeting on June 13, but
> obviously there was quite a bit reviewed there, and then Dr. Brailer
> did talk about \-- a roadmap for the future. And I think that now that
> we have a little more time than we previously had, we want to
> \[inaudible\] next few months really looking at playing out the
> critical components of our broad charge and what we need to do with
> those. So today, what we\'re going to do is go through sort of a
> roadmap and talk about what needs to happen in the next few months.
> And Kelly, I\'ve got to rely very heavily on you to sort of walk us
> through that.
>
> Is there anything else that I need to say, Kelly, right now?
>
> **[\>\>Kelly:]{.underline}**
>
> No, I think ‑‑ I think this really is just sort of a planning call, a
> call to sort of weigh in based upon everything we\'ve talked about
> over the last 4 to 5 months and try to agree on what we think needs to
> get done and prioritize if we have the time.
>
> **[\>\>Gail:]{.underline}**
>
> Okay. Before we get started with basically No. 4 on the agenda, the
> Workgroup roadmap, does anybody have any questions or anything that
> they would like to ask at this point before we get started on this?
>
> No? That\'s good. I\'ll take it that we can move right on.
>
> Okay, Kelly, you want to go through the discussion here, No. 4?
>
> **[\>\>Kelly:]{.underline}**
>
> Sure. In the agenda, we bulleted out the timetable that was presented
> to AHIC last week to try to guide all four of the workgroups\' process
> over the next 6 months and moving on to \-- even in 2007. And
> essentially, what we\'re trying to do is evolve into three phases,
> initially trying to collect information and \-- through testimony or
> background research so that we feel we have a good handle on what the
> critical components are of this broad charge, since I think all four
> of the workgroups really have a pretty significant scope to tackle.
> You know, with ours, it\'s really adoption of longitudinal,
> consumer-centric, easy-use, portable PHR, and within each of those
> objectives, there\'s a lot pulled into that and a lot that requires a
> lot more careful consideration.
>
> So I think first we need to feel comfortable that we have enough
> information to identify what the critical components are of the broad
> charge based upon what we\'ve done to date, or perhaps what we might
> do in the coming weeks, and then try to prioritize them and make sure
> that we\'re addressing those that are the most important or the most
> time sensitive first and map out exactly what we need to do in a
> workplan, in a detailed workplan that'll say exactly what we need to
> do in terms of background research, oral and written testimony,
> synthesis of literature, or expert opinion and the specific workgroup
> process that we need to undertake for each critical component. And
> then after we feel we\'ve done enough fact finding and we\'ve
> actually, you know, tried to identify what the barriers and enablers
> are for each of the major issues in the critical components, I think
> we'd like to move over to stakeholder concerns, where we do a
> stakeholder analysis. Everyone that isn't engaged, not only the health
> plans and the employers but obviously consumers and clinicians and
> caregivers, so that there\'ll be, I think, ample opportunity for us to
> really consider each of their perspectives and their roles in taking
> action.
>
> And then from there, we can move into drafting recommendations, once
> we feel we\'ve had enough time to really deliberate on these specific
> issues, and then repeat the process. So we basically want to make this
> more focused, more deliberative, and really have the whole group
> working on a set of specific issues that are really just a major
> component of the broad charge as opposed to trying to boil the ocean
> all at once.
>
> So we could focus, for example, on everything around functional
> requirement or interoperability up front and really have the next 2
> months be very focused on that particular issue so we can get to a set
> of recommendations that we can all comfortably support as opposed to
> trying to do what we were doing in the past, which was policy issues;
> interoperability and functionality; and consumer awareness and
> education in parallel, where I think it became quite challenging for
> us to do it in a compressed time frame. So we\'re going to make this
> more of a sequential process and try to, at least by December, come up
> with a second letter of recommendation that would hopefully tackle two
> of our critical components as we identify them.
>
> **[\>\>Gail:]{.underline}**
>
> Kelly?
>
> **[\>\>Kelly:]{.underline}**
>
> Yep.
>
> **[\>\>Gail:]{.underline}**
>
> How about if we do this? Because I want to make sure everybody in our
> group has an opportunity to weigh in and understand for each month.
> And I guess first of all, looking at the roadmap and the timetable,
> does everyone feel that this is a reasonable guideline moving forward?
> I think that\'s the first question.
>
> Do we have any comment on that?
>
> **[\>\>Davette Murray:]{.underline}**
>
> The only comment I would make \-- this is Davette Murray \-- is the
> scope and depth we\'re going to go into each area, because while the
> timeline says we're going to do each thing, I think the group has to
> agree, on each juncture, what our scope is going to be as we
> \[inaudible\] so everybody knows up front exactly what we\'re trying
> to achieve.
>
> **[\>\>Gail:]{.underline}**
>
> Well, that\'s what I was going to suggest: that we go to each month
> and talk about each one of those so that we can make sure that we all
> understand, first of all, what we need to do, and secondly, if we have
> any questions on that.
>
> **[\>\>Kelly:]{.underline}**
>
> Right. One of the things that we may want to think about is actually
> identifying what we think a critical component is and use that as an
> example to walk through, because it\'s sometimes hard to talk about,
> you know, without a real example or something really tangible.
>
> **[\>\>Gail:]{.underline}**
>
> Well, maybe what we can do then, Kelly, is look at June, because while
> we\'re talking about developing a workplan that lays out the critical
> components of the broad charge, do you have framed the critical
> components of that so that we can kind of understand exactly what
> those are?
>
> **[\>\>Kelly:]{.underline}**
>
> Well, now, I mean, really, the discussion today was going to try to
> validate what they are or really propose if we think it\'s different
> from what we\'ve been discussing in the last 4 months. I did share
> with the group a draft outline of a workplan that really is just ‑‑
> it\'s \[a\] very, very rough draft of a way we could potentially be
> looking at some of the issues, but again, I don\'t really ‑‑ no one
> offered a critical component to start with, so I just tried to pull
> from what we had already discussed publicly and in previous meetings
> to put together some of the sort of major themes that came out of
> that.
>
> But I think if we think about our draft recommendation letter that we
> started off with in, I think, the end of April, early May, we had a
> much longer list of recommendations, as we all remember, and we did
> have three major areas in that ‑‑ the way we categorized them and the
> one ‑‑ one set of recommendations are around interoperability; another
> set were around policy, although they were predominantly focused on
> privacy and security; and then the process for that, for those issues.
> And then the final category was education and awareness.
>
> So that would be one potential way we could look at the critical
> components, but I think it\'s important for everyone to sort of
> discuss what we think they really are and is that the right way to
> categorize them.
>
> **[\>\>Gail:]{.underline}**
>
> But I think probably the difference in our recommendations for me to
> think is, we were really working on the specific charge as opposed to
> \-- now we\'re kind of heading toward the broad charge. Am I correct?
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah, you\'re absolutely right. And what ‑‑ what I think we recognized
> early on is that a lot of the things we were struggling with, when it
> comes to medication history and registration summary, are so linked to
> a personal health record that inevitably what we were trying to tackle
> was really the major issues for a PHR, and that\'s why we ended up
> with sort of, you know, refining and taking out some of the
> recommendations that were more in a developmental stage, because
> they\'re so not integral or they\'re so connected with our broader
> charge.
>
> **[\>\>Gail:]{.underline}**
>
> And our broad charge is to make recommendations to the Community to
> gain widespread adoption of a personal health record. So I think that
> while the specific charges were part and parcel of this, I think that,
> you know, this is going to be more critical as we move forward to get
> all of this into what\'s needed for a personal health record.
>
> **[\>\>Rob Kolodner:]{.underline}**
>
> This is Rob Kolodner. One of the things, particularly on a schedule
> like this, where we\'re going to have a timetable and turn the crank
> periodically, is, we\'re going to have to learn what is the right size
> for something that we can take on each one of these things. And
> without the background of support, I think it\'s going to be a
> learning experience with the first time through.
>
> **[\>\>Gail:]{.underline}**
>
> Well, I think that\'s a very good point.
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah, I think \-- building on what Davette said, too \-- if we can
> sort of agree on what we think our critical components are and define
> them, to some extent, where we understand what the depth is of what
> can we reasonably get into in a 2- to 3-month period through
> testimony, background research, you know, synthesis of what\'s known,
> expert input, I think we can then more realistically understand to
> what level of detail we can get into, that it would be helpful to
> start to define that today.
>
> **[\>\>Gail:]{.underline}**
>
> Kelly, this is Gail. Help me understand here. If we\'re laying out the
> critical components of the broad charge for a personal health record,
> then we need to know basically all the parts that would go into that,
> and do we know that? I mean, do we know what those are?
>
> **[\>\>Kelly:]{.underline}**
>
> Well, I think if we\'re thinking about it in terms of function or the
> features of a PHR, I think they\'ve been described at a high level,
> but that\'s one of the questions, I guess, on the table \-- is, "Do we
> want to take on a definition of a PHR if they are evolving quickly in
> the marketplace?" There\'s not a lot of standardization, but we did
> start to identify through previous meetings what we thought maybe a
> core list of functional requirements might be, so we did start to go
> down that path, but I don\'t think that we\'ve sort of definitively
> set on either a definition or sort of a list of what we think to be
> the most important functions.
>
> And I think we also expressed some concern about not having a lot of
> information. We don\'t really know what consumers want yet. We have a
> little bit of policy and research to draw on, but we don\'t really
> have, through the definitive survey or \-- you know, a really good
> handle among a pretty broad base of consumers of what they really want
> in this area.
>
> **[\>\>Gail:]{.underline}**
>
> So could that be part of the plan, then, that we would do a survey
> that we would find out?
>
> **[\>\>Kelly:]{.underline}**
>
> Well, I think ‑‑ I think that\'s one of the things we probably need to
> think about in terms of realistic scope. You know, there\'s Blue Cross
> Blue Shield Association, and AHEP has done some work. I think we had,
> you know, a handful of other, smaller research efforts that we might
> be able to try to, you know, quickly get access to results and
> summarize what we know. But I don\'t think we\'re, in the short term
> \-- meaning over the next few months \-- we\'re going to have sort of
> the definitive information that we\'re looking for.
>
> **[\>\>Justine Handelman:]{.underline}**
>
> One thing I'll just \-- this is Justine with Blue Cross Blue Shield
> \-- I think many of you know many of our plans are already offering
> PHRs, our commercial insurers and others. And we do have a genetic
> project under way, and we\'re happy to share and coordinate work with
> you where we did bring together consumer focus groups, and look at our
> plans and what components are being offered and come up with a minimum
> set of data elements, if you will, that we think, from all of our
> research, should be in a PHR, that being the agreement where we're in
> commonality in thinking that\'s not the end-all-be-all, everyone,
> every provider, whether it\'s a health plan or a provider or, you
> know, a consumer who'll buy the product \-- that the PHR can add
> anything else they want to \-- at least lower the minimum component.
>
> And we felt that that was critical, to have minimum components, if
> only because then we can build around more to the portability and
> interoperability standards, because we do want to get this out there
> and have widespread use and prevent one thousand players from
> presuming differently than talk to each other, at least that core set
> has to be defined and be able to interact, with others, whether it
> means one carrier to another or from a carrier to having their
> provider access it, and our whole focus is to put it out in the public
> domain. So certainly, if there\'s work that we've done that can be
> helpful from our research and identifying where we\'re headed, we\'re
> certainly happy to work with you to put that out there.
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah, I think that, you know, we did, in the last couple months, not
> only learn more about what AHIC \[inaudible\] were doing, but we also
> learned more about what the HL7 process is doing and a few other
> groups that are engaged in this area, so we have a fair amount of good
> information to start off with in terms of what\'s already happening
> out there. But yet I don\'t think we have some of the underlying
> research base to inform everything in a definitive way. I think a lot
> of vendors are trying to learn from their experience as they go along,
> and they\'ll create the tools that respond to ‑‑ or that are in
> response to consumers\' needs or demands. So it seems to be sort of an
> evolutionary process, so it\'s maybe not realistic for us to have the
> right ‑‑ have the research \[inaudible\] that we want to \-- in real
> time to coincide with this. We\'ll have to just go with what we know
> at this point, and I \--
>
> **[\>\>Rob Tennant:]{.underline}**
>
> If I can make a couple comments. It\'s Rob Tennant from MGMA. A couple
> things that strike me. Critical components of the broad charge to me
> also signal principles, and as Justine said, there are folks that are
> working on this. I wonder if we can do a couple of things. One would
> be to create a matrix of things that have to happen, work products
> with a timetable and ‑‑
>
> **[\>\>Kelly:]{.underline}**
>
> Rob, we\'re losing you.
>
> **[\>\>Rob T.:]{.underline}**
>
> Yeah, I\'m thinking that we need to create a matrix that would allow
> us to lay out all the work that we need to do, perhaps define work
> leaders, maybe subcommittees, things like that, and I also think it
> might be wise for us to invite some industry folks to come in to
> meetings or present materials via e‑mail on their various activities;
> for example, the ASTM group that\'s developing the CCR. We sort of
> talk about things, but we really don\'t have a lot of knowledge on
> them.
>
> So I think if we get some participants to come in to talk about what
> they\'re doing, perhaps Justine can invite folks that are intimately
> involved in the development of the Blue Cross Blue Shield PHR and
> things like that.
>
> **[\>\>Kelly:]{.underline}**
>
> Right. I think that's really helpful. I should just specify that when
> we were talking about components, we really were not meaning
> principles per se. We\'re really just trying to organize the workgroup
> process so that everything you need to do and talk about and
> deliberate on related to interoperability or functionality could be
> done maybe as the first critical component. And if we need to have
> perhaps, you know, subgroups or certain people really focus on
> different aspects of that issue, then we could set it up that way. But
> we\'re not really equating these components with principles per se.
>
> **[\>\>Rob T.:]{.underline}**
>
> Well, I think, though, that the look and feel of the PHR is going to
> vary tremendously and might impact what the components are, because
> when you think of PHRs now, you\'re thinking of everything from paper
> to Web based and everything in between. And we might want to ‑‑ again,
> we might want to create a matrix with a different form, form or
> formats of the PHR, because I don\'t think we can recommend one form
> over another. I think ‑‑
>
> **[\>\>Kelly:]{.underline}**
>
> Rob, you\'re fading in and out.
>
> **[\>\>Rob T.:]{.underline}**
>
> That\'s not by design. But I\'m thinking that there are so many
> varieties of PHRs that in my mind, overall arching principles are
> probably the most important thing that we can develop.
>
> **[\>\>Kelly:]{.underline}**
>
> Rob, we can\'t really hear you.
>
> **[\>\>Gail:]{.underline}**
>
> I \-- this is Gail \-- I can hear him. Basically, what he\'s saying is
> that since we don\'t know what the components are, that the best thing
> that we can do, since there\'s so many different products out there,
> is really to define the principles of what they should include. Is
> that right? Did I get it right, Rob?
>
> **[\>\>Rob T.:]{.underline}**
>
> That\'s even better than what I said, so.
>
> **[\>\>Matt:]{.underline}**
>
> Kelly, just that \-- Rob\'s line is coming through fine so you
> might, if the IT people are available, have them check out your
> speakers. It might be something on your end.
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah, I can hear you fine, Matt, but everyone else is breaking up from
> our perspective. We\'re looking into it.
>
> **[\>\> Matt:]{.underline}**
>
> Okay, thanks.
>
> **[\>\>Gail:]{.underline}**
>
> Now, I think Rob\'s right. I think that as we move forward right now,
> we have an opportunity to do a couple of things. One is to see what
> the lay of the land is out there, because there are lots of different
> products that are being developed. And if we could actually get either
> a summary of those or a presentation on those, I think it would help
> tremendously. Secondly, I think that he\'s right also in preparing a
> matrix that kind of lays out what \-- the components that are needed
> for a PHR, but to lay it out in order so that if there are problems,
> we can put that in the matrix. I think that would be very helpful.
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah, I think, as others have noted, that that has been done to a
> certain extent and may be what would be useful also to try to not only
> identify the ‑‑ what a PHR might look like in terms of what it will
> do, like major categories of functionality, but then try to crosswalk
> to find out who\'s already doing what; who already identified that;
> you know, to what extent has anyone looked at, you know, requirements
> for EHR-PHR interoperability or the data elements that would be
> necessary to, you know, medication refill. I think there\'s so much
> going on, we need to try to capture and build off of what others are
> already doing to understand the landscape. But I think essentially in
> July, in the timetable that\'s in everyone\'s agenda, that\'s what we
> were referring to, is really trying to get through that ‑‑ the initial
> part of taking on a critical component. We do \-- it\'s not feasible
> in an intense environmental scan to really get a handle on what we
> know to be happening out there.
>
> But I just want to also try to differentiate that when we were talking
> about components, we weren\'t necessarily talking about components of
> an electronic health record system or a personal health record system
> or a biosurveillance system, like with the other workgroup. We\'re
> really talking about the ‑‑ our workgroup process. So what do we need
> to be concerned with as a workgroup to identify all the major issues
> that are important to realizing widespread adoption of PHRs? So it\'s
> not so much focused on the software; it\'s more focused on what are we
> trying to accomplish. What do we need to do to get ‑‑ what do we need
> to be thinking about and organizing our thoughts around in terms of
> widespread adoption of interoperable, longitudinal, easy-to-use PHRs?
>
> **[\>\>Gail:]{.underline}**
>
> I think that\'s more helpful to get that understanding, but I still
> believe that however we do this \-- and we do need to develop this
> workplan, but I think that we need to see what is going on, because
> you can\'t really move forward until you understand where you are and
> what the basic is. And I\'d really like to see what\'s going on out
> there with the development of some of the ‑‑ I know \-- I just heard
> the other day, I guess, that Google has something going right now.
> I\'d love to see what they\'re doing.
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah, and that\'s really what I think an important part of our fact
> finding and our data gathering in the \-- early on as we tackle each
> issue. So if our first issue is functionality and interoperability,
> then we\'re trying to do, you know, our very quick environmental scan
> of what are vendors offering now, and what are they responding to in
> terms of market demand, and are they really taking in good
> consideration what consumers want. We try to get testimony, written
> and oral; we can, you know, look at our existing matrix that we
> already put together, our inventory of all the PHRs that we know of;
> we can, you know, talk to a variety of people in the trade
> associations and elsewhere to really try to get our pulse on what\'s
> happening out there. So that\'s really going to be ‑‑ that\'s No. 1
> once we have identified what our workplan is and we know what our
> first critical component is.
>
> **[\>\>Justine:]{.underline}**
>
> I think what would be critical in that is, I mean, if a lot\'s
> happening, we know, but our consumers using it in key value, and I
> think from our experience with our claims that are doing this, the
> clients that are doing \-- simultaneously giving patients access
> information and giving providers that information, that\'s where
> there's the most traction of value, because you\'re able to have the
> two come together and talk. And I think it\'s critical. It\'s one
> thing to see what\'s going out there and what are people offering, but
> if it's being used and what\'s the value and why is it being used. I
> think that\'s just really critical. And on the other side, I know PHRs
> that are consumer controlled, but is there any way to give providers
> access to that information, whether the consumer authorizes that to
> happen and how, because that\'s really where we're seeing the traction
> \[inaudible\].
>
> **[\>\>Rick Ratliff:]{.underline}**
>
> Kelly and Gail, this is Rick Ratliff with SureScripts. Just a couple
> of comments, and I\'m fairly new to the group, so hopefully these are
> in line with the discussion that we\'re having.
>
> It seems to me, if I look at the outline that I believe Kelly said
> she'd put together on the workplan, there\'s in No. 5, our key
> components that are identified, and if we could get agreement \-- are
> those the components? Are we missing anything? Does it consolidate it
> essentially, et cetera? I think that\'s really the first point to your
> \-- or first step, and your point is going to be critical to help us
> move forward.
>
> The challenge will be, once we get those outlines, if can we take a
> sequential analysis for each one of those at the level of detail that
> I think is being suggested, that this timeline\'s probably not
> realistic. So I don\'t know if you\'re assuming that you\'re going to
> essentially break up into parallel efforts or not, but just getting
> through the functionality \[inaudible\] and interoperability ‑‑
>
> \[Interruption by electronic feedback.\]
>
> **[\>\>Kelly:]{.underline}**
>
> Can you all hear us now?
>
> **[\>\>Rick:]{.underline}**
>
> We can hear you now.
>
> **[\>\>Rob K.:]{.underline}**
>
> That's actually much better.
>
> **[\>\>Kelly:]{.underline}**
>
> Okay. Great. We just had to switch phones. Okay, great.
>
> **[\>\>Gail:]{.underline}**
>
> Well, maybe \-- Rick, you make a very good point there, but let me
> suggest something. Since we have a draft outline for a workplan, I
> think what\'s going to be important, though, is to make sure that our
> Consumer Empowerment Workgroup believes that this is the right
> workplan to move forward and if there are parts of this that need to
> be changed, then we need to look at that to be sure, because at the
> end of the day, we want to make sure that we come out with whatever it
> is we\'re trying to do.
>
> But ‑‑ so I think that what we\'re talking about in June, developing a
> workplan, I think that probably for this month, we should concentrate
> on, "Is this the right plan? If not, what are the parts that work, and
> what are the parts that don\'t?" And if we could get that nailed down,
> then I think we can be ready to move on to the next phase for July.
>
> **[\>\>Rob K.:]{.underline}**
>
> This is Rob Kolodner. I think the key thing that we heard at the AHIC
> is that the Secretary does want us to go through a couple of cycles
> and that the idea is that we show motion and just have to have the
> cycle sized so that we can make progress, and I think the point that
> Rick made about "Do we run parallel, or do we run sequential or
> interlace it?", I think, is important thing for us to resolve.
>
> **[\>\>Ross Martin:]{.underline}**
>
> This is Ross Martin, Pfizer. Another option is to run it in an
> iterative fashion, and if I look at the draft outline that Kelly put
> together, I think it\'s a decent formation of where we need to go, but
> one of the things I think we need to establish in this broader scope
> is how do we ‑‑ how do we iteratively enhance what we are doing and
> have a cyclical process for expanding functionality, going to the next
> level, because we know that each step that we take with this is going
> to be incremental in nature. Even if they\'re pretty big increments,
> it will still be steps along the way. And I think one of our primary
> objectives in this broad charge is establishing that process for
> iterative improvement in this.
>
> And part of that is what we\'ve already talked about before being the
> notion that you want to create a minimum set of standards, a minimum
> set of expectations about interoperability, about functionality, but
> always leave the door open for entities to go beyond that baseline
> functionality and interoperability capability in \-- so that they can
> keep things moving forward. I\'d like to see that concept built into
> the vision and scope of this group and, you know, frankly, of all of
> them, that it\'s just a vacant principle to go on some of the earlier
> comments to say, "I agree that we need to build some fundamental
> principles about how we\'re going to go about this."
>
> \[Silence\]
>
> I don\'t know if that\'s a good sign or a bad sign.
>
> **[\>\>Gail:]{.underline}**
>
> I think everybody\'s just thinking through that, Ross.
>
> **[\>\>Kelly:]{.underline}**
>
> Ross, you actually \-- you bring up a good point that we hadn\'t
> really thought about before, with respect to having some of these
> issues be best addressed in an iterative fashion, so if we know that
> whatever we discuss in terms of functionality is really going to drive
> a lot of requirements with respect to interoperability, then should we
> in fact try to perhaps tackle those two components in parallel but try
> to go in with some, you know, working assumptions that we\'re not
> trying to take on, you know, and identify at sort of a super set of
> requirements, but that we\'re really trying to all learn and get
> enough of a handle of what\'s going on out there and what\'s feasible
> and what people really think is the most important so that we end up
> with our minimum set or our baseline.
>
> **[\>\>Ross:]{.underline}**
>
> Yeah, I look at the minimum set, the issue being really related to our
> narrow scope charge, our immediate charge with \-- you know, we\'ve
> all been jumping through these hoops to get done with this initial
> scope work. And we\'ve all, you know, had \-- kind of suffered through
> that and knowing that it is a first pass, it is a first round, and I
> think tolerating a lot of not only ambiguity but just incompleteness
> of what we know is a much bigger issue.
>
> So in order to get something out of the gate in an early time, we've,
> you know, tried to narrow the focus, tried to just be a little siloed
> in this, knowing that\'s not really going to work in the long term. So
> now when we think about this broad charge, it\'s ‑‑ to me, I don\'t
> look at that as about what\'s going to happen, okay, over the next 2
> years. I look at \-- that\'s \-- what\'s going to happen over the next
> year or 2 years is in one iteration of this first narrow scope. Okay,
> now we have another narrow scope in this second phase, but all along,
> what we need to build is the mechanism for ‑‑ for this broader charge
> of how we\'re going to do this over the next 10, 15 years.
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah, I think that\'s really helpful as well, Ross. The other thought
> that I would have, in terms of timing, is that I think we all
> recognize that the market\'s moving so fast that there might be some
> real short‑term considerations with what needs to be done to make sure
> that we have the part of the broad charge that, you know, we all agree
> is really important; for example, having it to be, you know, consumer
> controlled or consumer centric and easy to use. There\'s perhaps going
> to be a lot happening quickly that we\'ll need to really keep up to
> speed with to the extent feasible and make recommendations that are in
> line with how quickly the market is responding.
>
> **[\>\>Davette:]{.underline}**
>
> I have a comment. I get very leery when we say "easy to use" or
> whatever, because I\'d like to add to the comment you made earlier
> about looking at the products that customers are actually using,
> because sometimes consumers will be using a product for various
> reasons, but that\'s not necessarily an indication that the product is
> easy to use. So in my mind, I just have a question for the group. As
> ‑‑ if we do these product reviews, are we looking for a combination of
> the products that are most being used out there and what their
> functionalities are? And also, does the group have a position or want
> to give a recommendation, although the most used product offer
> whatever XYZ type of functionality, in the group\'s opinion, is that
> functionality broad enough for where we think the PHR should go?
> Because, you know, we may have products out there that are being used
> very much, but do they have enough functionality for where we think
> that the PHR should be, for where they\'re thinking 10 years down the
> road, the kind of information people should be getting?
>
> **[\>\>Kelly:]{.underline}**
>
> That would suggest that we want to be thinking in terms of what\'s the
> market reality today, in terms of the most commonly used products, but
> then, sort of, what do we think is the most important as a midterm or
> long‑term goal?
>
> **[\>\>Davette:]{.underline}**
>
> Correct.
>
> **[\>\>Rob K.:]{.underline}**
>
> This is Rob Kolodner again. I think one of the things to think about
> is the role that we play within the whole scheme of things. And the
> marketplace is going to drive some of those decisions and usually the
> top-down of what should the solution be isn\'t necessarily what the
> consumer from the bottom up ends up driving. So what we need to look
> at is, given our role and the position we have, what are those levers
> that we should be exercising, and what parts of this should we be
> setting up? And that may be in the policy level. For example, it may
> be some of the interoperability aspects as well that we can contribute
> rather than thinking that we can shape the entire system.
>
> **[\>\>Helen Burstin:]{.underline}**
>
> Yeah, this is Helen Burstin from AHRQ. I was going to say something
> remarkably similar to what Rob was going to say. I think we should
> sort of take a step back and think about what\'s unique in value added
> that we could add in as the Community, being a Federal private
> partnership, that others in the private sector won\'t do on their own.
>
> And for example, things like PHR standards, I think, are something
> that probably might be an example of the kinds of things that
> probably, with, you know, Federal support, would be \-- would move
> more quickly and more across the board.
>
> **[\>\>Kelly:]{.underline}**
>
> That\'s a really good point, Helen and Rob. And I guess it goes back
> to what we are talking about before, trying to get to the, you know,
> who should do what to change this and what is sort of specifically our
> to-do's to really push this forward. What are our roles in \-- you
> know, across all the stakeholders that are represented on this call?
> What can we all do? Not necessarily for the worker process, but coming
> out of the process, what can we act on? And how could we recognize the
> appropriate organizations to take on, you know, a process that would
> find functional requirements or, you know, if we go down this road,
> certification or, you know, who could be implementing incentives? Who
> could be, you know, overall the enforcement arm over industry?
>
> **[\>\>Rob T.:]{.underline}**
>
> It's Rob Tennant here. I wonder if we might want to speed that
> approach by inviting Dr. Mark Leavitt to speak. It seems to me a
> fairly obvious home for this certification of PHR would be the CCHIT.
> At a minimum, their structure is such that it lends itself to look at
> PHRs. And if we settle on that, then that sort of removes the big
> chunk of work, and then we\'ve got to focus in on what we can do to
> support them.
>
> **[\>\>Rick:]{.underline}**
>
> This is Rick Ratliff again. I was about to make a similar comment in
> that that organization has also, as most of you know, gone through the
> process to define requirements for the electronic health records,
> right? So potentially, there\'s some elements of their process or
> their fact gathering that we can leverage to pull together the
> requirement components and potentially the minimum standard set and
> then the follow‑on certification process that would follow, if nothing
> else, just to inform our process so we\'re not recreating the wheel.
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah, I think before we get too far into this conversation, it would
> be helpful just to have more workgroup input on what we think these
> critical components are, because certainly issues around
> functionality, interoperability, or certification are all sort of
> bundled together, and there\'s a lot to think about and a lot of
> people to talk to really, you know, do enough research and background
> work before I think we\'d all feel comfortable, you know, moving
> forward in a significant way. But certainly Mark Leavitt would be a
> great person ‑‑ would be a great resource to this group over time.
>
> But I think we haven\'t really had enough of a discussion yet on what
> we think the critical components might be. I mean, should we go back
> to our old model of putting this up, which was, you know, policy
> interoperability and consumer awareness in health literacy? Or do we
> want to think about a different way of stratifying this or describing
> what the critical components are?
>
> **[\>\>Justine:]{.underline}**
>
> I have a quick question as to \[inaudible\] context. I know that the
> AHIC meetings \[inaudible\] for government programs, and I guess some
> of the questions are \--
>
> **[\>\>Kelly:]{.underline}**
>
> If you\'re talking, you need to speak up, please.
>
> **[\>\>Justine:]{.underline}**
>
> All right. Some of the questions are: on our specific charge where we
> had some recommendations for the broad charge, is this something the
> government\'s going to look to do, and are there certain agencies we
> are going to target to do things first then or not, certain components
> in the registration information and medication history? And maybe this
> was answered. I missed the beginning part of the meeting. But just how
> are we going ‑‑ I know part of the Secretary and I \-- it makes sense
> \[inaudible\] you have many government programs that can do things out
> there \[inaudible\], but what is the end goal or the timeline of \--
> are things going to be moved forward, and just kind of stepping back
> and thinking, "Well, what do we do? Do we want to look and answer some
> questions, have some questions answered around that, and then
> determine if we are going to look at a targeted approach or a limited
> population? What work do we need to do to make sure that that\'s
> successful?"
>
> Does that make sense?
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah, I think that the implementation of the recommendations around
> the specific charges are going to take on a life of their own, and
> while they might be somewhat related to what we\'re doing, you know,
> to figure out the standard adoption process internally across all the
> Federal agencies is really going to be complicated, and there\'s a lot
> of, you know, issues around procurement and contracting cycles, and
> that\'s really not that relevant to what we\'re doing. But certainly
> if CMS and AHRQ and DOD and DA end up, you know, collaborating on
> getting medication history out to beneficiaries, then that\'s
> something that we really could stand to learn from over time and could
> be, you know, perhaps brought back to a certain time.
>
> But I think in terms of what ‑‑ how is the government going to act on
> it, a lot of our initial recommendations on May 16 were more HHS
> oriented or Federal Government oriented, but that\'s not necessarily
> the way we have to be thinking, because I think we\'re all in this
> together and we all have a very important role to play. And much of
> what we need to be doing, I think, moving forward is identifying what
> everyone needs to do moving forward, and not just what is the role for
> HHS or VA or DOD or OPM, but what can Blue do, what can provision
> organizations do, what can those consumer groups do? And we did start
> to get into that, I think, before, when we, you know, were thinking
> about what would be necessary to collaborate to do some major consumer
> education campaign or, you know, how would we potentially take on some
> of the policy issues that would be both in the private and public, you
> know, payer category.
>
> But I think ‑‑ I don\'t think it\'s ‑‑ it\'s absolutely important for
> government to be acting on what comes out of the process, and we will.
> There\'s already stuff being taken, you know, from what's been
> presented from May 16, but it\'s going to be somewhat separate from
> what we\'re going to be doing moving forward.
>
> **[\>\>Justine:]{.underline}**
>
> The reason I ask is, I just think that we need to tie the two
> together, because if you want to do a broader PHR, I think that PHR
> would include registration information and medication history. And if
> there are standards that are identified for that and put to use, it
> needs to tie in, too, because you don\'t want to create silos; you
> want it all to fit together, and eventually you want that PHR. I would
> think one of the longer-term visions is to interoper‑‑ interoperate,
> is that a word? ‑‑ be interoperable with the electronic health record,
> and so these all do have to somehow come together. And how is that
> coming together \-- and I just don\'t want us here to go down a route
> that\'s not in ‑‑
>
> **[\>\>Kelly:]{.underline}**
>
> Right. Yeah. I think \--
>
> **[\>\>Justine:]{.underline}**
>
> \-- where the other ones are, because they all have to come together.
>
> **[\>\>Kelly:]{.underline}**
>
> Absolutely. And I think one of the points of confusion \-- and I think
> we own some ownership over this \-- that what a breakthrough is or
> what a breakthrough is particularly relevant to this specific person's
> broad charge was never really made clear. And I think that we\'re not
> necessarily talking about what the Federal Government is going to do
> to do a major PHR adoption breakthrough. I think that what we\'re
> really talking about is what are all the major things we need to think
> about, private sector and public sector, to move things forward.
>
> So it\'s not representative of one super project that would build off
> of, say, a AHRQ-CMS-DA medication history and registration summary
> pilot. I think that the pilots will inform our work and all of our
> other discussions for the last 4 months will inform what we decide on
> in terms of functionality or interoperability, because we\'ve already
> gone down into a fair amount of detail, but not as much as we need to.
> But, you know, what comes out of HITSP will be helpful to us, maybe,
> in our future deliberations. But I think we also need to be mindful of
> the fact that what we prioritize and what we consider to be, you know,
> important in the short term could end up feeding into use cases, into
> \[inaudible\] like a standards panel and potentially the Certification
> Commission, depending on which way we go. So to the extent that
> that\'s, you know, an important consideration, I think we need to be
> aware of the fact that the \-- of the workgroup role in informing use
> cases in 2007.
>
> **[\>\>Gail:]{.underline}**
>
> So where does that leave us right now then?
>
> **[\>\>Kelly:]{.underline}**
>
> Gail, I think it would still be helpful to get people\'s input on what
> we do think the critical components are. Do we want to go back to our
> old model dividing up into sort of functionality, interoperability,
> policy issues, and then consumer education and health literacy issues?
> Are those the right components, or do we want to think about a
> different construct?
>
> **[\>\>Gail:]{.underline}**
>
> Well, I don\'t know about the rest of the people, but I honestly, I
> think those certainly are the basics, unless there are others that we
> need to add to that, but I can\'t imagine that it wouldn\'t have this
> in there.
>
> **[\>\>Rick:]{.underline}**
>
> So Kelly, if those are the four broad constructs, then do things such
> as certifications that are underneath one of those such as
> interoperability and functionality or ‑‑ ?
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah, I would think that issue would actually be related to both. So
> perhaps maybe that\'s one reason why they should be considered in
> parallel.
>
> **[\>\>Rick:]{.underline}**
>
> Right. Then another question I would have is, you do have a bullet
> here that says "Privacy and Security Recommendations." Then does that
> fit under the policy side, or is that potentially across all
> workgroups actually?
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah, it will go across all workgroups, and we\'re still finalizing
> the membership and the leadership of that group. But we will be really
> linked to that process, and we\'ll have workgroup members that will be
> in common so we can keep both processes informed and up to date and
> get reports on, you know, what\'s happening. So I think we\'ll be very
> much involved, but we\'re not charged with taking on privacy,
> confidentiality, and security at this point.
>
> **[\>\>Rick:]{.underline}**
>
> So part of the reason I\'m asking is because I think one of the key
> issues with personal health records, at least from our perspective,
> when you think about interoperability, is ensuring proper distribution
> of credentials and access to the personal health record and
> authentication of the end user and the mechanisms for which that are
> done, and I don\'t know where that fits within any of these
> constructs; however, it is definitely a key aspect of, you know,
> distribution and providing widespread adoption and being able to
> support that.
>
> **[\>\>Kelly:]{.underline}**
>
> Right. You know, that\'s probably ‑‑ it would be a good point to sort
> of put on hold for the time being. And when we get this privacy and
> security group up and going, we can figure out how to have the
> deliberation in that workgroup and then how it will feed into what
> we'd talk about, because it is such an integral component.
>
> **[\>\>Gail:]{.underline}**
>
> Yeah, I think this brings up another point, because when we were
> talking about interoperability, I was thinking more of a personal
> health record as far as interoperability being interoperable with an
> electronic medical record so that there would always be this sharing
> of information that you ‑‑ that a consumer could populate their PHR
> with information that\'s coming from the providers' EMR. But am I
> wrong? I mean, is that \-- ?
>
> **[\>\>Kelly:]{.underline}**
>
> No, I think that\'s absolutely what we talked about in the past. I
> think another thing we've recognized, and I think the health plans are
> particularly sensitive to right now, is portability of information
> from maybe one plan to another or one PHR vendor to another. So there
> will be a lot of inputs and outputs into these PHRs, and I think we
> need to think about how we\'ll be able to have sort of a free and
> secure exchange of information no matter what the direction.
>
> **[\>\>Gail:]{.underline}**
>
> So, well, the reason I mention that is, I think it might be helpful
> then to make sure as we go forward that we have a common understanding
> of each of these recommendations and that we actually write that down
> so that it\'s not confusing, because with functionality, policy
> interoperability, all of this, there should be some definition of what
> those are, what those mean.
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah, and that's why I was hoping that, you know, in the next, you
> know, however much time we have to talk about this, we could start to
> scope out what the scope of the components are. So when we talk about
> interoperability, do we want to take on portability information from
> PHR vendor to PHR vendor? Do we want to be focused on EHR-PHR? I think
> it would be helpful if we could have that conversation to try to get
> some boundaries set. And I guess also to think about, you know,
> what\'s the most important at this point given what we understand to
> be going on in the market and what's going to be likely happening in
> the near term.
>
> **[\>\>Ross:]{.underline}**
>
> Going back to an earlier comment ‑‑ this is Ross ‑‑ an earlier comment
> about what is the role that we play versus the marketplace, to me,
> those two questions both involve interoperability between PHRs and
> other things like PHRs, like the payer portability, payer to payer,
> and also PHR to PHR so that an individual can have this information
> asset about themselves and not be bound to a particular provider of
> that service. That interoperability and the interoperability between
> PHRs and provider-based electronic records, EHRs, and the like, those
> are two clear roles that can only really happen within this kind of
> context in health care. If health care were not so fragmented and
> multiplayer, if you will, it would be easy to get everybody around a
> table and say, you know, "Let\'s make standards in the banking
> industry, for example, for ATMs." We don\'t have that. We don\'t have
> a big enough table to fit everybody. So we have to do that through
> these other mechanisms that we\'ve all come to understand.
>
> So in terms of prioritization, I do think that those are the types of
> things our group should be, you know, very heavily focused on. The
> types of functionalities, again, as long as we accommodate
> advancements and accommodate entities going beyond what the minimum
> specifications are, I\'m okay for the short term allowing the
> registration summary and medication history kind of being our minimum
> function, minimum specification for now, maybe expanding that a little
> bit in terms of how robust that stuff is in this ‑‑ in this early
> second round, but more focus on the interoperability component of it
> for all information, that whoever sends stuff around, whatever kind of
> information it is, that there\'s a ‑‑ that there\'s a framework for
> that to happen and that these additional functionalities \-- like
> let\'s say that one PHR vendor does imaging really well, and that\'s
> something they are capable of doing, and a provider or a patient wants
> to be able to share that with any number of kinds of entities, that\'s
> something that we need to be able to facilitate, even if it\'s not
> part of our minimum functional specifications for a PHR.
>
> So I\'d like to see us talking along those lines in terms of what our
> short‑term objectives are \-- our next-term objectives are, because
> we\'ve already kind of established what our short‑term objectives are.
>
> Does that make sense? Did I communicate that okay?
>
> **[\>\>Kelly:]{.underline}**
>
> Ross, I thought it made a lot of sense. I would also just add that,
> since Justine brought up the comment about how important it is to show
> value, that we be mindful as we prioritize to think about what might
> be really demonstrating value to consumers in the short term. So while
> medication and history and registration summary seem to be good two
> places to start, they might also like to see their labs, they might
> also like to request medication refills, so there might be some other
> things we could think about that would be perhaps the next set of use
> cases.
>
> **[\>\>Ross:]{.underline}**
>
> Sure, and I\'m not at all opposed to looking at where \-- what the
> next set of functional requirements we should be focusing on. And I do
> think that\'s where the market will help us a lot in telling us, "Hey,
> we\'ve done this enough now," you know. Medication refill, for
> example, is probably a good example, where we know what that takes, we
> know what it would be like for a patient to interact with a provider,
> a prescriber, in order to do that, and it\'s not, you know \-- it\'s
> not at the rocket science level at this point. It\'s just not
> universally available because there\'s not a commonly accepted
> mechanism, and it\'s more about naming one than, you know, that one is
> so magically better than another.
>
> And that\'s, I think, an example of something that when the market
> says, "Hey, we\'re ready to solidify this and experiment with it," you
> know, we don\'t need to experiment with it so much. We can push that.
> In areas where we see high value potentially but there isn\'t a lot of
> experience out there, then we can push on those a little bit. But I
> would think that for the most part, we\'ll be looking for the market
> to tell us what\'s ‑‑ what they\'re primed to do.
>
> **[\>\>Kelly:]{.underline}**
>
> Do other Workgroup members agree with what Ross said?
>
> **[\>\>Rick:]{.underline}**
>
> This is Rick Ratliff. I would agree completely. I think one of the
> challenges in the past has been that we try to over engineer or expand
> the scope too much in general \-- that\'s from an industry perspective
> \-- in health care and deliver too much. So taking a piece and
> prioritizing what\'s of the most value and kind of leaving that as
> Phase 1 and having an eye towards Phase 2 and letting the market drive
> the parts of it, I think, makes a lot of sense.
>
> **[\>\>Kelly:]{.underline}**
>
> Does anyone have a proposal to have a different kind of ‑‑ or a
> different set of critical components or any ideas on what we might add
> to what we've discussed?
>
> **[\>\>Davette:]{.underline}**
>
> If we're going to be hard-pressed, let's just flush with what we have.
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah. Okay. But do people basically agree that we could couple
> functionality, interoperability together in the short term or \--
> prioritization separate right now \-- and then would we want to make
> policy a separate bucket when we\'re not necessarily focusing on
> privacy and security in this process right now, but we could be
> looking at issues around incentives which could arguably be in the
> policy bucket? And then the last category we've talked about in the
> past has been consumer education and health literacy, and they\'re
> related but somewhat separate.
>
> **[\>\>Justine:]{.underline}**
>
> I understand if we are going to do consumer awareness, I think you
> have to do provider awareness, too, as I've mentioned. You want the
> two of them; I think that goes hand in hand.
>
> **[\>\>Kelly:]{.underline}**
>
> Right. Okay. \[Pause.\] So does the silence mean that we have
> consensus?
>
> **[\>\>Rick:]{.underline}**
>
> I\'d like to construct, as long as there's some opportunity \-- and it
> sounds like there is \-- to provide some definition that there\'s some
> breadth in them, that they capture a number of different issues, so
> they seem to be the right ones.
>
> **[\>\>Ross:]{.underline}**
>
> This is Ross again. I would offer one more concept, and it's related
> to, I think, our establishment of this cross‑cutting, you know, entity
> that does privacy and security issues for the breakthroughs. One of
> the observations from the HITSP process and the technical committees
> there is, they found that there was a whole lot of area of overlap
> between the four breakthrough areas, that is where they established
> these building blocks. And I know you use the term building block in
> your outline, Kelly, and I think they used it a little bit \-- they
> use it a little bit differently than how you've used it for PHRs,
> because it\'s much more elemental. But there are these universal \--
> everybody needs these little pieces in order for the \-- for
> everything to work, and not all of them are related to security and
> privacy issues like that cross‑cutting entity is.
>
> I\'m not suggesting necessarily that we create yet another of
> cross‑cutting workgroup or whatever, but we do have to think about how
> we raise those up as these fundamental things that need to happen,
> that yes, they are required for personal health records, but they are
> also equally required for these other elements to be successful, and
> how we\'re going to make sure that we are plugging those into a master
> plan. A lot of that came out in kind of the conversation for the AHIC
> meeting last week around clinical decisions support where they asked,
> you know, "Where did this fit in?", because it's really not been
> brought up, and there was this call for this, "Where is the real \--
> where is the road map that says where the prioritization is overtime
> and which things are essential elements?"
>
> I\'d like to see how we can fit that into our \-- you know, our broad
> charge, vision, and scope.
>
> **[\>\>Kelly:]{.underline}**
>
> But you\'re not necessarily talking about the building blocks across
> working groups. You\'re talking about how we can make sure everything
> we do within our workgroup process is interrelated and coordinated to
> the extent feasible; is that right?
>
> **[\>\>Ross:]{.underline}**
>
> I guess I\'m talking about building blocks across them \--
>
> **[\>\>Kelly:]{.underline}**
>
> You are.
>
> **[\>\>Ross:]{.underline}**
>
> \-- but it's \-- it goes beyond just, you know, ‑‑ this cross‑cutting
> group that we\'re forming is just about, you know, the privacy and
> security issues. There are other cross‑cutting, more elemental issues.
> Certainly those are some of them, but some of the basic functions for
> interoperability are not unique to any of these, and how are we going
> to \-- how are we going to communicate these amongst the groups, make
> sure that we are all concluding the same sorts of things and that the
> ultimate architecture that we recommend building this stuff on is
> consistent with all of those needs? I mean, that\'s ‑‑ it\'s a huge
> challenge, but it\'s a part of this that we really have to get in good
> alignment with the HIT Standards Panel stuff.
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah. And now I really \-- I much more understand what you\'re saying
> now. I think, in some ways, we\'re really very much related, or a lot
> of our work coincides with what chronic care is focusing on. I mean,
> not only, you know, e‑mail between clinicians and patients, which is
> what they focused on the last several months, and chronic care patient
> population, which is also of interest to us, but I think moving
> forward, they\'re going to be dealing with a lot of interoperability
> issues, perhaps between EHRs and PHRs. So I think we\'ll have to make
> sure that we have regular updates on their process and their
> considerations and that anything that\'s getting to the point of
> deliberations that are useful for the other workgroups, that we have a
> way of sharing that information so we can stay, you know, informed in
> a real-time basis. And if we end up, you know, drafting
> recommendations that might be related, we\'ll probably have to have
> the right group of people working on the charge to HITSP or to the
> charge to CCHIT to make sure that the interoperability issues that are
> common across the groups are, you know, consistently expressed so that
> people are clear on what\'s being asked of them coming out of our
> process.
>
> So I think, in large part, that\'s going to be up to our office to
> make sure that happens, because we\'ll be supporting a lot of the
> activity moving forward, but we\'ll need to make sure that the process
> is in place and the people are in place to do that.
>
> **[\>\>Ross:]{.underline}**
>
> Agreed.
>
> **[\>\>Gail:]{.underline}**
>
> Kelly, did you want us to get back to the \-- identify and agree on
> the critical components of the broad charge?
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah. I think that'd be great if can make sure everyone's comfortable
> with how we're describing them and what they are.
>
> **[\>\>Gail:]{.underline}**
>
> Does anybody have anything \-- I mean, it sounds like we're all sort
> of agreeing over here on the workplan about the functionality, the
> policy interoperability, but does anyone else want to offer anything
> else on that?
>
> \[Silence\]
>
> No? So then we\'re in agreement that those are the critical
> components?
>
> **[\>\>Ross:]{.underline}**
>
> Well, for the stuff that I just have been talking about, I see them as
> being part of the primary and secondary objectives of the group, and I
> would like to see some language around that. I don\'t know if you want
> me to suggest some, you know, A-B \-- for the A through E to add a
> couple more and see what \-- see how those fly with the group.
>
> **[\>\>Kelly:]{.underline}**
>
> You know, actually, Ross, your idea made me think: do we want to
> actually translate our objectives to what would really be describing
> what we want to get out of all these critical components? So, for
> example, you know, starting off with our previous primary objective
> \--create measurable value to consumers, patient families for improved
> health outcomes, cost, and convenience \-- do we want to then either
> modify that or add the \-- what we think is necessary to do in terms
> of defining "functionality" and "interoperability" with a particular
> focus on EHR-PHR interoperability and PHR-PHR interoperability to
> ensure that we can meet these objectives? I\'m just wondering if
> there\'s a way for us to crosswalk them or just create a set of
> objectives that would validate these critical components.
>
> I could be misunderstanding what you just suggested, though.
>
> **[\>\>Ross:]{.underline}**
>
> Are you asking me or Gail? I\'m sorry.
>
> **[\>\>Kelly:]{.underline}**
>
> Well, Ross, I was responding with what you mentioned.
>
> **[\>\>Ross:]{.underline}**
>
> If I understand what you were suggesting, I was thinking of elevating
> a couple of issues around establishing the long‑term iterative process
> as one of our objectives, and we can ‑‑ I think we can align with
> those, some of the \-- how are we going to do that in \-- later in the
> document? Maybe I misunderstood what you were just suggesting.
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah. It\'s probably not adding any clarity to the conversation, so I
> guess I was looking for a way for us to more carefully scope out what
> our critical components are, and I think so far we\'ve had a
> discussion around how that might look for interoperability, because I
> think we ‑‑ several of us have commented on the need to prioritize
> EHR-PHR interoperability and PHR-PHR interoperability with the
> recognition that the market's probably going to be driving a certain
> level of activity and determining what\'s, you know, of high value to
> consumers in particular.
>
> So I think we had some conversation around what\'s the scope or what
> are our priorities around interoperability, but I don\'t know that
> we\'ve talked as much about functionality, policy, consumer awareness,
> and health literacy. And in order for us to work up a \-- write up a
> workplan, I think it would be helpful if we had a little bit more
> conversation around what we think we need to be focusing on and what
> is our unique contribution, again, to taking on these issues.
>
> **[\>\>Rick:]{.underline}**
>
> Kelly, not to revisit interoperability, but I do have a couple
> questions.
>
> Two things that are happening in the market: One is when a patient is
> being admitted into a health system, there is a requirement called
> medication reconciliation, and there\'s a thought that the PHR
> potentially plays a role in that or integration to the health
> information system in the hospital. So to limit the scope to PHR-PHR,
> PHR-to-EHR, I don\'t know if that\'s relevant right now or not, but
> just something I wanted to bring up.
>
> There is a piece that requires interoperability potentially inside of
> the \-- into the health system. And then with medication therapy
> management services being driven into the pharmacy, at least on the
> medication side, there are some \-- there is some thinking that there
> is some PHR interoperability with potential clinical systems in the
> pharmacy. So again, I don\'t know if that\'s part of the scope of what
> we\'re talking about, but I just wanted to throw that out.
>
> **[\>\>Kelly:]{.underline}**
>
> Does anyone else have any feedback on whether or not we should
> incorporate issues around PHR health systems-information system
> interoperability, since that there\'s obviously a lot of information
> being captured from various health care providers?
>
> **[\>\>Ken Majkowski:]{.underline}**
>
> This is Ken Majkowski at RxHub. I\'m in complete agreement with
> Rick\'s comments. The medication reconciliation issue and the
> therapeutic drug management issue are probably going to be, for
> clinicians, the most important uses of medication history that can
> come from a PHR.
>
> **[\>\>Justine:]{.underline}**
>
> Actually, we have examples of plans that use \-- that offer medication
> history, that plans the hospitals are using this and accessing it and
> the numbers \-- I think of the JACHO requirement: once they required
> it, the use of that clinical health records, those records just jumped
> right through the roof, because they had to do that on admission. So
> it is one way, I mean, when you have that kind of requirement tied to
> a record, it drives up adoption.
>
> **[\>\>Kelly:]{.underline}**
>
> Right, right. So perhaps to the extent feasible and to the extent that
> our process allows, we should include that as in scope, but we\'ll
> need to also think realistically about what we\'re going to be able to
> accomplish in a 2‑month time frame in terms of fact finding and
> testimony and deliberations around sort of these three major areas of
> interoperability.
>
> And does anyone have anything to propose about functionality and how
> it should be tied to interoperability perhaps?
>
> **[\>\>Gail:]{.underline}**
>
> Kelly, this is Gail. I have to drop off ‑‑ and was there anything you
> wanted me to do before I drop off? I\'ve got about 2 minutes.
>
> **[\>\>Kelly:]{.underline}**
>
> If you have any thoughts about what you think the scope should be
> around consumer education or health literacy, it would be great,
> because I think it would be great to get that scoped out appropriately
> in the workplan.
>
> **[\>\>Gail:]{.underline}**
>
> Wait. Let me maybe put some thoughts down and send them to you; how
> about that?
>
> **[\>\>Kelly:]{.underline}**
>
> Okay.
>
> **[\>\> Gail:]{.underline}**
>
> All right. Thank you.
>
> **[\>\>Kelly:]{.underline}**
>
> Thanks.
>
> And what about \-- getting back to functionality, do we look at this
> as something that is sort of ultimately linked with interoperability,
> and do we want to be taking on the deliberations that we started
> before \-- or considerations before \-- around, you know, a minimum
> set of functional requirements? Is that something that ‑‑ what should
> the scope be for our focus on functionality? What can this group
> uniquely do, or what \-- who can we call on, perhaps? And with that in
> mind, what do we really want to accomplish?
>
> **[\>\>Davette:]{.underline}**
>
> I don't want to ask a question with a question you had just \-- this
> is Davette Murray \-- I guess when you had earlier said, "Well, what's
> our unique value for what we\'re going to produce?", if no one really
> ‑‑ since there\'s no standard out there for what is \-- should be a
> baseline PHR, you\'d think one of the goals of our group should be,
> okay, this is a starting point, but maybe not lock it in stone saying
> that for the short term or midterm. If organizations really feel like
> they\'re giving what you call the current level of practice, you
> should at least be offering to your consumers this level of PHR to be
> considered sort of like the current standard of practice, like \-- for
> instance, you don\'t really get an ROI, for instance, on doing an MRI,
> but for certain types of \-- when the patient presents a certain way,
> you\'re bound to give them an MRI, because that\'s the current level
> of standard of care. So do we want to like create something like the
> standard of information for the patient, what\'s the standard of
> information for the patient, what\'s the standard of information for
> the \-- ?
>
> **[\>\>Kelly:]{.underline}**
>
> Right. So I guess one of the questions then is, are we going to have
> the right, you know, input, expertise, time, and process to be able to
> come up with a high-level description of a minimum set of functions?
> And I guess the other consideration is then, if the answer to that is
> "Yes," then should our role also be to describe what, then, CMS and
> OPM and other Federal agencies should be doing based on that, or
> health plans? Or should we be also considering how we can integrate
> our process with what\'s already being set into motion through the
> Health IT Standards Panel and the Certification Commission?
>
> So I think it\'s one thing for us to come up with sort of a list, but
> then what is that going to do? We don\'t want \-- just want a report
> or a letter at the end of the day. We want to actually get traction;
> we want people to be acting on it. So I think we need to be realistic
> about what we can do in developing, you know, a high-level description
> around functional requirements but then also be thinking about, "Well,
> then, who can we get to do what to really make some necessary changes
> as we see fit in the market?"
>
> **[\>\>Davette:]{.underline}**
>
> So just as a point of clarity, I feel like, I guess, we\'re working on
> two levels here, because earlier, you talked about not just looking at
> specific agencies, but looking at government, industries, private
> sector, public sector \--
>
> **[\>\>Kelly:]{.underline}**
>
> Same thing.
>
> **[\>\>Davette:]{.underline}**
>
> \-- but now you\'re saying you really would like to identify specific
> organizations, recommendations for a path that we would like for them
> to do ‑‑
>
> **[\>\>Kelly:]{.underline}**
>
> No, it's the same thing as what I was saying before. It\'s just that I
> think we know we\'re supporting the Health IT Standards Panel and
> we\'re supporting the Certification Commission, and those are two sort
> of, right now, private-sector‑based processes that government is
> participating in. But it\'s ‑‑ if they are going to act on something,
> it\'s going to be not necessarily a government‑organized action.
>
> **[\>\>Davette:]{.underline}**
>
> I understand.
>
> **[\>\>Kelly:]{.underline}**
>
> And there are really just two levers for us, there\'s a standard
> terminalization process we can try to leverage and, you know, a
> certification process and as, you know, we reach, you know, consensus
> on what we think is the appropriate role is for certification we can
> think about then as a potential arm of implementing.
>
> **[\>\>Ken:]{.underline}**
>
> This is Ken Majkowski at RxHub. Shouldn\'t we maybe think about
> define ‑‑ when you talk about functionality, identifying the unique
> functionality that needs to be associated with the PHR rather than
> broad functionalities or things that, you know, are probably already
> in EHRs that are going to translate nicely, but for example, you know,
> how a patient can edit imported information, how a patient decides to
> share information with either clinicians or different systems that
> interoperability exists with. I mean, I think there are unique
> functions of a PHR that no one else discusses in all the other areas.
> We should identify those.
>
> **[\>\>Kelly:]{.underline}**
>
> Does anyone else agree?
>
> **[\>\>Ross:]{.underline}**
>
> Yes. This is Ross. I definitely agree with Ken, with Mr. Majkowski.
> It\'s ‑‑ we need to be able to figure out those particular things, and
> these are issues that go across not just the medication history and
> registration summary, but any function within a PHR.
>
> **[\>\>Ken:]{.underline}**
>
> Exactly.
>
> **[\>\>Kelly:]{.underline}**
>
> And is everyone ‑‑ does everyone feel comfortable that as a workgroup
> with, you know, the appropriate support, we could get to the point
> where we feel comfortable with sort of a baseline set of unique
> functions? Because I go back to thinking about how the EHR functional
> model was built and the HR process and it was incredibly labor
> intensive and so get to the point where you have a draft standard for
> trial use, not that would be our deliverable, but it\'s just a fair
> amount of work, and I think if we want to take this on we just need to
> clear about with at what level are we describing this and who might we
> pass it off to really get down to the very detailed determinations and
> perhaps, you know, drafting a more specific use case or doing the next
> level of work.
>
> **[\>\>Rick:]{.underline}**
>
> Well, it seems like ‑‑ this is Rick \-- just to kind of build up with
> what Ken has said, it seems like there are a number of players in the
> market that are building personal health records or personal health
> information systems. I mean, what Google does is really more about
> personal health information around the individual, and there are
> organizations like AOL through Revolution Health that are going to
> come out with these systems, and they're going to have all kinds of
> capabilities for the user to track their own health. But the real key
> is to ensure that the consumer has a tool that they can bring in real
> information that they haven\'t inputted themselves but from external
> sources whether that\'s from the pharmacies or the health plans, the
> PDM, the labs, et cetera and, that that information comes in an
> appropriate way and with the right security and authorization and then
> it could be controlled and shared appropriately.
>
> That\'s the hard part that I think we\'re going to end up with too
> many implementations or different implementations, too many different
> standards that are going to create challenges for all of us, they\'re
> looking for ways to provide ‑‑ to take that information and provide
> value whether it\'s to the individual consumer or the health care
> providers. So it seems like that\'s probably the most important thing
> that we could do and to kind of like Ross had described earlier, the
> market\'s going to drive added value around that.
>
> **[\>\>Ross:]{.underline}**
>
> Kelly, you asked if we thought that we as a group could do that, you
> know, picking and choosing a functionally unique function for the PHR,
> we can do some of it, but we probably need to build up ‑‑ build off of
> or review and acknowledge the work that others are doing, like I know
> that HL7 is going through the same process for PHR that they went
> through for the EHR and you know, that\'s a fairly, I think it\'s
> pretty early in the process, but we\'re going to go need to depend
> upon those deeper dive efforts and I know that that means, that\'s
> going to take longer than is probably helpful in some instances, but
> we can at least fine out where they are at given points in time and
> focus on those things where we see a clear role for this group.
>
> And I think we\'ve been talking all about it today this
> interoperability issue that yes, we want to be able to name what are
> minimum functions for, you know, lock down, you know, different pieces
> of the PHR over time about functionality, but the way this stuff is
> exchanged is going to be critical and there\'s things like Ken was
> talking about how does a consumer identify ‑‑ how does a consumer
> modify information within personal health record or add information
> and how does the provider understand and get information that says
> this was modified by the consumer so that they know it comes from a
> modified source or an entirely separate source and not just what the
> consumer says. There\'s actual verifiability of that information
> because it came directly from a lab or it came directly from a
> pharmacy.
>
> **[\>\>Kelly:]{.underline}**
>
> Right. I mean, in some ways it seems like if we\'re going to be trying
> to build off of what we started a couple months ago, which is trying
> to really understand the HL7 process and get input from, you know, the
> Co‑chairs of that effort and have it maybe report out in exactly where
> they are, I think they\'re initially focused on EHR-PHR
> interoperability but then wanted to move to a more broad functional
> model, but we also know there's a handful of other organizations
> already working in this area including the plans.
>
> So I guess if we have to review, acknowledge and get a much more
> detailed understanding of where everyone is, then we can then figure
> out what we could further specify or maybe get some more of a
> rationale approach to merging these efforts and to the extent feasible
> start to really identify what those unique functions are based upon
> the work that\'s already been done.
>
> I think we need to be very mindful of the process and who\'s going to
> be acting on whatever we do so we can turn it over to an organization
> that\'s going to, you know, own this over time.
>
> Does that make sense?
>
> **[\>\>:]{.underline}**
>
> Okay. How about consumer awareness and provider awareness and then
> also health literacy since we had a fair amount of conversation around
> those three areas, although I think many of the subgroup members
> aren\'t present. Although, Rob, if you\'re still on the phone, you
> might have some ideas on how we should scope this out.
>
> **[\>\> Rob T.:]{.underline}**
>
> Yeah, I think \-- I think Justine said it earlier, I mean, that you
> think about the effectiveness of a PHR, it\'s really going to be a
> tandem between the patient and the provider, and I think what we have
> to do is develop a workplan which would not only educate the provider
> on PHR, the technical side of it, but also the philosophical side, how
> can this improve the care they deliver to patients, what are they
> going to expect from patients as we walk through the door.
>
> So I think outreach materials that we could develop that could be
> given out to medical specialty societies, to government agencies that
> are working with both type community health centers, Indian health
> services and all those folks, the more consistent the message I think
> probably the better for providers.
>
> **[\>\>Myrl Weinberg:]{.underline}**
>
> This is Myrl Weinberg. Can you hear me?
>
> **[\>\>Kelly:]{.underline}**
>
> Yeah. Hi, Myrl.
>
> **[\>\>Myrl:]{.underline}**
>
> I have been on \-- I\'m with the National Health Council. I\'m
> assuming when we talk about putting together materials we don\'t
> really mean AHIC, but it means that we would encourage such things to
> be done. And the reason is, you know, there are as we\'ve been
> alluding to many groups that are working on all of these different
> aspects and I\'m sure most of you know that, you know, \[inaudible\]
> group is really moving ahead on working through health insurance plans
> and others.
>
> We here, again, I think have done quite a bit of research as well as
> others done research on what the core components, how people perceive
> them. We deal with health literacy all the time and our role is to
> reach out to health educate and create awareness among patients and
> consumers and to learn from them what works and doesn\'t and what they
> value and how they use it and then create the message to go out and
> create hopefully at the graduate level a real patient/consumer demand
> for these.
>
> So I just ‑‑ I always feel like there\'s so much going on and that
> whatever AHIC does, it truly needs to be value added and not, you
> know, not trying to do something that a number of groups are already
> well down the road.
>
> **[\>\>Rob T.:]{.underline}**
>
> If I can just add something \-- this is Rob \-- I know I\'ve used the
> term principles before, and it was kind of shot down. I really believe
> that since PHRs are in their infancy and there are so many variations
> as we\'ll no doubt find as we do the review, it might be helpful for
> AHIC to have a set of principles to guide, the developers of PHRs, but
> also hopefully to guide the public to allow them to A, understand what
> we\'re trying to do and B, to be reassured that their information is
> going to be kept private, but also there\'s going to be some value
> added to the patient. I\'m not so sure it\'s not a bad first step for
> us to develop a series of principles that the industry could agree on
> through the AHIC. I think we\'re so far away, from, for example,
> certification of PHRs that this might be a nice first development of a
> foundation
>
> **[\>\>:]{.underline}**
>
> I agree. I really think that\'s key.
>
> **[\>\>Kelly:]{.underline}**
>
> This is Kelly. I was really trying to differentiate what we\'re
> referring to as critical components as not being principles. Critical
> components are trying to organize the workgroup process, but you think
> we need principles for PHRs is what you\'re saying?
>
> **[\>\>Rob T.:]{.underline}**
>
> Well, in my mind that\'s really the only thing we can offer the
> industry at this point. If you look at what the \[inaudible\] has done
> in terms of \[inaudible\] PHR, they\'ve essentially agreed not to move
> forward with the first round and not include interoperability because
> there really are no standards out there. So for us to discuss
> interoperability between PHR and PHR and EHR and PHR is, I think, a
> little premature, but what we can do is say, here are some of the
> principles that the industry should clue in around and, No. 1, has to
> be privacy. As we\'re seeing in the last couple of weeks it is rearing
> its head again to a tremendous extent, and I think we need to reassure
> the public that the work we\'re trying to do has got that as its
> foundation.
>
> **[\>\>:]{.underline}**
>
> Rob, I think we\'ve already said that loud and clear in the
> recommendations we presented on May 16 really get there, and I also
> think that connecting for health has presented their set of principles
> with respect to privacy and security which, you know, were recognized,
> you know, we\'ve also dabbled with this early on in our workgroup
> process. I think it should be clear on what we\'re really trying to
> get out of it and what the real attraction would be that we would
> gain. You know, principles are great at a conceptual level but I think
> we\'re hopeful as we\'re really trying to make a unique contribution
> that\'s going to have an impact
>
> **[\>\>Rob T.:]{.underline}**
>
> Well, I agree with that, you know, but can\'t ‑‑ you can\'t drill down
> without principles and I\'m thinking very short term of having a set
> of guiding principles that will drive the Workgroup. For example, you
> know, what should the functionality principles be. Once we have those
> principles, then we can drill down over the next six or eight months
> or so.
>
> **[\>\>:]{.underline}**
>
> So do others agree that for functionality, for example, that our scope
> should be more limited to setting principles and not actually
> identifying requirements?
>
> **[\>\>Rob T.:]{.underline}**
>
> Well, that\'s not what I said, though. I think one has to come before
> the other. I think we need to do both but I don\'t think we can come
> up with a series of standards until we have principles.
>
> **[\>\>:]{.underline}**
>
> You\'re suggesting that the principles be discussed now and then we
> follow that on with details.
>
> **[\>\>Rob T.:]{.underline}**
>
> That\'s what ‑‑
>
> **[\>\>:]{.underline}**
>
> It would be a part of the recommendations.
>
> **[\>\>Rob T.:]{.underline}**
>
> Exactly.
>
> **[\>\>Davette:]{.underline}**
>
> This is Davette Murray. So would the principles be under the broad
> categories that we talked about earlier like policy?
>
> **[\>\>Rob T.:]{.underline}**
>
> Yeah, exactly. Education of providers and consumers.
>
> **[\>\>Davette:]{.underline}**
>
> So each of those categories would have principles is what you\'re
> proposing.
>
> **[\>\>Rob T.:]{.underline}**
>
> Exactly.
>
> **[\>\>:]{.underline}**
>
> Yeah, I think it would also be helpful to look back at the report from
> the National Committee on Vital and Health Statistics I think at a
> high level they did try to outline a lot of, you know, issues around a
> framework for PHRs and system attributes. So if we can leverage their
> activity to the extent that we\'re in agreement with what they\'ve
> said, I think it would be helpful. Again, I\'m just mindful of the
> time that we have. If we are being asked to get through a couple of
> cycles, I don\'t want to go back to perhaps a more basic conversation
> that we\'ve had, you know, a year and a half ago.
>
> But yet I\'m not ‑‑ I mean, I totally understand the value of trying
> to create some clarity at the higher level before we dive into the
> details.
>
> **[\>\>:]{.underline}**
>
> For the consumer education and health literacy issues would a set of
> principles add value in your mind or would that be duplicative based
> upon what you said so many other organizations are already doing?
>
> **[\>\>:]{.underline}**
>
> Well, I guess I think it would not be really helpful at this point
> because of what\'s already been done. I certainly don\'t think there
> needs to be more created. And at the same time what we\'re learning is
> as we, you know, believe done our research, you know, we\'re finding
> out more and more about what is important to them and we know the
> concerns are around privacy, accuracy, reliability and we know what a
> lot of the values would be and when I think of principles, I think of
> different documents I\'ve read about what the benefits should be to
> the patient or consumer, and I know those are out there in multiple
> places. There is even in one of the reports you sent, there\'s a list
> of the personal health record, there\'s a whole table there of what
> the benefits are for the different stake holders so my big concern is
> that we just not reinvent things and try to pick up where others are
> now and then figure ways to help all of us move forward.
>
> I know that\'s not really helpful, but I think I feel like if we
> continue to try to assess where things are and while some things are
> moving slowly, other things are moving pretty quickly and maybe we
> should identify the primary entities that are moving ahead in the
> different areas that we have identified and just try to in a very
> targeted way learn from them exactly where they are as part of our
> quick and dirty environmental scan.
>
> **[\>\>:]{.underline}**
>
> That makes a lot of sense. But in terms of what you think our main
> contribution could be to try to better on an organized deliberative
> efforts around consumer education in this area, would it be better
> identifying the health literacy issues and how to act on them\-- you
> think that there\'s a role for this group to consider based upon what
> others are doing\-- how we might be able to encourage better public
> private deliberation around consumer education, or is there a unique
> role for any given organization that should be recognized to create
> more of an organized process?
>
> I mean as I think we looked into the health literacy issues back in I
> guess late March and April, the literature is very weak and there\'s
> really not a whole lot known around HIT and health literary in
> combination so that strikes me as an area that might help with a
> little bit more definition and maybe prioritizing some of the
> important things we need to be mindful with, you know, people with low
> \[inaudible\] or certain ethnicities. You know, we can say that
> certainly these tools need to be sensitive to a variety of people and
> a variety of different backgrounds and what we do we really need to do
> to make it happen.
>
> **[\>\>:]{.underline}**
>
> Well, for me it\'s not really that much different from all the efforts
> that have been going on related to written documents and also, you
> know, CMS I think has had tremendous amount of experience with trying
> to deal with, you know, all of the health literacy issues with its web
> site and communications to Medicaid beneficiaries, so I just I do
> really struggle.
>
> I think that the council is not the only one, but it\'s certainly one
> organization where we have a variety of stakeholders in membership and
> we\'re hoping to based on the research that we\'ve done and the
> message really get out there and start actually doing a lot of the
> education along with other groups. So, you know, I \-- it would be
> nice if AHIC had some funding it could identify potential targets and
> really help move things along, but I know there is no funding and so
> it\'s really the question is who do you get in the room to try to
> identify as we\'ve been discussing the last couple of hours what is
> the unique added value that we can build on what others are doing and
> move things ahead and I, you know continue to give it lots of thought,
> but I don\'t have a magic answer here.
>
> **[\>\>:]{.underline}**
>
> And, Myrl, in terms of National Health Council and other organizations
> are thinking about what they might implement in terms of a consumer
> education plan would it be helpful for CMS and AHRQ and CDC and other
> HHS partners to be part of that, to have materials that are compliment
> to your campaign for the secretaries to be, you know, delivering
> messages that are also testing to be effective in really increasing in
> consumer awareness. I think there might be a role in terms of
> coordination between local grass root efforts, patient advocacy based
> efforts versus what the Federal Government could contribute.
>
> **[\>\>:]{.underline}**
>
> I do think that\'s very important. We\'re meeting with CMS fairly
> regularly and with some others in states where we hope to be involved,
> we\'re certainly reaching out to any entity, including the RHIOs that
> are already there and looking at these issues in order to do it
> together and to stay coordinated. So I think that those kinds of roles
> may be as you\'re saying it, sort of the highest level to encourage
> first knowledge of what each of the different stakeholders are doing
> in particular areas. And then to have those efforts coordinated and
> hopefully supported by the various stakeholders, that would be quite
> important.
>
> **[\>\>:]{.underline}**
>
> So as it may be a first step we could be talking about how we might be
> identifying effective messaging based upon your research and others
> that could be incorporated into all communication materials, not just
> among CDC-based groups or patient advocate organizations but across
> Federal Government agencies with a communication arm.
>
> **[\>\>:]{.underline}**
>
> Yes, that sounds like a good idea to at least look into.
>
> **[\>\>Rob T.:]{.underline}**
>
> I apologize. This is Rob. I\'ve got to step off the call.
>
> **[\>\>:]{.underline}**
>
> Okay. Thanks, Rob.
>
> **[\>\>:]{.underline}**
>
> Bye now.
>
> **[\>\>:]{.underline}**
>
> So you don\'t think that is an appropriate focus for this one
> component.
>
> **[\>\>:]{.underline}**
>
> Well, no, I\'m saying I think it\'s a good idea. I just think that we
> would need to after this conversation talk a little bit more about
> what it would be and how it would be accomplished.
>
> **[\>\>:]{.underline}**
>
> Okay, that sounds good. Can we reach out to you then after the call.
>
> **[\>\>:]{.underline}**
>
> Absolutely.
>
> **[\>\>:]{.underline}**
>
> Okay, great.
>
> Before we lose anybody else, I just want to make sure that we have
> equal opportunity to get volunteers to help flesh out this workplan
> because I think we\'ve had a lot good discussion, but I ‑‑ you know,
> this office doesn\'t want to be determining what this workplan is. We
> really want it to be coming from what the workgroup members think it
> should be. So Ross, since you had a lot of good ideas around
> interoperability, would you be willing to help flesh out some of those
> ideas?
>
> **[\>\>:]{.underline}**
>
> Sure.
>
> **[\>\>:]{.underline}**
>
> Okay, great. And does anybody else have any desire to further flesh
> out what we should do in functionality or some of the policy
> considerations?
>
> Okay, I think what we\'ll try is to reach out to a couple of you who
> have been the most active over the last couple of months and try to
> get everyone\'s thoughts together as we try to define what the scope
> of each of our critical components is, and then what does the process
> look like for us to do the fact finding, the environmental scan, sort
> of identifying the barriers and enablers, and how can we better
> coordinate cross sectors.
>
> And I think what we\'ll try to do is probably get something out to the
> Workgroup over the next two weeks for your input and, you know, you
> can feel free to edit as you like and hopefully we\'ll get to a common
> document in early July.
>
> And I\'d also encourage everybody as you give us feedback on what you
> think we should be tackling on sort of first, second and third to
> contribute your ideas in terms of who should we be getting in here to
> give testimony. Who are the innovators right now that are really
> making a difference in the market or who are the disease
> organizations, the patient advocacy organizations that are really
> making a difference with getting the word out to consumers and who is
> really going to be the ultimate standard organization that might own a
> lot of the issues around naming standards or interoperability with
> respect to what we talked about.
>
> So I think it would be helpful to sort of make, our wish list of
> testifiers so we can start lining them up and if we run out of time or
> we don\'t have, you know, the process that we would like to get
> everybody engaged, we can also get a lot of written testimony that we
> can all read in addition to our Workgroup meetings.
>
> So does anyone else have any other comments about how we might define
> the critical components and try and set boundaries for what we can
> accomplish?
>
> Well, I also just wanted to get feedback from you all whether or not
> you think that there are one or two top priorities that we really need
> to pay attention to now based upon what we know to be happening out
> there.
>
> **[\>\>Myrl:]{.underline}**
>
> This is Myrl again, and I do think it\'s critically important that we
> find ways to focus in on having people, patients, consumers and others
> understand the benefit and also we have messages that help reassure
> them about their privacy reliability types of concerns because I think
> that having people expect and desire to handle electronic personal
> health records may be the single most important thing that can happen
> to move things ahead. And, of course, we should also include providers
> and helping them resolve issues that they legitimately face with
> getting involved in and helping establish electronic personal health
> records.
>
> **[\>\>Davette:]{.underline}**
>
> This is Davette Murray. I think to add to that, though, this is going
> to come down to I know we talk about privacy and security, but I think
> what we have is \[inaudible\] issue just in the information world in
> general because the ideas that have been happening in the last two
> weeks it\'s not the actual server or the transmission of data in
> between systems, it\'s right now the level of how we design our system
> for tracking who is taking the information from those systems. Right
> now, the standard is, okay, I need to protect the data in transit. I
> need to either perhaps consider protecting the data in rest on the
> server.
>
> The next generation of evolution, though, I think for society in
> general is, okay, when it goes to someone\'s work desk, do we have an
> audit trail of a second drive in their system or they downloaded X
> report to their hard drive and they printed whatever, and right now we
> don\'t have I would say ‑‑ I shouldn\'t say everything. I would say
> the majority of applications regardless of whether they\'re medical or
> some other type of information system does not usually have that level
> of audit trail. And that needs to be knowledge that in the current
> product if we want that kind of audit trail where people\'s
> information adds on a whole lot of data development way beyond some
> products that are out there.
>
> **[\>\>:]{.underline}**
>
> Right, I think that\'s something that likely will be talked about
> among the privacy and security group. Because that\'s definitely an
> important issue for them to be able to tackle, but it\'s like we\'re
> going to be, you know, as they report back to us we can consider then
> the solutions of the options they\'re coming up with. And you know if
> that ends up being somehow worked into our considerations around
> functionality or interoperability, then we\'ll at least know sort of
> what\'s coming out of their public process.
>
> **[\>\>:]{.underline}**
>
> \[Inaudible\] honest broker with the consumer about what is totally ‑‑
> what does it mean when, say, privacy at that point \[inaudible\]?
>
> **[\>\>:]{.underline}**
>
> I think \--
>
> **[\>\>Kelly:]{.underline}**
>
> I think it\'s not going to be our charge to do that but it\'s
> definitely an important issue.
>
> Is there anyone else with any thoughts around the other categories
> around the need to prioritize what we tackle first?
>
> **[\>\>Rick:]{.underline}**
>
> Kelly, this is Rick again. I think there is a lot of momentum in the
> market right now relative to the potential to populate EHR, but the
> PHR, with medication list particularly as we look at the hurricane
> season coming on and what we did with hurricane Katrina last year. So
> the issue of the core functionally of the personal health record and
> how that\'s managed, although there are some security related issues
> as just described, we\'ll leave those off the table for now, but
> relative to potentially providing some direction or some guidance
> relative to personal health record vendors and how they interoperate
> with these data sources if you will and or with the electronic health
> records, it\'s happening in the market now and if we can provide
> guidance more from an industry level or national perspective, I think
> that will help ensure that everything is more compatible as we move
> forward. So that would be my two cents.
>
> **[\>\>Kelly:]{.underline}**
>
> Does anyone else agree with the need to prioritize interoperability?
>
> **[\>\>:]{.underline}**
>
> I guess within what scope in I\'m trying to get my mind wrapped around
> that. Earlier we had a conversation that products were not mature that
> we would be wasting our time trying to talk about that now.
>
> **[\>\>:]{.underline}**
>
> Yeah, I think that we were ‑‑ the three things that we talked about
> were focusing on EHR-PHR interoperability where there\'s been some
> work started by HL7, EHR, PHR, portability of the information going
> from one, and the third bucket was more focused on \-- was PHR to
> health care provider information systems where there might be some
> pre-population of data or the reconciliation of medication history and
> it sounds like there\'s a lot of activity out there without a lot of
> overarching guidance so that might be one thing we could consider as a
> priority.
>
> **[\>\>:]{.underline}**
>
> Prioritizing those three groups \[inaudible\].
>
> **[\>\>:]{.underline}**
>
> Yeah. Right.
>
> **[\>\>:]{.underline}**
>
> The challenge just to clarify a little bit is ‑‑ there\'s definitely a
> lot of momentum and if we could concur the authentication issue which
> we\'ll work on then it\'s going to happen, so the key is can we help,
> you know, provide some guidance into how that happens and then how
> does the individual make that information potentially available to
> their caregiver and to the points that were made earlier, you might
> have multiple physicians, some may need a printed out, some may be
> able to take information on a thumb drive and some may have
> interoperability through an HL7/CCR interface to the EHR, all of those
> things are happening very quickly in the market. And at least from my
> perspective, the more supportive we could be, it would be helpful
>
> **[\>\>:]{.underline}**
>
> But is there a unique role for this group to recognize sort of what\'s
> going to be ‑‑ is there a need for a public private, sort of public
> process to recognize what\'s happening that\'s going to be helpful? I
> guess I\'m trying to figure out if your argument, you\'re saying
> there\'s already so many happening, is what\'s already happening going
> to adequately address what we know to be barriers in inoperability
> now?
>
> **[\>\>:]{.underline}**
>
> Well, it will create barriers to interoperability if it doesn\'t
> follow certain standards and I think a lot of the industry is trying
> to follow that to the best of their ability, but still respond to
> market demand. The key that I was getting at really I think this falls
> right along with what Ken and Ross were mentioning earlier about we
> need to focus on those unique functions or features of a personal
> health record that are outside of just, you know, I\'m going to track
> my blood glucose levels, I\'m going to track my \[inaudible\] all
> these kinds of things on line. It\'s the core kinds as much as things
> that are definitely going to happen that we could use some guidance to
> ensure individuals, or capture this information and then share it
> again in an appropriate fashion with other individuals in the health
> care system.
>
> **[\>\>:]{.underline}**
>
> Thanks, that\'s really helpful. I think we\'re running out of time. So
> I\'ll just make sure that I follow up with Ms. \[Inaudible\] who
> expressed some comments on what they think should be components and
> also try to allow others who are silent on the call today to weigh in
> on prioritization. So I\'ll get back in touch shortly with everyone,
> and we\'ll also be identifying lead staff for this Workgroup moving
> forward so we will have adequate support over the next 6 plus months.
> But I also want to allow for public comment to accept if there\'s
> anyone who\'s been holding out till the very end to offer some. So
> Matt, if you could switch on or tell the operator to allow for the
> public input, that would be great.
>
> **[\>\>:]{.underline}**
>
> We just put the number up and if anybody wants to make just press star
> one on your telephone if you\'re following along right now you\'ll see
> there\'s a number up on the screen and we\'ll wait about two minutes
> to see if anyone gets through. We\'ll e‑mail where you can send your
> comments.
>
> **[\>\>:]{.underline}**
>
> While we\'re waiting for someone to come on the line, I am still
> trying to wrap my mind around the interoperability between all the
> different categories that we just laid out. I\'m wondering if the
> value added is to have a formal forum for the people that are working
> on those types of products to form a group that comes up with the
> standard for industry because right now everybody\'s out there doing
> their own thing and whatever the consumers sort of likes is what they
> get, where in like in the computer industry what happens over time is
> the vendors sort of decide, hey, we\'re shooting ourselves in the foot
> and they\'ve got themselves together and came up with standards for
> hardware and came up with standards to put on certain types of
> operating systems and then when people start building certain
> applications, everybody said, okay, this is a baseline if you\'re
> going to do office software, this is the baseline for a PC.
>
> **[\>\>:]{.underline}**
>
> I think that\'s what we\'ve always intended to help IT standards and
> how to be that organization that\'s going to be naming those standards
> and getting down to the implementation guidance if necessary. So if,
> in fact, we\'re talking also about the development of a functional
> model, then we need to think about other appropriate organizations
> that could be doing that, but I think in terms of interoperability,
> the standards for interoperability it would be starting with the
> health panel. So where we\'re really more involved is in the use case
> portion of that and having enough deliberations that we\'re pretty
> sure about ‑‑ we can describe those requirements at a high level.
>
> **[\>\>:]{.underline}**
>
> I\'m just trying to understand our little niche between all these
> other organizations.
>
> **[\>\>:]{.underline}**
>
> Okay. I think since we don\'t have anybody queued up I guess at the
> moment I also wanted to mention that we have the NHIN Forum next week.
> I think the last day for registration is 6/21 so Wednesday, and it\'ll
> be on the 28th and the 29th so for anyone who\'s interested. You can
> participate I think by phone or in person.
>
> **[\>\>:]{.underline}**
>
> Yeah, you can by phone, but there will be no video on the Web, just
> audio only.
>
> **[\>\>:]{.underline}**
>
> If you register online.
>
> **[\>\>:]{.underline}**
>
> We can provide the Web link.
>
> **[\>\>:]{.underline}**
>
> That would be great. Thank you.
>
> **[\>\>:]{.underline}**
>
> Kelly, nobody's calling in to make a comment.
>
> **[\>\>Kelly:]{.underline}**
>
> Great, thanks everyone for your contributions. I think we\'ll try to
> get a lot more clarity around the scope of what we\'re going to do
> moving forward and a more detailed workplan based upon some iterations
> with you all over the next couple of weeks. But thanks for all of your
> comments today. They were really helpful and I think we\'re about to
> embark on a period that hopefully will be, you know, that allowing us
> to take on the right role to really make a unique contribution and
> doing it in a way where we have the time and the resources to really
> take on these issues. So thanks again everybody and we\'ll meet again
> in July ‑‑ when is it? July 24. So until then have fun.
>
> **[\>\>:]{.underline}**
>
> Thank you. Bye. Thank you.