tag:blogger.com,1999:blog-28847982674084726422024-02-19T06:26:31.536-05:00Harmonious Health ITDiscussions about health information technologyUnknownnoreply@blogger.comBlogger37125tag:blogger.com,1999:blog-2884798267408472642.post-85540937175931614252012-10-30T11:45:00.000-04:002012-10-30T11:45:12.643-04:00What's Up With Me?<span style="font-family: Georgia, Times New Roman, serif;">I'm back on the blog after being M.I.A.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;">I took an "early retirement" from Siemens, after working there for 35 years. </span><span style="font-family: Georgia, 'Times New Roman', serif;">My last day was September 30th.</span><span style="font-family: Georgia, 'Times New Roman', serif;"> </span><span style="font-family: Georgia, 'Times New Roman', serif;">I've communicated that to many people privately, but had not updated my blog to reflect it.</span><span style="font-family: Georgia, 'Times New Roman', serif;"> </span><span style="font-family: Georgia, 'Times New Roman', serif;">This was not an easy decision. I will always appreciate the many wonderful people I worked with at Siemens and also in the healthcare IT industry. It was great to share in the efforts of those who are so dedicated to improving healthcare.</span><br />
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span>
<span style="font-family: Georgia, Times New Roman, serif;"><span style="background-color: white;">Many have asked me what I'll be doing. I'm taking a few months off to reflect and refresh. Then I hope to have a "plan for the plan" to tackle the "backlog" of life goals and requirements</span><span style="background-color: white;">. <i>(Apparently I haven't retired from business-speak!)</i> I am enjoying spending more time with my family (wife, children, grandchildren whose numbers are growing, siblings, parents); pursuing my musical passions (piano and singing) and hopefully giving recitals/concerts; volunteer and church work; travel while we're still in good health; and possibly "something completely different" as the Monty Pythons would say! </span></span><br />
<br />
<div style="background-color: white;">
<div>
<div class="MsoNormal">
<span style="font-family: Georgia, Times New Roman, serif;"><u></u></span></div>
</div>
<div>
<span style="font-family: Georgia, Times New Roman, serif;"><br /></span></div>
</div>
<div style="background-color: white;">
<div class="MsoNormal">
<span style="font-family: Georgia, Times New Roman, serif;">While I'll take a breather from HIT for the rest of 2012, I expect to remain involved in the HIT industry perhaps as a part-time consultant. I'm currently finalizing some work on the ONC S&I Framework Transitions of Care Initiative, specifically the Companion Guide to HL7 Consolidated CDA </span><span style="font-family: Georgia, 'Times New Roman', serif;">For
Meaningful Use Stage 2. </span></div>
<div class="MsoNormal">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: Georgia, 'Times New Roman', serif;">If I continue blogging, it will probably be on different subjects like music, so the "harmonious" will still be there, if not the "HIT." </span></div>
<div class="MsoNormal">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: Georgia, 'Times New Roman', serif;">David</span></div>
<div class="MsoNormal">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: Georgia, 'Times New Roman', serif;"><br /></span></div>
</div>
Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-2884798267408472642.post-84007278932381311442012-07-25T14:35:00.003-04:002012-07-25T14:35:56.239-04:00Patient Engagement as a Two-Way Street Part 3 – Recommendations<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Arial;">In my last post, I spoke of the importance of “getting to know” the patient and asserted that knowing a person can’t be accomplished only by predefined questions. I also referred to the HIT Policy Committee and HIT Standards Committee’s request for comment on Patient-Generated Health Data (PGHD) for Meaningful Use Stage 3 (MU3). </span><a href="http://healthit.hhs.gov/blog/faca/index.php/2012/06/18/federal-advisory-committees-seeking-input-on-incorporation-of-patient-generated-data-for-stage-3-meaningful-use/comment-page-2/#comment-7387"><span style="color: #606420; font-family: Arial;">Four Siemens employees (including me) submitted comments</span></a><span style="font-family: Arial;"> on that blog last week. Here’s my own summary of the comments, stated as recommendations.</span></div>
<ul style="margin-top: 0cm;" type="disc">
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: "Siemens Sans";">MU3 should define criteria for EHRs to accept PGHD, initially in either unstructured or structured formats. <i style="mso-bidi-font-style: normal;">(Note: “PGHD” should include data not only from patient but from their care givers such as family members)</i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: "Siemens Sans";">Encourage, but don’t mandate, structured data content standards. Define a clear roadmap for standards to come, compatible with data standards for EHRs.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: "Siemens Sans";">Clearly define provenance (data source) metadata requirements to inform providers so they can exercise their clinical judgment on how to use the data.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: "Siemens Sans";">Focus on relevance, being careful not to overwhelm people with too much data. Allow provider access to additional PGHD where needed.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: "Siemens Sans";">While in typical cases the patient is authoritative on many issues, the provider needs to exercise judgment as to trustworthiness in each SPECIFIC<i style="mso-bidi-font-style: normal;"> </i>patient interaction.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: "Siemens Sans";">Avoid being overly prescriptive on which data to gather, but rather let patients say what’s most important to them. We “don’t know what we don’t know.” <span style="mso-spacerun: yes;"> </span></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: "Siemens Sans";">Strive for wide adoption and low barriers to entry by evaluating and embracing a variety of data entry and viewing technologies most commonly used by patients</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: "Siemens Sans";">Define clear purposes, expectations and responsibilities for the review and use of PGHD</span></li>
</ul>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: "Siemens Sans";"></span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Arial;">PGHD is not new: much of today’s healthcare depends on it already. Still, in an increasingly mobile, connected, socially networked culture, there’s a lot more potential for providers to get to know patients better by collaborating with them through the two-way exchange of information. MU1 and MU2 are weighted toward a one-way flow of information from EHRs to patients, but the HIT PC and <place w:st="on"><city w:st="on">HIT</city> <state w:st="on">SC</state></place> are, commendably, seeking ways to turn this exchange into more of a “two-way street” with PGHD. </span></div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-2884798267408472642.post-29376583993441126772012-07-13T14:37:00.000-04:002012-07-13T16:57:15.646-04:00Patient Engagement as a Two-Way Street Part 2 – “Getting to Know You”<br />
<div class="MsoNormal">
One of the purposes of patient-generated health data (PGHD)
is to help providers know their patients better than they would have otherwise
if they relied only on data captured by providers. In my experience, I
appreciate doctors who do more physical exams and tests but know more about me
that could help them personalize their treatment. As Rodgers and Hammerstein
wrote in <a href="http://en.wikipedia.org/wiki/The_King_and_I">The King and I</a>,
“Getting to know you, getting to know all about you…”</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
So it is with PGHD. How can it help providers know us
better? I worked with colleagues to write a detailed response, which you can
find as a comment on the <a href="http://healthit.hhs.gov/blog/faca/index.php/2012/06/18/federal-advisory-committees-seeking-input-on-incorporation-of-patient-generated-data-for-stage-3-meaningful-use/">HIT
Policy Committee and HIT Standards Committee's blog requesting input on PGHD</a>.
I’ll give some highlights in my next installment. The rest of today’s post,
while alluding to that response, is my own opinion. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
While a patient-provider relationship is special and not
necessarily deeply personal, think about how people get to know each other in
general. They talk! In ways that can’t be predefined, prescribed, or pigeonholed.
Sure there are facts such as your birthday or address. But the vast majority of
emotion, experience, and aspirations are richly expressed through natural
language. Would you want to get to know someone by filling out structured forms
with multiple-choice questions?! So in response to the blog question “does <b style="mso-bidi-font-weight: normal;">all</b> PGHD for care management need to be
in a structured form?” I’d answer a resounding “no!” As one working in healthcare standards, I
understand and fully support the need for structured data in EHRs, for
interoperability, analytics, decision support, quality measures, etc. But even if we
could magically get all PGHD structured, standardized, tagged, and
automatically imported into EHRs, that wouldn’t necessarily make things great.
Structured data has precision, but very little nuance. Very few patients think
or communicate via structure, and no amount of standards or government
regulation will turn patients into health informaticists. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
So I suggest crawling before we walk or run when it comes to
PGHD. Let’s lower the barrier to entry by embracing PGHD in whatever formats or
devices (PCs, smart phones, basic phones with text messaging, etc.) the
patients can create it. Yes, there should be a direction for standards so that
appropriate data (such as med lists or glucose levels) can flow from
patient-facing systems like PHRs into EHRs and be understood. But let patients
express themselves in their own words and preserve this in their health record.
And speak to them in <a href="http://www.healthdatamanagement.com/issues/20_7/information-technology-health-literacy-hospitals-group-practices-44661-1.html?zkPrintable=1&nopagination=1">plain
language that they understand</a> (which won’t be structured XML). Then we’ll
have the kind of two-way street that will help my providers “get to know me” and
deliver the kind of healthcare relationship that I want for myself and my
family. </div>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-2884798267408472642.post-61544515717383975252012-07-06T15:55:00.000-04:002012-07-06T16:00:12.940-04:00Patient Engagement Needs to be a Two-Way Street<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="MsoNormal" style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none; margin: 0cm 0cm 0pt;">
<span style="font-family: Arial;">The “patient and family engagement” objectives within the federal Meaningful Use (MU) incentive program Stages 1 and (proposed) Stage 2 have been well-intended steps forward. But they have mostly regarded patients as receivers of information (education materials, clinical summaries after each visit, view/download/transmit their information, receive patient reminders). This is pretty much a “one way street.” <shapetype coordsize="21600,21600" filled="f" id="_x0000_t75" o:preferrelative="t" o:spt="75" path="m@4@5l@4@11@9@11@9@5xe" stroked="f"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path gradientshapeok="t" o:connecttype="rect" o:extrusionok="f"></path><lock aspectratio="t" v:ext="edit"></lock></shapetype></span><span style="font-family: Arial;"><span style="mso-spacerun: yes;"> </span>Sure, there is “secure messaging” where a patient can send essentially an email to a provider. But most requirements assume that providers control the keys to information that they (figuratively) “dispense” to the patient. </span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<br /></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Arial;">I recently read a fascinating book called “</span><a href="http://en.wikipedia.org/wiki/Cognitive_Surplus"><span style="color: #606420; font-family: Arial;">Cognitive Surplus: Creativity and Generosity in a Connected Age” by Clay Shirky</span></a><span style="font-family: Arial;">, whose premise is that the digital age offers “thrilling changes” as society is transformed from a passive consumer culture (e.g., watching TV/movies and reading publications, all controlled by large media companies), to a more networked culture where technology enables people to create, publish, share, connect, and collaborate in innovative ways, without dependence on established authorities. While the “free for all” can produce huge volumes of frivolous or low-quality content, it can also engender truly original and breakthrough ideas, which otherwise would not have happened, by relying on the goodwill and “cognitive surplus” (hitherto untapped creative energies) of millions of people. Examples include Wikipedia, </span><a href="http://kiva.org/"><span style="font-family: Arial;">kiva</span></a><span style="font-family: Arial;"> (microfinancing to help individuals start small businesses and alleviate poverty) and </span><a href="http://grobanitesforcharity.org/"><span style="color: #606420; font-family: Arial;">Grobanites for Charity</span></a><span style="font-family: Arial;"> fans of a singer who banded together to help charitable causes in places such as <place w:st="on">Africa</place>. Shirky’s cognitive surplus thesis has strong parallels to the </span><a href="http://www.health2con.com/"><span style="color: #606420; font-family: Arial;">Health 2.0</span></a><span style="font-family: Arial;"> movement and patient engagement. How can patients be full partners and <i style="mso-bidi-font-style: normal;">contributors</i> to their health information and their health, rather than merely passive consumers whose information is controlled by providers? Or, to use a music analogy as I like to do, is the patient just listening to solo performances by each provider, or are they playing harmoniously as an ensemble? </span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<br /></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Arial;">Patients are partial contributors already. After all, didn’t lots of the patient’s history and information about symptoms, contraindications, outcomes, and treatment that’s in paper charts or EHRs come from patients and their families, through interviews, assessments, and clipboards? Who knows better than patients what they are really doing (not what someone else thinks they ought to be doing)? So it’s good that there has been recent testimony and requests for public comment from the HIT Policy and Standards Committees about </span><a href="http://healthit.hhs.gov/blog/faca/index.php/2012/06/18/federal-advisory-committees-seeking-input-on-incorporation-of-patient-generated-data-for-stage-3-meaningful-use/"><span style="color: #606420; font-family: Arial;">patient-generated health data (PGHD)</span></a><span style="font-family: Arial;">. If you have any interest in this subject (and, as a patient, you should), you can respond too. There’s no stated deadline, though commenting sooner rather than later you’d be more likely to be heard. </span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<br /></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Arial;">Admittedly, it’s easier when discussing EHR certification and MU to discuss <i style="mso-bidi-font-style: normal;">outputs</i> from the provider’s EHR <i style="mso-bidi-font-style: normal;">to</i> patients, because those are easier to understand, quantify, and control (from a provider’s or EHR vendor’s perspective). When accepting information <i style="mso-bidi-font-style: normal;">from</i> patients, things are much more unpredictable. The request for comment asks 10 good questions, such as how “structured” PGHD should be, where are patients “the authoritative source,” and what degree of incorporating PGHD into EHRs should be expected of providers. </span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<br /></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Arial;">I have many thoughts on these questions. More to come next week…</span></div>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-2884798267408472642.post-58435227398328761732012-04-24T09:01:00.000-04:002012-04-24T09:01:13.191-04:00Patient-Centeredness: will "Direct-only" get us there?<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Arial;">I read that the </span><a href="http://geekdoctor.blogspot.com/2012/04/april-hit-standards-committee.html"><span style="color: #606420; font-family: Arial;">HIT Standards Committee</span></a><span style="font-family: Arial;"> recommended that </span><a href="http://wiki.directproject.org/Applicability+Statement+for+Secure+Health+Transport"><span style="color: #606420; font-family: Arial;">Direct (SMTP, S/MIME secure email</span></a><span style="font-family: Arial;">) be the <i style="mso-bidi-font-style: normal;">only</i> transport protocol for certification. While on the one hand this sounds like a good step toward parsimony (similar to having only one vocabulary for problems or one Consolidated CDA standard for summary of care records), I think it’s different and has some unintended consequences against the patient-centered view that can be advanced with HIEs. </span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<br /></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Arial;">Those of us who worked on Direct recognized its strength for particular “push” use cases. Many also felt strongly that Direct needed a bridge to the HIE world in terms of protocols (hence the XDR and XDM for Direct Messaging specification). The </span><a href="http://wiki.directproject.org/file/view/DirectProjectOverview.pdf"><span style="color: #606420; font-family: Arial;">Direct Project Overview</span></a><span style="font-family: Arial;"> made it very clear that Direct “push” is not intended to solve every use case but to coexist with other forms of exchange including “pull” as well explained in </span><a href="http://www.himssehra.org/docs/20110629_EHRA_TransportFramework_Final%20.pdf"><span style="color: #606420; font-family: Arial;">this EHRA whitepaper</span></a><span style="font-family: Arial;">. </span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<br /></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Arial;">This is easy to understand if we look at how businesses are run, and how people manage their personal data. Email push is highly beneficial and essential in my business and personal life. But it’s <b style="mso-bidi-font-weight: normal;">not</b> all there is. At work, when people collaborate on projects (as providers ought to<span style="mso-spacerun: yes;"> </span>collaborate in patient care), they store information in shared resources. They <b style="mso-bidi-font-weight: normal;">don’t</b> rely upon the project documents existing in every individual’s email or personal folders! That would lead to waste and confusion. Instead, there are repositories that handle version-controlled documents, source code, etc. Wiki pages rather than emails can be used to record the shared project experience. Emails are great for initial notification, but not for the ongoing management of the information. And even individuals don’t email their photos to everyone in their address book: they share them in a single place (like Facebook) from which trusted friends can pull (view and download) them. Information <i style="mso-bidi-font-style: normal;">exchange </i><span style="mso-spacerun: yes;"> </span>via Direct should not “push out of the picture” information <i style="mso-bidi-font-style: normal;">sharing</i> that benefits the patient and provider community. </span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<br /></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Arial;"><place w:st="on"><city w:st="on">HIT</city> <state w:st="on">SC</state></place>’s recommendation of a single protocol for certification is fine as a “minimum requirement.” But I’m very concerned that certifying only Direct, if accepted by ONC, could bias providers toward Direct to the detriment of other types of exchange. CMS’ Incentive Program proposes that meaningful use measures only count <span style="mso-bidi-font-family: Arial;">transmissions to providers <i style="mso-bidi-font-style: normal;">using the standards included in certification</i> (page 13708 of the NPRM). This </span>would have the unintended consequence of discouraging sharing through HIEs (at any level), that use IHE profiles such as XDS, XDR, XCA, etc., as most use these instead of Direct. Those profiles require sufficient metadata to support queries against a patient-centered document registry, so that providers can find what they’re looking for. Direct by itself does not provide or require those metadata, so even if Direct were used to push documents to an HIE, the HIE would be hard pressed to correctly index and file the documents. </span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<br /></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Arial;">I’m not criticizing Direct for what it is. I <b style="mso-bidi-font-weight: normal;">am </b>saying that it was not designed to handle all exchanges, and that overemphasizing it as the only “meaningful use” method that “counts” will have negative impacts on HIEs that provide a patient-centered aggregate view. Point-to-point transmissions don’t provide such a view since each provider’s view from “push alone” is only a “silo” unless <i style="mso-bidi-font-style: normal;">everyone</i> copies <i style="mso-bidi-font-style: normal;">everyone</i> else on <i style="mso-bidi-font-style: normal;">every</i> document (the dreaded “reply to all” email) – not a good idea! While HIEs aren’t <i style="mso-bidi-font-style: normal;">required </i>for MU, they should not be discriminated against either. CMS regulations incenting Direct <i style="mso-bidi-font-style: normal;">only </i>(implicitly disincenting HIE) could harm progress toward patient-centricity. That would be like a business rewarding people for sending their documents via email but not rewarding them for sharing controlled versions of those documents in a repository. Between ONC and CMS, I hope this problem can be avoided by focusing on the real objective – providers and patients sharing data electronically, without CMS measures counting only Direct SMTP exchanges as qualifying for meaningful use. “Pull” exchanges from an HIE or “push” exchanges using other protocols (e.g., XDR SOAP) should also count toward MU measures. And I hope that HHS goes beyond “permitting” HIEs for MU, but that they will continue to invest in and work with others (e.g., states) on a national healthcare infrastructure (NwHIN Exchange as it evolves) to enable a patient-centered, cross-provider view of data as a public good. </span></div>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-2884798267408472642.post-4323460021713932012-03-28T11:02:00.000-04:002012-07-06T15:59:14.997-04:00Meaningful Use and Consolidated CDAI invite anyone who is interested in commenting on the ONC Stage 2 Standards and Certification Rule, and/or the HL7 Consolidated CDA standard, to visit this page within the ONC S&I Framework.<br />
<br />
<a href="http://wiki.siframework.org/ToC+MU+Analysis"><strong>http://wiki.siframework.org/ToC+MU+Analysis</strong></a><br />
<br />
As you know Meaningful Use 2 has specified Consolidated CDA and the data to be exchanged with providers (upon transitions of care) and with patients (view, download, and transmit; clinical summaries after visits). But the mapping of the MU2 data to consolidated CDA has been fuzzy, so the work on that page is an attempt to clarify and help "harmonize" ONC's rule with the standard it references. I have a spreadsheet posted that explains this, and Keith Boone does too (and Keith has written extensively about this on <a href="http://motorcycleguy.blogspot.com/">his Healthcare IT Standards blog</a>). <br />
<br />
The time is short, as comments to ONC are due by early May. We are conducting this analysis via an open process facilitated by ONC S&I, in cooperation with HL7 Structured Documents workgroup. <br />
<br />
DavidUnknownnoreply@blogger.com1tag:blogger.com,1999:blog-2884798267408472642.post-31056190378656310092012-02-24T16:23:00.001-05:002012-07-06T15:58:42.718-04:00Meaningful Use Seeking Standards!<span style="font-family: Georgia;"><span style="font-family: Georgia; font-size: 11pt; mso-ansi-language: EN-US; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-US;"></span></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Georgia;"><em>Update: 10 minutes after I posted below, the ONC NPRM was issued!</em></span><br />
<em>================================================</em><br />
<br />
<span style="font-family: Georgia;">Hello! I, like many of you, are in the midst of reviewing the </span><span style="color: blue; font-family: Georgia; mso-bidi-font-family: Arial;"><a href="http://www.ofr.gov/OFRUpload/OFRData/2012-04354_PI.pdf" title="http://www.ofr.gov/OFRUpload/OFRData/2012-04354_PI.pdf
blocked::http://www.ofr.gov/OFRUpload/OFRData/2012-04354_PI.pdf
http://www.ofr.gov/OFRUpload/OFRData/2012-04354_PI.pdf">Medicare and Medicaid Programs; EHR Incentive Program - Stage 2 Proposed Rule</a></span><span style="color: blue; font-family: Georgia; font-size: 10pt; mso-bidi-font-family: Arial;"> </span><span style="font-family: Georgia;">(NPRM) on Meaningful Use Stage 2 (MU2), which was published late yesterday afternoon but was probably not seen by most people until today. The reason I titled this post as I did was because MU2 needs to be “married” to the Standards, but we’re all limited by the fact that the ONC NPRM on Standards and Certification Criteria was not published on the same day as the CMS NPRM. We’re still waiting... So for MU 2, we don’t have the actual standards in our hands yet, which we need in order to understand the criteria and assess their effects on providers, vendors, and others. Since I’ve been following the HIT Standards Committee for months, and there were sneak previews given at <a href="http://www.himss.org/ASP/topics_meaningfuluse.asp"><span style="color: #606420;">HIMSS</span></a>, I know about many standards that ONC supposedly included such as Consolidated CDA, NwHIN Direct, and SNOMED-CT. But I’d sure like to see the details ASAP. </span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<br /></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Georgia;">From CMS’ NPRM, many data elements in the “summary of care record,” “clinical summaries,” and “view and download” overlap but aren’t quite the same. As worded they don’t exactly match terms used in standards. Hopefully someone in ONC did the mapping to translate from the HIT Policy Committee’s and CMS’s phrases into the right “data buckets” in Consolidated CDA, for example. If not, I’m available to help through efforts like <a href="http://wiki.siframework.org/TOC+Implementation+Guidance+SWG"><span style="color: #606420;">ONC’s S&I Framework Transitions of Care</span></a> workgroups. </span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<br /></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Georgia;">Margalit Gur-Arie wrote a <a href="http://onhealthtech.blogspot.com/2012/02/moving-up-escalator-to-stage-2.html"><span style="color: #606420;">helpful MU2 summary</span></a> that helps distinguish what’s the same, what’s slightly new, what’s really new, etc. </span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<br /></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;">
<span style="font-family: Georgia;">As an interoperability champion, I see that ONC really means it when it talks about a big push for interoperability in MU2. MU2 has no more of those “check the box” tests without real exchange that characterized much of MU1! But stage 1 still has a few more years of life in it, for at least some providers, even if it is just a stage setter, Farzad Mostashari spoke of the “massive river flowing” of advances HIT, and I’ll be glad when real information exchanges flow abundantly among providers and patients, as I wrote about in some of my <a href="http://harmonious-healthit.blogspot.com/2010/12/opening-information-liquidity-faucet.html"><span style="color: #606420;">very first blogs</span></a>. </span></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2884798267408472642.post-21663023680973351762011-12-28T15:10:00.001-05:002011-12-28T15:14:03.557-05:00Unfinished HIT Business<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><span style="color: #660000;"><em><strong>Happy New Year!</strong></em></span> Typically it’s a time for reflection and looking ahead. But since Keith Boone already blogged about the </span><a href="http://motorcycleguy.blogspot.com/2011/12/top-10-healthit-standards-efforts-of.html"><span style="font-family: Georgia, "Times New Roman", serif;">Top 10 HIT Standards efforts of 2011</span></a><span style="font-family: Georgia, "Times New Roman", serif;"> and John Halamka predicted the </span><a href="http://geekdoctor.blogspot.com/2011/12/standards-work-ahead-in-2012.html"><span style="color: #606420; font-family: Georgia, "Times New Roman", serif;">Top 16 HIT Standards Committee Topics for 2012</span></a><span style="font-family: Georgia, "Times New Roman", serif;">, where does that leave me? I’ll try blending 2011 and 2012, since many things started in 2011 but haven’t yet come to conclusion.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><br />
</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia, "Times New Roman", serif;">In the hilarious comedy Throw Momma from the Train, Billy Crystal plays a writer who is so obsessed with his ex-wife, that he has serious writer’s block and can’t get past the first sentence of his new novel (“The night was humid…”). He eventually gets his writing groove back (“A writer writes, always”), and doesn’t leave unfinished business. Sometimes I feel like I can’t get a blog started either, so I’m going to just start writing and close out the year!</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><br />
</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia, "Times New Roman", serif;">Here are <b style="mso-bidi-font-weight: normal;">11</b> items of HIT standards unfinished business that I hope reach some closure in <b style="mso-bidi-font-weight: normal;">‘12</b>.</span></div><ol style="margin-top: 0cm;" type="1"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><b style="mso-bidi-font-weight: normal;">Meaningful Use Stage 2.</b> More than a hope, it’s a safe bet that this <i style="mso-bidi-font-style: normal;">will</i> reach closure in 2012. I predict that items #3, 5, 6, and #8 below will be partially resolved by MU2, but most won’t because they’re complex and/or outside the scope of MU2. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><b style="mso-bidi-font-weight: normal;">Sustainability of federal standards initiatives.</b> HITSP was the previous ONC’s sanctioned standards harmonization effort, but it is gone. Some wheels were reinvented. Now the ONC S&I Framework is here, but an election year and budget cuts loom. <i style="mso-bidi-font-style: normal;">What are the chances for national continuity of direction beyond 2012?</i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><b style="mso-bidi-font-weight: normal;">Sensible certification rules.</b> The HIT SC’s Implementation Workgroup made recommendations based on testimony from the difficult Stage 1 experiences. <i style="mso-bidi-font-style: normal;">What practical improvements will be made to certification?<span style="mso-spacerun: yes;"> </span></i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><b style="mso-bidi-font-weight: normal;">CDA.</b> Just when we thought there was convergence on Consolidated CDA and achievement of a critical mass of CDA-capable products (driven largely by Stage 1 certification), significant CDA changes are being discussed: Detailed Clinical Models (CIMI) and Green CDA standards. <i style="mso-bidi-font-style: normal;">What is the path forward that achieves simplification and yet doesn’t send everyone back to the drawing board? </i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><b style="mso-bidi-font-weight: normal;">Transitions of care.</b> ONC put a lot of effort into the ToC initiative, and some fine clinical recommendations were issued, but they haven’t been fully connected to the Consolidated CDA work yet. <i style="mso-bidi-font-style: normal;">How will the MU standards be adjusted so that they truly help clinicians in care coordination?</i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><b style="mso-bidi-font-weight: normal;">Vocabularies.</b> What appear to be strong recommendations for singular standard vocabularies were made, but seemingly watered down by statements that they are “for quality measures only.” <i style="mso-bidi-font-style: normal;">Will converged vocabularies be a reality for interoperability as well as quality measures?</i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><b style="mso-bidi-font-weight: normal;">Patient-sourced information.</b> Let’s face it, much data in EHRs comes straight from the patient already, yet patient-sourced information seems to be controversial. <i style="mso-bidi-font-style: normal;">What HIT standards, will enable patient information (from devices, interviews, messages, PHRs) to have their proper place? </i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><b style="mso-bidi-font-weight: normal;">Lab reporting and ordering.</b> I hope that the ONC Laboratory Reporting Initiative has achieved widespread consensus. <span style="mso-spacerun: yes;"> </span><i style="mso-bidi-font-style: normal;">Will these standards</i> <i style="mso-bidi-font-style: normal;">finally result in standardized interfaces in the real world, vs. just on paper? </i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><b style="mso-bidi-font-weight: normal;">Holistic view of exchange patterns.</b> ONC has focused heavily on the specifications that it commissioned. <i style="mso-bidi-font-style: normal;">But will ONC recognize the role of community-based HIEs using standards such as IHE XDS, and not leave a “hole in the middle” by considering only Direct and cross-community NwHIN Exchange? </i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><b style="mso-bidi-font-weight: normal;">Certificate and/or Provider Directory. </b>Much effort has been poured into supporting only the Direct Project. <i style="mso-bidi-font-style: normal;">Will the limited use case of certificate discovery given a Direct address be enough to push Direct into mainstream use? Will there be robust universal certificate directories and provider directories?</i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia, "Times New Roman", serif;"><b style="mso-bidi-font-weight: normal;">Query Health.</b> This is not likely to be in MU2, and with so many other priorities, there may not be many organizations geared up to be query responders. <i style="mso-bidi-font-style: normal;">What critical mass of industry adoption is necessary in order for population health queries to be statistically significant? </i></span></li>
</ol>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-2884798267408472642.post-40380718770467206592011-11-21T11:35:00.000-05:002011-11-21T11:35:40.019-05:00A Harmonious HIT Thanksgiving<span style="font-family: Georgia;">Since I’m traveling to visit family over Thanksgiving, I’ll take this opportunity to wish everyone a great holiday week. There’s always time to comment on what could be better! But now’s a good time to reflect on things for which I’m thankful in the HIT industry and my professional career. I won’t lengthen this post with all the <i style="mso-bidi-font-style: normal;">personal</i> reasons I have to be thankful, but they are many. </span><ol style="margin-top: 0cm;" type="1"><span style="font-family: Georgia;"><ol style="margin-top: 0cm;" type="1"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia;">I’ve worked in HIT for 34 years at one employer (SMS/Siemens Healthcare). Having a job at all is not to be taken for granted these days, and it’s much more than “a job” because I truly believe HIT, properly applied, can help people. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia;">I’ve had so many opportunities to interact with great people from healthcare providers, other vendors, the federal government, states, payers, pharmacies, labs, consumer advocates, certifying bodies, standards developers, and more, who have greatly enriched my understanding and competence. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia;">I live in a country where people are free to debate and disagree, but still work together, without fear of reprisal from the government. In fact, we have a government that wants to listen, as evidenced by ONC S&I Framework and public hearings and comment processes. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia;">My family and I have received excellent healthcare from many professionals assisted by HIT, and our lives are better (or some are still alive at all) as a result. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia;">My colleagues include many healthcare professionals, some of whom have given me high quality medical care, and who use the EHRs that we and other vendors develop, so they understand firsthand what works and what needs to be improved.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia;">There are increasing opportunities for me to be engaged, as a patient, in HIT.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia;">No one I know is satisfied with the status quo of HIT. We all want it to do more and better in terms of interoperability, usability, efficiency, and promotion of patient safety. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia;">There’s much exciting work ahead, so life in HIT is anything but rote and boring! </span></li>
</ol></span></ol><div class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;">Have a wonderful Thanksgiving, filled with harmony among those with whom you spend it.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2884798267408472642.post-91586465755708640252011-11-07T12:32:00.000-05:002011-11-07T12:32:19.890-05:00How Will Engaged Patients Get Their Comprehensive Health Information?<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia;">As I’ve blogged previously, I believe in the right of patients to access their data. Exercising a right is one thing: deriving benefit is another. The data needs to be usable for the patient or their caregiver/designee. Google Health’s demise, or the fact that patients very rarely ask for an electronic copy of discharge instructions or clinical summary (Stage 1 MU) doesn’t prove that patients don’t want their data: it’s not an “either/or” choice between having convenient functionality vs. having access to the data (<a href="http://harmonious-healthit.blogspot.com/2011/07/do-patients-need-and-want-data-or.html"><span style="color: #606420;">see my thoughts here</span></a>). I’ve made analogies (with caveats) to <a href="http://harmonious-healthit.blogspot.com/2011/02/quickening-flow-of-health-information_17.html"><span style="color: #606420;">online banking</span></a> before. But besides health data being more voluminous and complex than banking data, people usually don’t interact with nearly as many banks as healthcare providers. I as a generally healthy person have visited eight healthcare providers in the last two years, and 12 providers in the last five years. A person with more chronic illnesses would have more providers and far more visits. Will the increasing penetration of EHRs help us as patients? Specifically, <i style="mso-bidi-font-style: normal;">how will I get my comprehensive personal health information when it’s scattered in so many different places, electronic or not? </i><a href="http://harmonious-healthit.blogspot.com/2011/02/would-you-like-to-be-engaged-to.html"><span style="color: #606420;">Connecting to each one individually</span></a> doesn’t seem to be the answer. </span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><br />
</div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia;">Here are some ways that might possibly happen (<i style="mso-bidi-font-style: normal;">with italicized comments indicating my opinion of feasibility and likelihood):</i></span></div><ol style="margin-top: 0cm;" type="1"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia;">Private or public health information exchanges</span></b><span style="font-family: Georgia;"> that connect all my providers (or at least a critical mass), aggregate and perhaps normalize my data, and which have a patient portal with view/download capability for patients. <br />
<i style="mso-bidi-font-style: normal;">A few of these exist, so it may be possible for patients to get somewhat comprehensive information if they stay in the same region or provider network for a while and all those providers share data with the HIE</i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia;">All providers’ EHRs pushing their data to my PHR.</span></b><span style="font-family: Georgia;"> This could work with HealthVault, though I don’t know how many other PHRs currently support Direct protocols. The patient can receives separate standardized structured documents (e.g., CCD), but then has the option to merge and reconcile data from those documents into their PHR data fields. <br />
<i style="mso-bidi-font-style: normal;">Unlikely in the near future, though technically possible to the extent that Direct Project becomes adopted and required in Stage 2 MU.</i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia;">All providers’ EHRs making their subset of my data available to me to download, which I then upload into my PHR.</span></b><span style="font-family: Georgia;"> <br />
<i style="mso-bidi-font-style: normal;">This is theoretically possible if Stage 2 Meaningful Use continues as proposed by the HIT Policy Committee, but it’s a lot of work for the patient: adds the download + upload steps to the “merge and reconcile” step of #2.</i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia;">Patient Centered Medical Home</span></b><span style="font-family: Georgia;"> that aggregates data from multiple providers. <i style="mso-bidi-font-style: normal;">Possible in pockets with PCMHs and strong HIE capability</i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia;">All providers having all my data</span></b><span style="font-family: Georgia;"> (due to comprehensive information exchange plus EHRs consuming and storing everyone else’s data) so that no matter which one I accessed, I’d have all my personal health info. <br />
<i style="mso-bidi-font-style: normal;">Highly unlikely in the near future, since most EHRs can’t consume and store most of the data. Some EHRs can import some external data, such as medication history. </i></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia;">Virtual on-the-fly health record assembled from all sources</span></b><span style="font-family: Georgia;"> (similar to the recommendations in the PCAST report).<br />
<i style="mso-bidi-font-style: normal;">Highly unlikely in the near future.</i></span></li>
</ol><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia;">I think #1 and #2 are the most feasible today, though the percent of patients who will actually benefit from them is still low. I’d be interested in your thoughts on what is most likely to gain traction and whether there are other possibilities that are feasible today that I missed.</span></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2884798267408472642.post-40740279346059763352011-10-28T17:29:00.000-04:002011-10-28T17:29:21.787-04:00"Six Months of Strategery?"<span style="font-family: Georgia; mso-bidi-font-family: Arial;">I read a <a href="http://www.modernhealthcare.com/article/20111028/NEWS/310289987?AllowView=VW8xUmo5Q21TcWJOb1gzb0tNN3RLZ0h0MWg5SVgra3NZRzROR3l0WWRMZmFWUDhKRWxiNUtpQzMyWmFyNVhRWUpiU20="><span style="color: #606420;">story in Modern Healthcare</span></a> about a discussion with HHS CTO Todd Park at a recent conference in <place w:st="on"><city w:st="on">Nashville</city></place>. He talked about unleashing innovation. I applaud Todd for his bravery in giving out his email address publicly seeking input on innovations, and for his goal of “unlocking the mojo” of HHS staff, rather than having good ideas doomed by “six months of strategery.” I liked that!</span> <div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><br />
</div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia; mso-bidi-font-family: Arial;">There has been plenty of recent discussion, and <a href="http://www.nist.gov/healthcare/usability/"><span style="color: #606420;">guidance from NIST about improving EHR Usability</span></a> (for patient safety, efficiency, and many other reasons). There has also been similar discussion in the HIT Standards Committee <a href="http://healthit.hhs.gov/portal/server.pt?open=512&objID=1482&parentname=CommunityPage&parentid=2&mode=2&in_hi_userid=10741&cached=true"><span style="color: #606420;">implementation workgroup</span></a> about improving the usability of specifications and standards to remove barriers to adoption so the “little guy” isn’t left behind, and so that <i style="mso-bidi-font-style: normal;">everyone</i> doesn’t waste time navigating specs that point to other specs that point to other specs (called “the indirection problem”). Some recent standards efforts, such as the HL7 Consolidated CDA implementation guide, are trying to improve usability of specs in this way.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><br />
</div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia; mso-bidi-font-family: Arial;">I plan to write Todd speaking as an individual citizen (remember this blog doesn’t speak for my company though my writing is influenced by working in the Health IT industry). Usability is important for both a positive and a negative reason. Lack of usability (of specs, or software, or anything) tends to waste people’s time and “raise their blood pressure” due to frustration. Wasted a few hours per person multiplied by thousands or millions of people, and you have some serious non-productivity! Worse, it can lead to mistakes (like clinical errors jeopardizing patients) or people throwing up their hands and just not doing things that are too complicated (like refusing to use an EHR). On the positive side, when something <i style="mso-bidi-font-style: normal;">is</i> usable, like I consider my search engine, Word processing, email, and blog editing software to be, then people can get amazingly more productive, and can do great things. </span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><br />
</div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-layout-grid-align: none;"><i style="mso-bidi-font-style: normal;"><span style="font-family: Georgia; mso-bidi-font-family: Arial;">What about the usability of the specifications that hover over all of us in the EHR industry, Meaningful Use and Certification regulations?</span></i><span style="font-family: Georgia; mso-bidi-font-family: Arial;"> Or for that matter, all Federal regulations published in the Federal Register with its three columns and small print, no index and poor searchability? It’s so “1950’s” and paper-oriented. You can’t just scroll down the page like any normal document or web page, because you have to keep backing up for the next column. Try fitting a page on a screen and you can’t read the tiny font. You can’t search it to find a referenced section number, because the numbers are not a sensible scheme like 178.25.3.2.7, where you always know your context: instead section numbers aren’t even contiguous and searchable. For example, the ONC Standards and Certification Final Rule has text like “The standard specified in § 170.207(a)(2)”<span style="mso-spacerun: yes;"> </span>OK, if I want to find that paragraph in the document, it’s easily done in the Acrobat search box, right? Nope, can’t be done! It only finds is the <i style="mso-bidi-font-style: normal;">references</i> to the paragraph, but not the paragraph itself. The only way to get to § 170.207(b)(2) is by scrolling around and finally locating 170.207 near the end, then finding subparagraph (b) dangling by itself, and finally finding subsubparagraph (2), hopefully still inside of (b) unless I missed a changed letter in between. And when I finally get there, I still can’t see what the standard is, because it says “the code set specified in 45 CFR 162.1002(a)(2)” which isn’t defined in the document. I have to go out to Google. Those like me who have been doing this for a while know some tricks and short cuts and contacts to ask, but a lot of people don’t have that luxury. </span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-layout-grid-align: none;"><br />
</div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-layout-grid-align: none;"><span style="font-family: Georgia; mso-bidi-font-family: Arial;">So my suggestion to Todd is very low-tech and has nothing to do with HIT, but a lot to do with usability, productivity, and helping folks actually do what the regulations want them to do! First of all, they need to be able to understand the regs in a reasonable amount of time. I’ve spent hundreds of hours reading regulations affecting HIT. I estimate that just their formatting and numbering alone causes me to spend 50-100% more time to digest them than it should. And I probably also miss important information in the process. Multiply that by thousands of others who have the same problem. While it helps that others have created “Readers Digest versions” to simplify and explain the regulations, but why did they have to create them in the first place?</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-layout-grid-align: none;"><br />
</div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-layout-grid-align: none;"><span style="font-family: Georgia; mso-bidi-font-family: Arial;">Could this problem be solved by <i style="mso-bidi-font-style: normal;">reformatting new regulations for usability</i>, using a few smart people including human factors engineers, armed with common sense and putting themselves in the “consumer’s” shoes? Could this be done without “six months of strategery?” Hopefully yes, if Todd’s right and “mojo gets unlocked” in this area. I admit that I and probably most people and companies have similar entrenched traditions and rules that get in the way of us doing what we ought to do. I just blogged about this today because I read the interview with Todd and connected his ideas with my reading of the regulations. But the Federal Government’s regulations affect thousands of providers, vendors, and others. There’s a real opportunity for a simple low-tech innovation in the government regulation writing and formatting to help many people avoid wasting time, so they can direct more of their energies to creating innovative solutions that will really help people!</span></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2884798267408472642.post-60039510452828314702011-10-25T11:39:00.000-04:002011-10-25T11:39:49.297-04:00ONC S&I Framework Face-to-Face "Aha!" Moments<span style="font-family: Georgia;">I attended the <a href="http://wiki.siframework.org/October+F2F+Meeting"><span style="color: #606420;">ONC Standards and Interoperability Framework meeting</span></a> last week, and found it very helpful, though what I came out with was not what I expected going in. It shows that I need to keep and open and flexible mind! I’m not going to recap the entire meeting, but will focus on three “Aha!” moments that I had. While I had intended to focus on Transitions of Care (ToC), I ended up splitting my time between ToC, Query Health (QH), and Data Segmentation (DS). </span><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><br />
</div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia;">The S&I Framework is the place to be to understand where the industry (including Meaningful Use) is headed. It has some of the strengths (open participation) and challenges (difficulty integrating the workgroups) of HITSP, but has more direct buy-in from ONC, and also has the admirable goal of pilot testing standards to prove their viability before incorporating them into regulations. However, not <i style="mso-bidi-font-style: normal;">everything</i> done in S&I Framework is connected to Meaningful Use stage 2; some is more futuristic. </span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><br />
</div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia;">So here are my three “Aha!” moments.</span></div><ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia;"><a href="http://wiki.siframework.org/Transitions+of+Care+%28ToC%29+Initiative"><span style="color: #606420;">Transitions of Care</span></a></span></b><span style="font-family: Georgia;">. <strong>The dots still need to be connected across the many pieces in this initiative. </strong>While there’s convergence upon a single standard (CDA Consolidation Guide, which is close to passing its HL7 ballot), that in itself is both <i style="mso-bidi-font-style: normal;">too much</i> and yet <i style="mso-bidi-font-style: normal;">not enough</i> for ToC. <i style="mso-bidi-font-style: normal;">Too much?</i> Many parts of the guide aren’t necessary for ToC. <i style="mso-bidi-font-style: normal;">Not enough?</i> The sections that <i style="mso-bidi-font-style: normal;">are </i>necessary don’t have the core data element constraints of the <a href="http://wiki.siframework.org/ToC+CIM+Core+Data+Elements"><span style="color: #606420;">Clinical Information Model (CIM)</span></a> specified clearly enough to know what must be implemented and piloted. I was also surprised to learn that the current reference implementation work in ToC is based on HITSP C32/C83/C80, not yet based on the CIM and CDA Consolidation work because they’re waiting finalization. So they’ll have to flip over quickly to address the emerging standard in order to pilot it. Piloting tools based on C32 would only be nice to have for developers who haven’t already done it, and it wouldn’t make sense to have to pilot them prior to Stage 2 final rulemaking. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia;"><a href="http://wiki.siframework.org/Query+Health"><span style="color: #606420;">Query Health</span></a></span></b><span style="font-family: Georgia;">. I had thought a “query” was something like an SQL query or an IHE document requestry or patient identity query, and assumed it would be synchronous. As Gershwin would say, <a href="http://en.wikipedia.org/wiki/It_Ain't_Necessarily_So"><span style="color: #606420;">“<i style="mso-bidi-font-style: normal;">it ain’t necessarily so!</i></span></a>” While those are indeed queries, <strong>QH has a broader definition, and seems to be leaning strongly to asynchronous messages.</strong> For example, a query might be composed of two separate (but correlated) push transactions, like a Direct message conveying the “query” (question to be asked, such as “How many diabetic patients with elevated A1C were on X therapy?”). Then the EHR or HIE would run the query and send back the results (again possibly via a push transaction). So it could be like a secure email and a reply to that email. Or it could be like an HL7 Lab Order and a subsequent Result observation message. The QH Technical Workgroup will evaluate the various technical standards to satisfy the use cases. But beyond whatever technical standards are endorsed, I’ll be interested to see how QH defines a mix of predefined query parameters vs totally ad hoc queries, and how the systems are expected to understand what is being requested. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia;"><a href="http://wiki.siframework.org/Data+Segmentation"><span style="color: #606420;">Data Segmentation</span></a></span></b><span style="font-family: Georgia;"> (for Privacy?). I was only at about an hour of these discussions, which were moving slowly. But what struck me was the debate about <b style="mso-bidi-font-weight: normal;">whether this initiative should focus solely on privacy</b>. Clearly, data can be “segmented” for multiple purposes, but given the difficulty up till now of getting a standardized privacy solution deployed even for simpler use cases, I was surprised that broadening the scope was being advocated by some. Other efforts have struggled between “narrow vs broad” use cases. In this particular case, I think the challenge is big enough on privacy that it makes sense to have a narrow focus rather than to “boil the ocean” with other uses of data segmentation. Perhaps a clear definition of phases and scope would help: Phase 1 is solely focused on standards and pilots for privacy data segmentation; later phases can expand the scope. I view this as primarily a <i style="mso-bidi-font-style: normal;">problem (granular privacy consent) in search of a solution</i>, rather than a <i style="mso-bidi-font-style: normal;">solution (segmentation) in search of many problems</i>. </span><span style="font-family: Georgia;"></span></li>
</ul><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia;">So all in all, it was a productive meeting. Much work still remains to be done, and there’s way too much going on for most organizations to stay on top of. Still, I appreciate ONC’s leadership in convening and “uniting the tribes” as Dr. Mostashari said at the <a href="http://harmonious-healthit.blogspot.com/2011/10/onc-care-transitions-convocation-what.html"><span style="color: #606420;">Care Transitions</span></a> meeting. </span></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2884798267408472642.post-51974576600082465242011-10-19T08:15:00.001-04:002011-10-20T10:07:53.762-04:00ONC Care TransITions Convocation – What Happened?<span style="font-family: Georgia; font-size: 12pt; mso-bidi-font-weight: bold;">I blogged about the meeting that was to be held on October 14<sup>th</sup>. Now that it has occurred, with approximately 160 persons attending in person and 300 via webcast, here are first impressions. Some <a href="http://ahier.blogspot.com/2011/10/putting-it-in-healthcare-transitions.html">slides from the meeting</a> are posted, with the main conclusions on 13-17 and 24-26. </span><span style="font-family: Georgia; font-size: 12pt;"><span style="mso-spacerun: yes;"> </span></span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span> <br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><br />
</div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><b><u><span style="font-family: Georgia; font-size: 12pt;">KEY POINTS FROM THE MEETING</span></u></b><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></div><ul type="disc"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia; font-size: 12pt;">ONC's purpose in convening this meeting. </span></b><span style="font-family: Georgia; font-size: 12pt;">Farzad Mostashari (ONC) and Todd Park (HHS CTO) said ONC's role was to "unite the tribes" and "let others help” solve a major problem in today’s health care system.</span><span style="font-family: "Times New Roman"; font-size: 12pt;"> </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia; font-size: 12pt;">Transition between hospitals and post-hospital (PCP, Long-Term Care, Home) was the focus</span></b><span style="font-family: Georgia; font-size: 12pt;">. The consensus was that the current state of affairs is unacceptable. Much of the time there is <i>zero</i> transfer of information from hospital to other providers, particularly public health clinics. </span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia; font-size: 12pt;">Plan of Care. </span></b><span style="font-family: Georgia; font-size: 12pt; mso-bidi-font-weight: bold;">Based on findings from four parallel workgroups, there was much<b> </b>mindshare<b> </b>in<b> </b></span><span style="font-family: Georgia; font-size: 12pt;">support of a <i>shared Plan of Care</i> (PoC). "Shared" doesn’t mean just "exchanged" as in passed along from one provider to another. They meant a collaborative mutually-developed Plan of Care that has input from multiple providers (care team) as well as the patient and his caregivers. This comes with challenges of governance and access control, though I didn’t hear those issues discussed. </span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
<ul type="circle"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 72.0pt;"><span style="font-family: Georgia; font-size: 12pt;">Are transitions of care more like a "relay race" (hand off the baton linearly) or like a "football game" which is much more interactive all along the way? Some felt that the best we could expect was to improve the handoffs in a relay (vs. dropping the baton by not exchanging at all), whereas others wanted to move more toward a collaborative care model like a football team. Harmonious collaboration requires much clearer definition of roles and responsibilities across many organizations. </span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 72.0pt;"><span style="font-family: Georgia; font-size: 12pt;">Some said that the care plan should be approved by the patient, and co-developed, like two people redlining a contract together, rather than thrown over the wall.</span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
</ul><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia; font-size: 12pt;">CDA Consolidation Standard.</span></b><span style="font-family: Georgia; font-size: 12pt;"> Doug Fridsma and Jitin Asnaani affirmed ONC's support for the new "single standard" CDA Consolidation. This builds upon but also simplifies the standards that many have worked hard to support, and is convergence rather than divergence. I favor this direction, though the standard is still being balloted, and it will take work to migrate to it. </span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
<ul type="circle"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 72.0pt;"><span style="font-family: Georgia; font-size: 12pt;">Dr. Holly Miller of MedAllies gave a good example of the clinical need for standards and information exchange which could not only help care transitions, but change the course of the patient's health. She used the example of repeat visits to the ER involving patient falls treated in isolation, vs. the alternative where the PCP is notified, detects a pattern and underlying cause, and intervenes to prevent future falling incidents. </span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 72.0pt;"><span style="font-family: Georgia; font-size: 12pt;">Jitin said that 10 HIT/HIE vendors (not named) have committed thus far to the ONC ToC pilots. He said one or two of them would test Consolidated CDA in conjunction with Direct Project. (My editorial comment: Consolidated CDA in its entirety (over 50 sections) is unlikely to be tested in the pilots, but a constrained subset that still needs to be clearly defined should be tested). </span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 72.0pt;"><span style="font-family: Georgia; font-size: 12pt;">Jitin also announced the coordination of the S&I Framework, Beacon Communities, <a href="http://interopwg.wikispaces.com/"><span style="color: #606420;">EHR/HIE Interoperability Workgroup</span></a> (the multi-state effort led by <state w:st="on"><place w:st="on">New York</place></state>), and the State HIE Programs. The EHR/HIE workgroup is outside of ONC, but is cooperating with them. </span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 72.0pt;"><span style="font-family: Georgia; font-size: 12pt;">While the focus of much of the discussion was on needs rather than how to do it technically, there was a strong agreement on the need for tight, specific standards.</span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
</ul><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia; font-size: 12pt;">Timeliness and Relevance of Information. </span></b><span style="font-family: Georgia; font-size: 12pt;">The theme of "the right information, when I need it, where I need it" was emphasized often. Not just for providers but for patients. Dr. Scott Young of Kaiser Permanente said that typical Discharge Instructions are not given/explained at the right time and place (which should be where the patient spends most of their time, e.g., at home). Similarly, patient education is often deferred until the end of the hospitalization and are generic, whereas it can and should be started while the patient is in the hospital. Several said that PCP and other providers needed to be notified <i>at the time of admission</i> not just at discharge, because they need to be aware of the situation and given the opportunity to contribute to the care process.</span><span style="font-family: "Times New Roman"; font-size: 12pt;"> </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia; font-size: 12pt;">Taking Follow-Up Actions.</span></b><span style="font-family: Georgia; font-size: 12pt;"> Others said that Patients should not just be told to do things like make appointments: the hospital should actually <i style="mso-bidi-font-style: normal;">make</i> them (or help the patient make them) while the patient is still there. Similarly, don't just tell the patient to get prescriptions filled or buy medical equipment: send them home with them! The highest risk to a patient occurs within the 1st 72 hours after discharge, when the patient is most vulnerable physically but also is distracted by other things needing social support (childcare, finances, cleaning the house, taking care of the yard, etc.). </span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia; font-size: 12pt;">Medication Reconciliation. </span></b><span style="font-family: Georgia; font-size: 12pt; mso-bidi-font-weight: bold;">One suggested that t</span><span style="font-family: Georgia; font-size: 12pt;">he reconciliation process should start with what the patient is <i>actually </i>taking, and then build from there, rather than other people's lists that the patient is asked to verify (because they will tend to say "yes" when asked "Are you taking ____X?" even if they really aren't taking it. </span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia; font-size: 12pt;">Feedback loops</span></b><span style="font-family: Georgia; font-size: 12pt;"> were often emphasized. While not defined precisely, I gather that it means feedback to the care team and caregiver about how well the care plan is working, whether desired outcomes/goals are being achieved. </span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia; font-size: 12pt;">Disintermediation. </span></b><span style="font-family: Georgia; font-size: 12pt;">Dr. Bo-Linn, a physician who has practiced for 50 years, said that there must be "disintermediation" because the system can't afford to be so hierarchical and provider-dependent, but that patients must be able to <i style="mso-bidi-font-style: normal;">do more for themselves</i> to remove cost from the system. He pointed to examples like ATMs (no tellers), pumping and paying for gas. Making travel reservations is another example. </span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia; font-size: 12pt;">Spread of existing technology rather than new technology.</span></b><span style="font-family: Georgia; font-size: 12pt;"> While new technology was encouraged, most felt that the technology exists to do nearly everything that was discussed, and that successes exist in pockets, but are exceptional and seldom replicated. So one of the challenges is disseminating successes and scaling out the solutions that already exist. </span><span style="font-family: "Times New Roman"; font-size: 12pt;"></span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia; font-size: 12pt;">Getting the Word Out. </span></b><span style="font-family: Georgia; font-size: 12pt;">Health Affairs, one of the leading health policy journals, wants to chronicle innovation as its happening, and encourages submissions. ONC is now funding Health 2.0, an innovative group highly focused on patient engagement. It has sponsored an innovation competition, "Ensuring Safe Transitions from Hospital to Home" which ends on November 16th. </span></li>
</ul><div class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto;"><span style="font-family: Georgia; font-size: 12pt;">So it was a thought-provoking day that I’m glad I attended. While its intent was to stimulate urgency and innovation, rather than to define standards or regulations, I think it was a preview of priorities that HHS will be focusing on in the future. Speaking of Care Transitions, I’m at the <a href="http://wiki.siframework.org/October+F2F+Meeting"><span style="color: #606420;">ONC S&I Face-to-Face</span></a> right now. I plan to blog about the S&I Framework projects that I’m involved in.</span><span style="font-family: "Times New Roman"; font-size: 12pt;"> </span></div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-2884798267408472642.post-91076601972252242622011-10-12T14:30:00.001-04:002011-10-12T14:30:40.463-04:00Putting the IT in Care TransITions<div class="MsoNormal"><span style="font-family: Georgia;">On Friday, October 14<sup>th</sup>, I look forward to attending a meeting in Washington DC called <b style="mso-bidi-font-weight: normal;"><span style="color: blue;"><a href="http://www.govhealthit.com/blog/putting-it-care-transitions">Putting the ‘IT’ in Care Transitions</a></span></b>. That will be followed closely by the <b><span style="color: blue;"><a href="http://wiki.siframework.org/October+F2F+Meeting">ONC S&I Framework Face-to-Face meeting</a></span></b> in DC on October 18-19, which will also feature a track on Transitions of Care. Meanwhile, Meaningful Use Stage 2 standards definition marches on, as I wrote in my last blog. Many initiatives are converging (I hope). </span></div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><span style="font-family: Georgia;">The October 14<sup>th</sup> meeting will consider three specific patient scenarios: an elderly isolated widow with many chronic conditions; a young child with serious asthma and exacerbating home environment; a homeless man with diabetes and schizophrenia. The premise is: “if the system is designed to assist the most complex patients, then the system will function effectively for all.” I agree with the premise as far as capabilities (more complex scenarios often require more robust capabilities), but I don’t think it’s always true from an adoption and usability perspective. How often have you and I felt that a process or a gadget or a computer UI was “over-engineered” because it was designed for a complex but rare scenario, but was cumbersome for the most common scenarios? </span></div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><span style="font-family: Georgia;">The October 14<sup>th</sup> meeting also has a premise that “even the most advanced provider and community organizations acknowledge that new innovation is needed to improve the efficiency and effectiveness of delivering transitional care interventions to large numbers of patients, particularly in an environment in which technology adoption is rapidly growing and the state of technology is changing.” Right on, and so I suggest that these are some key areas for “much new innovation:”</span></div><ol start="1" type="1"><li class="MsoNormal" style="mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia;">Innovative and Usable Presentation </span></b><span style="font-family: Georgia;">of a "just right" level of information to clinicians that avoids the extremes of "information overload fatigue" vs. overly aggressive filtering of information, especially when much information exchange occurs. Can HIT be smart enough to anticipate what a clinician needs? Or must HIT be passive and "do no harm" by leaving all decisions up to the clinician?</span></li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia;">Policies and guidelines</span></b><span style="font-family: Georgia;"> for which electronic information a clinician <b>must </b>read, vs. what they do not need to read. While this is often viewed as a bigger problem for HIE/"Pull" models, it’s a concern even for "push" exchanges, especially if a sender sends information to one provider and copies many others on the "care team." </span></li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia;">Reconciliation principles for many types of data</span></b><span style="font-family: Georgia;">, not just medications. E.g., lists of problems/diagnoses, allergies, procedures, and immunizations. The risks vs. rewards of merging, aggregation, deduplication, normalizing across multiple information sources whose vocabularies are not fully standardized. Should HIT strive for “a single source of truth” or just accept that “here is what other sources have said?” </span></li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><b><span style="font-family: Georgia;">Who or what makes a care team? </span></b><span style="font-family: Georgia;">The term is used a lot, but is it clear what makes one? Just knowing who other providers are, and even having access to their records, doesn’t necessarily create a team or a care plan. My hometown football team, the Philadelphia Eagles, has so much talent that some dubbed them a “Dream Team” and surely they know each other’s names and roles, but they aren’t an effective team at the moment. And to play off the meeting title, how will putting the <b>T</b> (Technology) into <b>T</b>eam result in better patient <b>Care</b>? </span><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia;"></span></b></li>
</ol><div class="MsoNormal" style="mso-margin-bottom-alt: auto; mso-margin-top-alt: auto;"><span style="font-family: Georgia;">I look forward to blogging about the outcome of these next two meetings. </span></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2884798267408472642.post-41883273591675162792011-10-03T09:42:00.003-04:002011-10-04T15:13:34.271-04:00Forecast Cloudy but Clearing: a Crystal Ball for Meaningful Use<div class="MsoNormal">Now that the <a href="http://healthit.hhs.gov/portal/server.pt?open=512&objID=1817&parentname=CommunityPage&parentid=28&mode=2&in_hi_userid=11673&cached=true">HIT Standards Committee met on September 28<sup>th</sup></a> to wrap up their “Standards Summer Camp” and are well along in several of the ONC Standards and Interoperability Framework initiatives, how do we stand in getting a clear weather forecast for Meaningful Use Stage 2? Activity was fluid during the hot summer, but by the chill of winter, much will have “frozen” into the form of ONC’s Notice of Proposed Rulemaking (NPRM) for Stage 2 Standards and Certification Criteria. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">I was pleased to see an<a href="http://www.blogger.com/healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_12811_955623_0_0_18/6-ImpWg_HITSC_Recommendations_9-26-11.pdf"> initial draft of certification criteria produced by the Implementation Workgroup</a>. While it’s very preliminary, I understood it to be the first cut at the criteria that ONC will refine over the next few months as they write the NRPM, expected to be released for public comment perhaps in January. Here are a few highlights of what I found new or surprising. While my main focus is generally on <i style="mso-bidi-font-style: normal;">information exchange</i> criteria, there is some noteworthy new information on other objectives too. Numbers refer to the rows in the document. </div><ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;">10 Clinical Decision Support</b>. There’s more specificity around the ability to configure the CDS rules based on user role, patient setting, and points in workflow; also display of the evidence/source of each notification or care suggestion</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;">15 Lab Results</b>. Lots of work has been done in the ONC S&I Framework and HL7 on the new <a href="http://wiki.siframework.org/Lab+Results+Interface+%28LRI%29+Initiative">Lab Results Interface (LRI) implementation guide</a>, in an effort to bridge the gap between competing standards. I applaud efforts to work together to reach consensus, even if it means no one gets everything they want, so I hope that this standards effort is leveraged.</li>
<li class="MsoNormal"><b style="mso-bidi-font-weight: normal;">18 Electronic Notes</b>. They provide clarity that it must not be a scanned document, but that pretty much every other kind of electronic note is OK. While functionally that is achievable, hopefully there will be careful consideration in how to <i style="mso-bidi-font-style: normal;">measure</i> this objective to avoid burdening providers with workflow issues.</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;">23 Patient View and Download.</b> A definite shift to patient-initiation via electronic access (a secure web portal for example) to more information than was required in Stage 1, rather than have to request a copy through provider personnel. There’s still much debate about alternative ways to satisfy this (e.g., is an export to a patient-controlled PHR acceptable?), so it will be important for guidance to be clear here. </li>
<li class="MsoNormal"><b>29 Exchange Clinical Information. </b>In this objective, as well as Patient View and Download, clarity is needed on how many types of clinical documents are required (one-size-fits-all vs. multiple different documents?). For example, the ONC S&I Framework <a href="http://wiki.siframework.org/Transitions+of+Care+%28ToC%29+Initiative">Transitions of Care initiative</a> has recommended <a href="http://wiki.siframework.org/ToC+Abstract+Model">specific documents</a> -- Discharge Summary and Discharge Instructions from a hospital and Consultation Request and a Consultation Summary from an EP, but the MU objective is written as if it is just a single clinical summary. </li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;">33 Syndromic Surveillance</b>. As expected, there is a new implementation guide, though it is only applicable to hospitals. But there is still uncertainty over considering submission of Reportable Cancer Conditions by EPs. If that is to be included, what is the recommended standard? </li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><b style="mso-bidi-font-weight: normal;">52 Amendments to information.</b> This is a requirement that had not been included in previous presentations of Stage 2 MU. Will it be in the NPRM? If so, it would include replacing a data element while preserving a record of the previous value, and appending patient-supplied information as free text or scanned image/document, for patient engagement (e.g., if the patient disputes something in the record). Note, they use the word "user" but are not clear whether they mean "patient" for the requirement to "Make electronically available, upon a <i style="mso-bidi-font-style: normal;">user's</i> request, a historical account of amendment(s).”</li>
<li class="MsoNormal"><b>53 Patient Matching</b>. This is also something not mentioned in the Policy Committee's MU objectives. It is fuzzy at this point. <i>If </i>included in certification, it would impose more validation upon some demographic data. </li>
</ul><div class="MsoNormal">I encourage you to read these thoroughly and work through the channels available to you (e.g., a provider association, a trade association, an industry consortium, or comments to <a href="http://www.healthit.gov/buzz-blog/">ONC’s blog</a>) to submit suggestions for clarification. The people on policy and standards committees work very hard, but it’s impossible for them to anticipate every case where someone might have trouble interpreting. The implementation workgroup already has flagged areas that they <i style="mso-bidi-font-style: normal;">know</i> need more work. If you can give examples of how interpretations may vary, and offer constructive suggestions for how it could be worded unambiguously and made testable, I think it will help ONC to write the clearest possible regulatory language.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2884798267408472642.post-39646684722051413362011-07-06T10:33:00.001-04:002011-07-06T10:34:12.368-04:00How Would EHRs Matter to Patients?<div class="MsoNormal">In my previous post, I said I’d talk next about patient engagement functions that need EHR data vs. those that don’t. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">No doubt, there are some “data-less” functions that can still be useful – you need little or no clinical data to request an appointment, e-mail your doc, or a refill (other than your Rx number). Here’s a list, undoubtedly incomplete, of some functions that I think are Not EHR-dependent vs. those that need (or greatly benefit from) EHR data. Several of the items below are “gray areas.” </div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b>Not EHR-Dependent</b> </div><ul type="disc"><li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Personal Health Record (PHR) – untethered, if patient is willing to enter the data or settle for existing PHR data feeds (e.g., PBM med history)</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Patient self-service functions (e.g., schedule appointment, request drug refill, view clinical data, pay bill) </li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Patient-provider communication and collaboration </li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Tools for providers to improve the patient experience </li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Technologies to make healthcare more accessible for patients, e.g., telemedicine, virtual visits </li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Wellness/lifestyle aids (not just "medical", e.g., diet, exercise, recreation) </li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">“Find a doctor” </li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Search for alternatives to provide services (e.g., price comparisons for services not covered by insurance) </li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Patient satisfaction surveys </li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Bedside communication with family & friends (e.g., Skype video chat, web access) </li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Notification/invitation to events (free screenings, symposiums, etc.)</li>
</ul><div class="MsoNormal"><b>EHR-Dependent</b> (some may also be provided by Health Information Exchanges) </div><ul type="disc"><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Patient access to EHR information (e.g., download) </li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Personal Health Record (PHR) – tethered; or untethered PHR with data feeds from EHR (to greatly increase usability)</li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Patient Portal </li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Patient annotations/amendments to their health information </li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Patient provision of information to providers (e.g., home device measurements) </li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Providers pushing information to patients via patient preference </li>
<ul type="circle"><li class="MsoNormal" style="mso-list: l1 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 72.0pt;">Reminder “app” for taking meds, vaccinations, physical exam, etc. </li>
<li class="MsoNormal" style="mso-list: l1 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 72.0pt;">Other apps or notifications that help patients follow through with what was prescribed/planned </li>
</ul><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;">Tools for patients to act upon their data (trackers, analytics, access to knowledge) </li>
</ul><div class="MsoNormal">So patients can accomplish quite a bit without EHRs. But you have questions about your lab or imaging tests and their significance, or your many medications, it sure would help to have the actual data and not rely on memory. I doubt that you’d get full benefit from your med list unless you also knew about your problems/conditions and diagnostic results. I, for one, wouldn’t want to take subsets of my data and redundantly enter it into a dozen separate websites. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">If I’m a patient who wants a comprehensive and integrated view of my data, how might I get that? More on that next time…<span style="background: none repeat scroll 0% 0% yellow;"></span></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2884798267408472642.post-51520052628536807952011-07-01T12:48:00.002-04:002011-07-01T20:37:08.895-04:00Do Patients Need and Want Data, or Convenience Features?<div class="MsoNormal">So it seems that most patients were not “engaged” to, and certainly not “married on” independent PHRs such as Google. Many people including myself have learned more from failures than successes. Sometimes it helps to learn not just from my <i style="mso-bidi-font-style: normal;">own</i> failures but from the failures of others. So while the recent announcement of Google Health demise was no surprise, it offers an opportunity to learn. What do patients want? What do they need? Are needs and wants the same? </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Mr HISTalk wrote about <a href="http://histalk2.com/2011/06/28/news-62911/">what Google Health should have done</a>, and asked what actual users (not only HIT pundits) think. <a href="http://thehealthcareblog.com/blog/2011/06/29/the-phr-school-of-hard-knocks/">Missy Krasner</a>, a founder of Google Health, echoes some of the same observations about people wanting convenience functionality, not a medical archive. She also asks the same question (“to tether or not to tether”) and comments on PHRs not being “social enough” – see my posts about <a href="http://harmonious-healthit.blogspot.com/2011/02/would-you-like-to-be-engaged-to.html">Being Engaged to Multiple EHRs</a> and <a href="http://harmonious-healthit.blogspot.com/2011/06/social-healthcare-and-social-hit.html">Social Healthcare and Social HIT</a>).</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">So, answering Mr. HISTalk’s call, here’s my experience. I was/am a user of both Google Health and Microsoft HealthVault, hoping that one or both would get over the hump of <i style="mso-bidi-font-style: normal;">updating my record with providers’ data so I wouldn’t have to enter it myself.</i> Technically, both of them were partially over that hump since they could import medications from my Pharmacy Benefits Manager (Medco), and Lab Results from my main lab provider (Quest), except that I had to get a physician authorization for the labs (why this barrier?), which was an example of the authentication hassle that Missy mentioned. Microsoft was more proactive than Google in allowing HealthVault PHR updated with discrete data extracted from a clinical summary (e.g., CCD) sent by an EHR via SMTP (email) protocol, which I’ve done successfully. While Google was nominally a member of Direct Project, Microsoft was much more involved and visible. Will HealthVault actually be updated by many EHRs, and even so will it still meet Google’s fate? I won’t speculate on that, except to say that Microsoft made it farther over the hump than Google did. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b style="mso-bidi-font-weight: normal;">You Don’t Want Only Data, but You DO Need Data!</b></div><div class="MsoNormal">Nearly everyone intones that a PHR is not useful if it’s just a passive data “filing cabinet.” They say Google Health just didn’t “DO” enough to capture the minds and time of patients, although both HealthVault and Google Health had “ecosystems” of applications that would work with them. A few years ago, I thought “patient engagement” largely meant PHR (including their ecosystems) + patient portals. But I now realize that patient engagement goes way beyond PHR – I’ve got a large and growing list of what it encompasses. Still, just because functionality and convenience are what “sell,” that does <b style="mso-bidi-font-weight: normal;">not</b> mean that data is unimportant! A physician or hospital won’t want to buy an EHR just for a raw database if the EHR lacks functionality and usability. But an EHR without a solid data foundation probably won’t be very functional or usable either! </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Not all patient engagement is data-dependent. For example, I could schedule an appointment without having any of my electronic health information. In my next blog post, I’ll discuss which patient engagement functions clearly need EHR data, which ones don’t, and which ones are in a gray area. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Happy Independence Day!</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2884798267408472642.post-86396638513013656792011-06-21T10:37:00.003-04:002011-11-08T17:01:47.782-05:00"Social Healthcare" and "Social HIT"<div class="MsoNormal">I considered a title of “Socialized Healthcare” as a play on words, just to get some attention. But I’m <b style="mso-bidi-font-weight: normal;">not</b> talking about socialized medicine and government takeover of healthcare (I won’t touch politics with a 10 foot pole in this blog). Rather, I’m thinking about the implications of social networking and interactive communities. This is a big theme of the <a href="http://www.health2con.com/">Health 2.0 community</a>, of which I’ve attended an innovative and fascinating conference. “Patient engagement” – a key priority in the incentives for Meaningful Use (MU) – isn’t just about patients accessing their electronic health records, but also about interaction among a community of patients, caregivers, care providers, and others. People already “socialize” (talk about) their health quite a lot already, in some cases using IT (e.g., the Internet)! </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">A little-known fact about the <a href="http://directproject.org/">Direct Project</a> is that there was a “bake-off” among four exchange protocols: SMTP (e-mail transport***) chosen by consensus as the primary protocol, SOAP (web services as used by IHE) chosen as an option to bridge to many existing EHRs, REST (web services based on Internet HTTP protocol), and <a href="http://wiki.directproject.org/The+Case+for+XMPP">XMPP</a> (the protocol used in Facebook). While XMPP wasn’t chosen, its consideration was intriguing. The state of existing technology adoption in healthcare IT, and the fitness to purpose were factors in reaching the decision, but there was recognition that new technologies could play a significant role in the future. So as healthcare itself becomes more interactive and collaborative, new enabling technologies will become more applicable. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><i style="mso-bidi-font-style: normal;"><span style="font-size: 10pt;">***Caveat – I realize that Direct Project is not just “plain old e-mail” like most people are using, but e-mail is the easiest analogy to explain the Direct push pattern of information exchange.</span></i></div><div class="MsoNormal"><br />
</div><div class="MsoNormal">The key question isn’t about protocols, but how persons and systems interact with each other. Generally speaking:</div><ol style="margin-top: 0cm;" type="1"><li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><i style="mso-bidi-font-style: normal;">System-</i><i style="mso-bidi-font-style: normal;">system</i> interactions are called <i style="mso-bidi-font-style: normal;">interoperability</i> </li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><i style="mso-bidi-font-style: normal;">Person-</i><i style="mso-bidi-font-style: normal;">system</i> interactions are called <i style="mso-bidi-font-style: normal;">user interface </i></li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><i style="mso-bidi-font-style: normal;">Person-</i><i style="mso-bidi-font-style: normal;">person</i> interactions (facilitated by IT) are sometimes called <i style="mso-bidi-font-style: normal;">social networking</i> </li>
</ol><div class="MsoNormal">The first two have received much attention in discussions about MU. The last has not. Even though there are proposed Stage 2 or 3 Meaningful Use requirements such as uploading patient-sourced data, that’s one-way, not really interactive. Secure patient-provider messaging may be the closest MU requirement in the Person-person category. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">While e-mail-style of interaction can appear semi-interactive (i.e., long threads), it’s less interactive than chat/instant messaging or Facebook. It matches those use cases that drove it (e.g., pushing referrals, discharge summaries, results, and immunization updates among known recipients). Facebook, in contrast, has push, pull, and publish/subscribe patterns all rolled together. I haven’t seen many use cases that imply more interactivity (though a few were mentioned in the XMPP link above), so I’d be interested if anyone could point out some. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">I haven’t researched or pondered this subject enough to write in depth about it it yet, but foresee huge and possibly transformative potential there. My company’s CEO, John Glaser, said as much at the <a href="http://www.healthcareitnews.com/news/himss%E2%80%99-hit-x0-hit">HIMSS HIT X.0 mini-conference</a>. I look forward to learning more about the opportunities (use cases), technologies, and innovations in “Social Healthcare.” </div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2884798267408472642.post-60188900146245355512011-05-27T12:34:00.002-04:002011-07-01T20:34:48.026-04:00That Harmonious Spring Break HappenedWell, my <a href="http://harmonious-healthit.blogspot.com/2011/05/harmonious-musical-spring-break.html">big piano recital event</a> for which I had been practicing for a year occurred last weekend. I was happy to play, and now I'll be a little less intense for a while, before I start preparing for the <b><a href="http://www.musicappassionata.org/">MusicAppassionata</a></b> piano festival in West Chester, PA August 1-6. <br />
<br />
I've uploaded most of <b><a href="http://www.youtube.com/" target="_blank">my recital performances to YouTube</a></b>. To find them, search in YouTube for <b>David Tao piano recital</b> and they'll show up. The camcorder sound was compressed, meaning that the soft parts were made louder and the loud parts were softened, so there appears to be very little dynamic variation. Trust me, I actually can play soft, sometimes! <br />
<br />
I've related music and its performance to interoperability several times in this blog. One thing that a recital teaches you is that things go awry that you totally didn't expect, but you move on. You can't anticipate everything about some keys making unwanted noises, wheel locks not preventing the piano from rolling away, slight movements in the audience causing a brief distraction and memory lapse, etc. Despite avoidance of sugar and caffeine, and conscious intent to stay under control (knowing adrenaline would amp me up anyway), I still played faster than planned. Similarly, implementing interoperability in the real world seldom goes as you envisioned it or as cleanly as what's written in the standards or even developed in a product, because each participant doesn't have control over the other participants' systems or the environment. But every time you do it, you learn and improve the next time.<br />
<br />
Happy Memorial Day Holiday Weekend to everyone! <br />
<br />
DavidUnknownnoreply@blogger.com0tag:blogger.com,1999:blog-2884798267408472642.post-6725740209491339062011-05-13T12:55:00.002-04:002011-05-20T10:03:39.003-04:00Certification Retrospective Part 4 – Lessons Learned<i style="mso-bidi-font-style: normal;"><span style="font-family: Georgia,"Times New Roman",serif;">Note: this blog post concludes my discussion of experiences in CCHIT. The opinions are mine, and do not necessarily reflect the views of CCHIT or Siemens.</span></i><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia,"Times New Roman",serif;">In life in general, and in development of software, standards, and certification criteria, we learn and grow more by trial and error than we do when everything goes smoothly. Frederic Brooks’ classic software engineering book </span><a href="http://en.wikipedia.org/wiki/The_Mythical_Man-Month"><span style="font-family: Georgia,"Times New Roman",serif;">The Mythical Man-Month</span></a><span style="font-family: Georgia,"Times New Roman",serif;"> said “Plan to throw one away; you will anyhow.“ Hence we need prototyping and iterative refinement. The </span><a href="http://wiki.siframework.org/CDA+Harmonization+WG"><span style="font-family: Georgia,"Times New Roman",serif;">CDA Consolidation Project</span></a><span style="font-family: Georgia,"Times New Roman",serif;"> is fresh on my mind. I voted negative in its HL7 ballot, but that doesn’t mean it won’t succeed, only that it has issues to fix. It would have been a miracle to get that complex task right the first time. </span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><br />
</div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia,"Times New Roman",serif;">So it is with certification. The CCHIT Interoperability Workgroup (IOWG) experienced growing pains in its early years. 2006 produced only a roadmap, 2007 produced the first (modest) interoperability criteria. 2008 had stronger criteria and roadmap, and 2009 was poised to make big strides toward semantic interoperability. What were my main lessons learned through these years? </span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><br />
</div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia,"Times New Roman",serif;">What We Got Right (IMHO):</span></b></div><ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;"><b style="mso-bidi-font-weight: normal;">The “methodical march” sequence of building blocks. </b>Putting the horse before the cart sure helps! As described in </span><a href="http://harmonious-healthit.blogspot.com/2011/04/certification-retrospective-part-2.html"><span style="font-family: Georgia,"Times New Roman",serif;">Method to our Madness?</span></a><span style="font-family: Georgia,"Times New Roman",serif;">, we proposed a logical sequence for interoperability: </span></li>
</ul><ul style="margin-top: 0cm;" type="disc"><ol style="margin-top: 0cm;" type="1"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l2 level2 lfo2; tab-stops: list 72.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia,"Times New Roman",serif;">Data Capture</span></b></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l2 level2 lfo2; tab-stops: list 72.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia,"Times New Roman",serif;">Liquidity</span></b></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l2 level2 lfo2; tab-stops: list 72.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia,"Times New Roman",serif;">Standardized Content </span></b></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l2 level2 lfo2; tab-stops: list 72.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia,"Times New Roman",serif;">Data Consumption</span></b></li>
</ol></ul><div class="MsoNormal" style="margin: 0cm 0cm 0pt 36pt;"><span style="font-family: Georgia,"Times New Roman",serif;">Our views crystallized especially in 2008-2009. CCHIT’s criteria included many of the standards that were eventually endorsed by ONC. For example, Lab Results, CCD, e-prescribing, vocabularies (LOINC, RxNorm, SNOMED CT), and leveraging HITSP.</span> </div><ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;"><b style="mso-bidi-font-weight: normal;">The Roadmap (“Glide Path”) Concept. </b>I love maps (online, GPS, paper) and want to know ahead of time where I’m going and the milestones along the way. CCHIT<b style="mso-bidi-font-weight: normal;"> </b>published roadmaps for the next two years beyond each certification year. Roadmaps aimed to provide adequate lead time and to encourage developers to plan and head in the right direction. While the HIT Standards Committee did a great job proposing a </span><a href="http://www.himss.org/ASP/ContentRedirector.asp?type=HIMSSNewsItem&ContentId=72253"><span style="font-family: Georgia,"Times New Roman",serif;">“Glide Path”</span></a><span style="font-family: Georgia,"Times New Roman",serif;"> to more robust standards in their proposals in late 2009 (see </span><a href="http://healthit.hhs.gov/portal/server.pt?open=512&objID=1817&parentname=CommunityPage&parentid=28&mode=2&in_hi_userid=11673&cached=true"><span style="font-family: Georgia,"Times New Roman",serif;">Jamie Ferguson’s August 20th 2009 Clinical Operations Workgroup presentation)</span></a><span style="font-family: Georgia,"Times New Roman",serif;">, that concept was mostly lost when the ONC regulations were published (see comments on </span><a href="http://geekdoctor.blogspot.com/2010/02/comments-on-interim-final-rule.html"><span style="font-family: Georgia,"Times New Roman",serif;">John Halamka’s Feb. 10, 2010 blog</span></a><span style="font-family: Georgia,"Times New Roman",serif;">). For interoperability, developers need to know the target standards, more than a high-level meaningful use matrix, to move forward. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;"><b style="mso-bidi-font-weight: normal;">Staying a Course</b>. Once we defined the roadmap, we might adjust timing and provide more detailed criteria in our next development cycle, but overall there was continuity and stability with a minimum of “surprises.” </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;"><b style="mso-bidi-font-weight: normal;">Transparency.</b> CCHIT posted responses to every public comment on its website. Of course not everyone would agree, but we thought everyone deserved to know their comments were considered and our rationale for decisions. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;"><b style="mso-bidi-font-weight: normal;">Teamwork</b>.<b style="mso-bidi-font-weight: normal;"> </b>The IOWG built relationships and trust among multiple stakeholders within CCHIT, as mentioned in </span><a href="http://harmonious-healthit.blogspot.com/2011/04/certification-retrospective-part-1.html"><span style="font-family: Georgia,"Times New Roman",serif;">Part 1</span></a><span style="font-family: Georgia,"Times New Roman",serif;">. That enabled us to work through differences and get things done, despite conflicting opinions. In contrast, it’s harder to capture the “team” element in groups where 50-100 people are nominally on a project but attendance is sporadic, yet I understand the need for openness and transparency. Ultimately, a small group forms a cohesive team within the larger group. For example, the </span><a href="http://wiki.directproject.org/Documentation+and+Testing+Workgroup"><span style="font-family: Georgia,"Times New Roman",serif;">Documentation and Testing workgroup</span></a><span style="font-family: Georgia,"Times New Roman",serif;"> within the Direct Project gradually developed a “team” spirit similar to what the IOWG had. </span></li>
</ul><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: Georgia,"Times New Roman",serif;">Regrets:</span></b></div><ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;"><b style="mso-bidi-font-weight: normal;">Lack of <place w:st="on">Opportunity</place> to Finish What We Started. </b>Last week I used football, now here’s my first baseball analogy. CCHIT, as the “starting pitcher” for EHR certification was relieved by ONC in the 6<sup>th</sup> inning – enough to get a quality start, but not enough to win the game. Our methodical march didn’t reach its goal, but I hope that ONC will be a good “closer” to save the win for interoperable EHRs, coordination of care, and the good of the patient. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;"><b style="mso-bidi-font-weight: normal;">Lack of End-to-End Coverage</b>. Interoperability involves senders, receivers/requesters, and perhaps intermediaries. To succeed, it must encompass all participants (e.g., EHRs, HIEs, PHRs, labs, pharmacies, public agencies), because so much exchange goes beyond EHRs. We didn’t achieve this in CCHIT, but not for lack of trying! We envisioned covering some end-to-end interoperability through certification programs for HIEs and PHRs in addition to EHRs. Excellent people were in the HIE and PHR workgroups, and the IOWG had good dialogues with both. The HIE program was launched with poor uptake followed by suspension in light of impending ONC program changes. The PHR program was not launched.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;"><b style="mso-bidi-font-weight: normal;">All-or-Nothing Approach</b>. CCHIT pondered a modular certification approach early on, especially for inpatient EHRs, but didn’t implement it until ONC mandated it in the Certification Final Rule. In hindsight, I wish we had done that sooner. I don’t think we needed an “all or nothing” approach. Truth in labeling would have disclosed each product’s gaps, to help people make informed decisions. Vendors with complete EHR functionality could still differentiate themselves as a “one-stop shop” but others (“little guys”) would not be excluded from certification just because they didn’t provide 100% of all capabilities. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;"><b style="mso-bidi-font-weight: normal;">A year in limbo.</b> From mid-2009 through mid-2010, the industry was paralyzed by uncertainty and lost momentum on interoperability. It was clear that CCHIT criteria wouldn’t be adopted as is by ONC, but no one knew what would replace them. There was no assurance of staying a course or a clear glide path, and people who had done their best to follow the CCHIT roadmap were concerned and confused. Interoperability features (such as standardized coding and discrete data consumption) that the IOWG expected to be in products in 2010 have been delayed, possibly to MU Stages 2 or 3. </span></li>
</ul><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia,"Times New Roman",serif;"><br />
<b style="mso-bidi-font-weight: normal;">Whether right or regret, there are lessons learned that can be applied going forward.</b></span></div><ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level1 lfo3; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;">Follow the <b style="mso-bidi-font-weight: normal;">methodical march</b> – a logical sequence of capture, liquidity, standardization, and consumption.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level1 lfo3; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;">Define a <b style="mso-bidi-font-weight: normal;">roadmap</b> (glide path) with ample lead time.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level1 lfo3; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;"><b style="mso-bidi-font-weight: normal;">Stay the course</b>.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level1 lfo3; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;">Take an <b style="mso-bidi-font-weight: normal;">end-to-end</b> perspective.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level1 lfo3; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;">Be <b style="mso-bidi-font-weight: normal;">transparent</b>.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level1 lfo3; tab-stops: list 36.0pt;"><span style="font-family: Georgia,"Times New Roman",serif;">Be <b style="mso-bidi-font-weight: normal;">flexible</b>, not “all or nothing.”</span></li>
</ul><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Georgia,"Times New Roman",serif;">That’s it! This has been a long blog series, and if you made it to the end, thanks!</span></div>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-2884798267408472642.post-86343177027665498132011-05-05T16:02:00.002-04:002011-05-06T13:12:14.059-04:00Certification Retrospective Part 3 – Controversies Along the Way<div class="MsoNormal"><i>Note: this blog post continues my discussion of experiences in CCHIT. The opinions are mine only and do not necessarily reflect the views of CCHIT or Siemens. Please bear this in mind especially considering that the topic is “Controversies”</i></div><div class="MsoNormal"><br />
</div><div class="MsoNormal">From my <a href="http://harmonious-healthit.blogspot.com/2011/04/certification-retrospective-part-2.html">last Certification Retrospective post</a>, I promised to share lessons learned and some “agonizing controversies” we faced in the CCHIT Interoperability workgroup (IOWG). I thought I could do both in one post, but now realize that I’ll need a “Fourth Movement” after this. Each controversy could easily take up a post of its own, but I’ll try to squeeze them into this post, deferring Lessons Learned to Part 4.</div><ol start="1" style="margin-top: 0cm;" type="1"><li class="MsoNormal"><b>When should <a href="http://hitsp.org/">HITSP specs</a> be incorporated into certification? </b>Once HITSP was formed, it (not CCHIT) was designated to select standards. CCHIT, however, could decide when/if those standards would be certified, striking a difficult balance between supporting the federal strategy (HITSP was HHS-funded, CCHIT was partially HHS-funded) and yet being pragmatic. It would have been difficult to require EHRs to develop too much at once when certification was “all or nothing” and not modular. From working in both CCHIT and HITSP, CCHIT tended to give more weight to considerations such as market adoption and lead times, not just whether a suitable standard existed. I along with Jamie Ferguson were appointed to co -chair the 10-member HITSP-CCHIT joint working group, whose goal was to coordinate the work of HITSP and CCHIT and address how/when to include HITSP specs in certification. But some HITSP-selected standards were still in “trial implementation” with little adoption, and the approval of a standard (HL7, HITSP, or any other) didn’t mean it should be mandatory within a specific timeframe. And there were just so many of them to digest, let alone certify! Some people weren’t pleased, thinking that CCHIT should be a more aggressive “enforcement arm” of HITSP. In the end, we included more of HITSP in 2008 and 2009 certification criteria than ONC did in its 2011 certification criteria, most notably the HL7 2.5.1 Laboratory results with LOINC vocabulary starting in 2007, C32 CCD starting in 2008 (adding RxNorm, UNII, SNOMED CT vocabularies in 2009) and HITSP TP13 (IHE XDS.b – see point #2 below). But we also roadmapped (2-3 years out) most other HITSP specs when we published our 2009 criteria. I believe this was a sensible middle of the road approach. IMHO, if we had mandated many more HITSP specs in certification, there would be few or zero certified products today!</li>
<li class="MsoNormal"><b>Should certification require transport standards?</b> Fourth & Ten – we’d better punt! Seriously, we debated this during 2008 and 2009. We recognized this as a glaring gap in interoperability, and wanted to make headway, realizing that lack of secure transport standards would hinder interoperability even if content were standardized. The Direct Project didn’t exist back then. We were aware of diverse ways that HL7 messages were transported, that IHE had defined SOAP-based web services for document transport, and that HITSP had selected many IHE specifications. Many vendors had already tested IHE Cross-Enterprise Document Sharing (XDS.b) at Connectathon. So the IOWG approved XDS.b as 2009 certification criteria (along with PIX/PDQ to support it). But the Board of Commissioners decided to designate these as <i>optional</i> interoperability criteria, not required for certification, because despite the IOWG’s recommendation and strong EHRA support, some commented against it. This was the one case I can recall where my workgroup’s recommendation was overridden by the Board, which I know was a tough decision since the Board usually didn’t do that. This was also a case where we were <i>less</i> aggressive in CCHIT than the EHR Association had proposed. EHRA had sometimes criticized CCHIT for not providing enough lead time, but in this case they were very disappointed that CCHIT had not required this in certification. This one still bothers me as a missed opportunity. </li>
<li class="MsoNormal"><b>Should we require discrete data import, and who owns that decision anyway?</b> We felt that the main point of requiring standardized content formats and vocabularies, not just human readability/liquidity, was for the discrete data to be consumable. Following our <a href="http://harmonious-healthit.blogspot.com/2011/04/certification-retrospective-part-2.html">“methodical march” mentioned in part 2</a>, we thought in 2008 that the time had come to propose discrete data import (e.g., update your medication, allergy, or problem lists using data from other providers). But now we were into a “boundary condition.” Where did interoperability’s “turf” end and functionality begin? We had a series of “discrete data import” meetings between the IOWG and the Ambulatory and Inpatient Functionality workgroups. We recognized that data must not only be exchanged, it needs to be reconciled (medication reconciliation being an example), and that you can’t just “slam in” all meds, allergies, problems from <a href="http://harmonious-healthit.blogspot.com/2010/12/andante-what-happens-when-trickle_22.html">many external sources</a> to automatically update the active med/allergy/problem list. The functionality workgroups didn’t think the time was right to require such capability in certification for 2009 or 2010. But how were we going to keep making progress toward semantic interoperability? In the end, we proposed criteria to import very specific discrete data elements for medications, allergies, demographics, and immunizations (with problems to come later), as described in my last post. But we didn’t define the functionality, as long as the discrete data were stored somewhere. And in any case, reconciliation criteria would belong to the functionality workgroups, not the IOWG. I think this would have been a reasonable “baby step” but because of the change in certification that started in 2009, those roadmap criteria never had the chance to be certified. I hope that similar careful thought will go into decisions in ONC certification, whenever it gets to that point. End-to-end interoperability involves content creation, secure standardized transport, and content consumption, all of which should be considered holistically. </li>
<li class="MsoNormal"><b>Should we push the industry toward a single standard for clinical problems?</b> This was really part of the broader topic of converging on a singular standard vocabulary for each type of data, but SNOMED CT for problems was the lightning rod topic for several reasons: a) the difficulties of getting physicians to create medical problem lists at all; b) ICD-9 diagnosis codes were already required for reimbursement and some physicians systems were built around ICD-9; c) ICD-10 was already complicating things by looming on the horizon; d) anything that imposed more work on physicians could hinder usability and adoption. So though SNOMED CT seemed a clear winner for an interoperable clinical vocabulary and was HITSP-endorsed, we received considerable pushback from some members of the other workgroups as to how fast SNOMED CT could be required. I was pleased that many in the IOWG stepped up to provide statistics and research facts such as analysis of mapping of ICD-9 to SNOMED CT and clarification that standard codes don’t have to be visible in the clinician’s UI. We knew this was a contentious issue, but staked out our positions in the 2009 roadmap and a Q&A document. </li>
</ol><div class="MsoNormal"><b></b></div><div class="MsoNormal">The above four were prototypical of the controversies we faced in content, vocabulary, and transport. I could go on with more examples. That’s part of the challenge of interoperability work, as evidenced by the fact that ONC and the HIT Standards Committee still have <i>all</i> of the above issues to ponder for Stages 2 and beyond. I should mention that one more big controversy arose in the very first year, when CCHIT was newly formed and struggling to figure out how to set the interoperability bar. Eyes were upon <a href="https://docs.google.com/leaf?id=0B9s2w8-b67zsZDJkYzMzMGItM2IyNC00NDFhLWE0NGMtMTVjMjJkOGJiMDJh&hl=en">those first members</a> to resolve the CDA vs. CCR debate. Unlike the four issues above, where we took a stand, we weren’t ready to force a decision in 2006, and then HITSP was formed by ONC to deal with such “standards harmonization” issues. So at least our punt had a receiver (and football wasn’t locked out)! </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">I promise that Part 4 will really conclude this series with my thoughts on Lessons Learned, proudest accomplishments, regrets, and hopes for the future, stemming from my CCHIT experience. Thanks for listening to my sharing from “inside the trenches” of discussions of which the public was not aware. </div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2884798267408472642.post-24705704329069992292011-05-02T10:40:00.001-04:002011-05-02T10:40:46.307-04:00A Harmonious Musical Spring Break<div class="MsoNormal">I expect to conclude my three-part certification retrospective within the week. Since it will end with a discussion of lessons learned as well as some tough controversies, it will need some thoughtful review before I just fire it off. In the meantime, I’m going to take a brief break to return to my non-HIT passion, music, which has many parallels with Health IT as I introduced in <a href="http://harmonious-healthit.blogspot.com/2010/12/harmonious-what.html">my first blog post in December</a>. One of my physician colleagues recently shared with me an article from the March 15<sup>th</sup> edition of the Annals of Internal Medicine, entitled <i><a href="http://www.annals.org/content/154/6/426.abstract">What Musicians Can Teach Doctors</a></i>. No, I’m not going to use this post to teach doctors, but I recommend the article, as it compares musical training and performance to medical training and practice. Furthermore the aspects of teamwork, rehearsal, and specialization are key to HIT interoperability. Both music and interoperability must be performed by collaborating participants, not just specified in theory, and there’s no substitute for doing it over and over, refining it, and continuously improving.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">I’ve been applying the principle of “practice” (musical, not medical) for the past year preparing for an upcoming solo piano recital. For too long, I didn’t make time for it, as the demands of family, work, and “life” kept getting in the way, but now on May 20<sup>th</sup> and 21<sup>st</sup> I’ll perform two concerts. Information is available on the web about the <a href="https://docs.google.com/document/d/1YPV-6y380tNhOpt4Gy0JmAPFil388nueJdLOrWgSofo/edit?hl=en&authkey=CN6RxrMD">recital program</a>, <a href="http://www.youtube.com/watch?v=F9HOiTbcYQc">Youtube video preview “trailer”</a> and <a href="https://docs.google.com/leaf?id=0B9s2w8-b67zsYmZmY2RmNTYtZjYzNC00NjhiLWJlMjMtOWE0M2QxMDhkY2My&hl=en">location at Immaculata University</a>. So if any blog readers happen to be in the Philadelphia PA area on those dates and would like to come by, you’re most welcome! I realize that solo piano doesn’t illustrate very well the “teamwork” principle that ensemble music would. But I’d like to convey a faithful and yet personal interpretation of the composers’ musical “specifications” to connect with my audience so that they realize the genius and beauty of what Bach, Beethoven, Liszt, et al created. So even though it’s a solo recital, I’m trying to be the “interface” between the composers and my audience. Hopefully, not too much will be lost in translation!</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Anyway, after this “break,” next time I’ll return to conclude the CCHIT Certification Retrospective.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2884798267408472642.post-62732246744939018292011-04-28T13:40:00.002-04:002011-05-20T10:05:53.918-04:00Certification Retrospective Part 2 – Method to our Madness?<div class="MsoNormal"><i>Note: this blog post will continue discussing my experiences in CCHIT. The opinions are mine, and do not necessarily reflect the views of CCHIT or Siemens. </i></div><div class="MsoNormal"><br />
</div><div class="MsoNormal">In Part 1, I talked about CCHIT giving me the privilege to work with great people over the years. But we didn’t volunteer for CCHIT just to meet people, but to do important work to advance the HIT industry. So what did we accomplish, and what were we thinking as we evolved? </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">One thing I learned is that no group can please all the people all the time. Sometimes, people wondered <i>why</i> we proposed some criteria and not others, or proposed the timeframes that we did. So we tried to explain these “whys” in a white paper <a href="http://www.morrisseywrites.com/wp-content/uploads/2010/04/CCHIT_Interoperability_white_paper.pdf">Interoperability, Supplying the Building Blocks for a Patient-centered EHR</a><b> </b>in mid-2009 which still exists on the website of writer John Morrissey. It described the context for what we were doing and the “methodical march” to increasing levels of information interoperability that we proposed. I don’t think this was well understood by the public, who might have thought some of what we did was arbitrary. But here’s what was in our mind (well, I can only speak for myself – mine at least). </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Key principles: </div><ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal">We aren’t starting with a blank sheet of paper. The existing state of adoption (immature as it might be) must be considered, so we started each year with an “environmental scan” on the state of the HIT industry. </li>
<li class="MsoNormal">Adequate time must be provided for EHR products to make the transition to a more desirable state. We aimed for 18 months lead time from our first “signal to the market” (new draft criteria) until certification testing of those criteria. </li>
</ul><div class="MsoNormal"><br />
</div><div class="MsoNormal">Given these principles, our methodical march followed the path below. </div><ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal"><b>Data <i>Capture</i></b> precedes interoperability. You can’t share what you don’t have! When we started CCHIT, not all EHRs even captured all the data that other systems would want, so functionality criteria (ambulatory, inpatient, ED) needed to capture the data elements that could then be shared. Thus in the first certification year, 2006, there were no interoperability criteria required (though several criteria, such as Lab Results and e-prescribing, were roadmapped for later years). </li>
<li class="MsoNormal"><b><a href="http://harmonious-healthit.blogspot.com/2010/12/opening-information-liquidity-faucet.html">Information <i>Liquidity</i></a></b> (a term we didn’t use, but which implicit in our criteria) is beneficial even prior to semantic interoperability. Thus, the first clinical summaries that CCHIT certified (Continuity of Care Documents, CCDs) in 2008 required <i>human-readable</i> sections for meds, allergies, problems, etc., but not structured data. We were later criticized for this, as if we didn’t care about structured data, but this was always intended as a stepping stone to later stages (as explained in the white paper). Even today (3 years later than the 2008 criteria), many voices espouse liquidity as a more important and realistic for the near-term than semantic interoperability (“don’t let the perfect be the enemy of the good”). </li>
<li class="MsoNormal"><b>Standardized <i>Content</i> (formats and vocabulary)</b>. Human-readability is fine for humans, but doesn’t help most EHR systems to “understand” (semantics) and process the information they receive from others. Because of the existing <a href="http://en.wikipedia.org/wiki/Tower_of_Babel">Tower of Babel</a> syndrome most EHRs have been “confounded” in their ability to share information with other EHRs, and to “consume” (not just display) it. So CCHIT supported the goals of ONC and HITSP to progress toward standardization of vocabularies. But it realized that changing an EHR’s vocabulary overnight wasn’t realistic, and that mapping from one vocabulary to another is not simple or foolproof and must be done carefully for patient safety and other reasons. Thus a “glide path” from narrative to standard vocabularies was roadmapped. </li>
<li class="MsoNormal"><b>Discrete Data Import (Consumption). </b>When liquidity and standardized content are established, the EHRs that receive or retrieve clinical data can “do something” with the data, more than just file and display it. As early as 2007 criteria, we published certification criteria for ambulatory EHR <i>discrete import of Laboratory Results</i> that referenced the HITSP-endorsed HL7 2.5.1 Lab Results Reporting Implementation Guide, including a common subset of LOINC observation codes. Thus, many of us were disappointed when the ONC Final Rule for certification, published in 2010, lacked a specific HL7 standard and LOINC requirement, not going as far as what CCHIT had been certifying since 2007. There are 127 CCHIT <span style="color: black;">Certified®</span> ambulatory EHRs that already meet this requirement. For CCDs, the challenge of discrete data import is greater because of the wider variety of data, and multiple applicable vocabularies. Rather than declaring the problem too big to tackle in one shot, we proposed chipping away a few sections at a time, starting in 2010 with discrete import of medications (using RxNorm as specified by HITSP), allergies (using RxNorm and UNII), Immunizations (using CVX) and demographics, then moving on to problems (using SNOMED-CT). These criteria are a matter of public record, and can be found on the CCHIT website: <a href="http://www.cchit.org/certify/2008/ambulatory-2008-ehr-certification">2008 criteria</a>. See 2008 Criterion IO-AM 11.06 for example, which originally roadmapped discrete data import for 2009, though the date changed to 2010 in the 2009 criteria (published but then withdrawn)***. You can decide based on the facts whether we were too aggressive, or too laggardly, or about right.</li>
</ul><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b>So what’s the point of this retrospective? </b>I’ll<b> </b>sum up lessons learned in the next post. I’ll also speak more about how CCHIT’s interoperability criteria compared to ONC’s criteria. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">I’ll also discuss some of the agonizing controversies that we faced, particularly in 2008 and 2009 over issues like standardized transport, discrete data import, data reconciliation turf (is it <i>interoperability</i> or <i>functionality</i> or both?) and the feasibility of requiring SNOMED-CT. We wrestled with each of these, and did our best. We might not have succeeded perfectly in all of them, and our criteria development work was superseded by ONC before we could resolve them all, but we learned much in the methodical march!</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">David</div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><span style="font-size: 10pt;">*** (Long Footnote)</span></div><div class="MsoNormal"><span style="font-size: 10pt;">The 2009 Ambulatory Certification criteria, along with the CCHIT 2009 certification program, were not launched, since they were in limbo awaiting decisions on ONC-ATCB certification. But eventually most of these criteria (without the roadmap) were relabeled and launched as the <a href="http://www.cchit.org/sites/all/files/CCHIT%20Certified%202011%20Ambulatory%20EHR%20Criteria%2020100326.pdf">2011 CCHIT Certified® ambulatory criteria</a>. If the 2009 program had proceeded, Criterion IO-AM 11.06 would have required the following in 2010, adding much specificity beyond what had been proposed in the same criterion in 2008: </span></div><div class="MsoNormal"><i><span style="font-size: 10pt;">The system shall provide the ability to display CCD documents, using a subset of the HITSP C32 specification for the Medication and Immunization History module, file them as intact documents in the EHR, and import the discrete data from one or more of the entries in a structured form into the patient record. The system shall provide the ability to import as discrete data the following data elements from the C32 Medications Module: Free text SIG, free text product name, free text brand name, coded product name, coded brand name, product concentration, status of medication, quantity ordered, order date/time, order expiration date/time, prescription number, quantity dispensed, and fill number. (Note: fill number means the number of fills dispensed, not the number of fills prescribed). The “required if known” (R2) data elements will not always be known, and therefore will not be present in every instance of a C32 document, but if present, the system shall be able to import them</span></i><span style="font-size: 10pt;"> </span></div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><span style="font-size: 10pt;">More was explained in the Comments column: </span></div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><i><span style="font-size: 10pt;">Medication and Immunization History-Coded Subset includes the following content modules of the HITSP C32: Person Information, Healthcare Provider, Medications-Prescriptions and Non-Prescription, Information Source, Comments</span></i></div><div class="MsoNormal"><i><span style="font-size: 10pt;">The intent for 10 Certification is not to require specific capability to use the imported data but only to show the system is capable of processing discrete data elements from a CCD. In future certification years, more functionality criteria to “use” the data may be added. Fulfillment of the 10 Certification criteria may be demonstrated in a variety of ways, including but not limited to any one of the following:</span></i></div><div class="MsoNormal"><i><span style="font-size: 10pt;">- Reconciliation functionality that allows CCD data to be compared with existing data, and selectively imported into a list</span></i></div><div class="MsoNormal"><i><span style="font-size: 10pt;">- A display of data captured from external sources, including the imported discrete data. The physical storage location (database table, file, etc.) is at the vendor’s discretion and does not need to be the same location as the active allergies.</span></i></div><div class="MsoNormal"><i><span style="font-size: 10pt;">- Creation of an CCD that includes the elements previously imported as discrete data</span></i></div><div class="MsoNormal"><i><span style="font-size: 10pt;">Vendors may innovate and differentiate their products by how well such data are used, but 10 Certification will not limit vendors to any particular approach</span></i><span style="font-size: 10pt;"></span></div><div class="MsoNormal"><br />
</div>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-2884798267408472642.post-89637902528082210702011-04-25T21:27:00.002-04:002011-04-26T10:19:29.490-04:00Certification Retrospective -- Part 1<div class="MsoNormal"><i>Note: this blog post will discuss my experiences in CCHIT. The opinions are mine, and do not necessarily reflect the views of CCHIT or Siemens. </i></div><div class="MsoNormal"><br />
</div><div class="MsoNormal">It’s been a long time since I blogged, even though there have been many HIT topics to blog about, such as Stage 2 meaningful use, the ONC Standards and Interoperability Framework, the ONC Strategic Plan, the NPRM on Medicare Shared Savings (Accountable Care Organizations), and more. I’m getting back on the wagon. One topic I’ve wanted to blog about for a while, even though it’s not a current “hot topic” in the news, is my experience in the <a href="http://www.cchit.org/">Certification Commission for Health Information Technology (CCHIT)</a> prior to the establishment of the ONC certification program. This bubbled to the surface when I read a <a href="http://histalk2.com/2011/04/02/time-capsule-cchit-should-provide-more-information-to-purchasers/">HISTalk “Time Capsule” posting.</a> So I’ll write another mini-series (probably two or three parts). This first post will simply introduce the “cast of characters” and how they interacted. The next posts will talk about what the Interoperability Workgroup of CCHIT did, and how its work through 2009 related to the ONC-ATCB certification program as we know it today. There are useful lessons learned.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">As a matter of disclosure, I’ve been a CCHIT volunteer for more than five years, and am still officially a co-chair of CCHIT’s Interoperability Workgroup, but this group has been inactive for about a year though it still nominally exists. The reason for its inactivity is that it was chartered as a group to propose <i>certification criteria EHRs</i>, a role that was displaced by ONC and the HIT Standards Committee. CCHIT still offers its branded certification program called “CCHIT Certified®” that is completely distinct from the ONC certification for which CCHIT is an authorized testing and certification body (ATCB). The branded program includes criteria that I and many others worked on until 2009. In interoperability, CCHIT is currently performing testing based on the NIST test scripts and some optional tools, but it is not developing any new interoperability criteria at this time. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Industry collaboration – whether in standards organizations or groups like CCHIT – has been a rewarding and mind-expanding aspect of my career. It’s about the people who work together to benefit many more people (e.g., patients and providers), trying to leave their agendas and “organization hats” at the door. So this first post focuses on some facts about the volunteers of CCHIT interoperability. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">I found it fascinating to compile a list of the people I’ve served with on Interoperability workgroups at CCHIT. <a href="https://docs.google.com/leaf?id=0B9s2w8-b67zsZDJkYzMzMGItM2IyNC00NDFhLWE0NGMtMTVjMjJkOGJiMDJh&hl=en">See this link for a table of volunteer names</a>. It’s a pretty diverse and impressive list, IMHO. The list of CCHIT workgroup members has always been publically posted, though I don’t know if it’s preserved historically, so I had to dig through my archives. My apologies if there are some typos in my list. The organizations listed were as of the time the people were on the workgroup, not necessarily where they are now. And occasionally there were people who had to resign for lack of time and a few were replaced but that may not be reflected in my table. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Each year, the Interop Workgroup had between 13 and 24 members (the 24 divided into two groups). Over 60 members served on the workgroup at some time. Of these, 9 were from EHR vendors (only counting vendors of products subject to certification, not vendors of different product types like e-prescribing, lab systems, or HIE tools). The EHR vendor reps were generally active participants, but they didn’t dominate the workgroup. Of course, there are many other interoperability experts who <i>could have</i> been on CCHIT but weren’t, since there was limited space. In that sense, CCHIT was not open like a Standards Development Organization, but it tried to establish a small committed group of volunteers, selected by an application process according to guidelines for stakeholder balance. Sometimes, we knew what we didn’t know, and invited guests to educate us at our meetings, on topics like e-prescribing, vocabularies, and clinical documents. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Sometimes the group was split into an Inpatient Interop WG and and Ambulatory Interop WG (in which case I was on the Inpatient side). In the last year, it divided into an Advanced Interoperability WG and a “regular” Interoperability WG (I co-chaired the latter). Usually a small subset of volunteers would work on specific subsets of criteria (e.g., Lab, eRx, clinical documents) and the entire WG would review and refine. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">I have very positive feelings towards these people. They’re some of the finest I’ve worked with, and I am grateful to them. There was a strong sense of collegiality and teamwork, and the sense that we were doing something important. While there were downsides to the group being selected rather than open, that also helped motivate most members since they couldn’t passively leave the work to “someone else” as tends to happen in larger groups. Collaboration was real across different stakeholders and even among vendor competitors. Sure we wouldn’t always agree. Some members thought criteria should be much more aggressive. Others couldn’t understand why features they regarded as only “nice-to-haves” should be mandatory for certification. Sometimes (as co-chair) I’d feel frustrated if I thought someone wasn’t pulling their weight (e.g., not showing up for meetings). It’s inevitable that in volunteer organizations not everyone contributes equally, but everyone had the opportunity. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">In acknowledgments, there’s always a risk of omitting someone important, but I especially want to thank Amit Trivedi and Anita Samarth who alternated as CCHIT staff leads for interoperability. Their support was tireless and outstanding: I still remember 4am e-mails from both of them as they worked towards tight deadlines! And I really appreciated the commitment, passion, and the desire to do the right thing, from my fellow-co-chairs such as Dr. Alan Zuckerman, Dr. Pat Hale, and George Robinson. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">The Board of Commissioners was mostly “out of sight” for the workgroup. They respected and endorsed the expertise of the volunteers, but would attend our meetings if we needed them (Dr. Leavitt did this several times), offering guidance but not dictating what we should do. I only remember being “overridden” by the Board on one substantive issue. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">In the subsequent post(s), I’ll talk more about the interoperability work products that we developed, how it related to standards organizations, ONC, and what I would have done differently if I could start over. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">David</div>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-2884798267408472642.post-2938667551630976932011-02-22T16:07:00.005-05:002011-07-01T12:49:27.207-04:00Would You Like to be Engaged to Multiple EHRs?<div class="MsoNormal">There’s strong agreement that for meaningful use of Healthcare IT, patients and families need to be “engaged.” The question is, how? In Stage One, patients are to be given an electronic or paper copy of clinical summary information from office visits and hospitalizations, as well as discharge instructions from hospitals. This is good and a step beyond mere paper. But that raises the question of how this information can be used by the patient, other than viewed as if it were paper. What’s the “<a href="http://harmonious-healthit.blogspot.com/2011/02/quickening-flow-of-health-information_17.html">Quicken” equivalent</a> of a “killer app” for patients to manage their health? (Oops, maybe “killer” app is not so good for healthcare…). The <a href="http://healthit.hhs.gov/media/faca/MU_RFC%20_2011-01-12_final.pdf">Stage 2 Meaningful Use Request for Comment</a> proposes that patients be able to view and download their information from a “web based portal” that is a module of an EHR (considering that the incentive program is about “certified EHR technology”).<br />
<br />
The best tool for any given patient depends on the individual, so speaking in statistical terms may gloss over some things. But let’s suppose that all EHRs were to offer such a portal. How many of them would a patient need to access? For myself last year, that would have been five (four EP and one hospital). According to an <a href="http://www.mskcc.org/mskcc/shared/graphics/epidemiology/How_Man_Doctors_text.pdf">article by Peter Bach of Memorial Sloan Kettering Cancer Center</a>, the typical Medicare patient sees seven doctors in four practices in one year, and those with multiple chronic conditions saw 11 docs in seven practices in one year. If you then throw in a hospital, that means eight healthcare organizations possibly with eight EHRs for one patient in a year. If you’re a family member caring for your children or aging relatives, multiply all that. You might have to interact with more than 20 web portal accounts, ending up with over 40 separate downloaded files (you’d probably need more than one per organization per year). Even if they’re in a standardized format, who or what will reconcile or pull them together? Will you be the one, using copy & paste with a spreadsheet or word processor? I don’t think so… If you use a web-based tool specifically designed to deal with those files, well then you’re probably using a Personal Health Record (PHR).</div><div class="MsoNormal"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiMMhmybYAt6y5PE9qQbVfx_KEhHsRGg9EGqVfLVO7fXRBQzh2HqybaPVc281XXuk4F7Vue9OjiQuMyp3IJMo1h42F1sinp0eRDX9DvwCmUbtxq4wH8u72ZY_Td-t8ynl462wvvRJy74w/s1600/PatientOverwhelmed.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="238" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiMMhmybYAt6y5PE9qQbVfx_KEhHsRGg9EGqVfLVO7fXRBQzh2HqybaPVc281XXuk4F7Vue9OjiQuMyp3IJMo1h42F1sinp0eRDX9DvwCmUbtxq4wH8u72ZY_Td-t8ynl462wvvRJy74w/s320/PatientOverwhelmed.JPG" width="320" /></a></div></div><div class="MsoNormal">The problem with the current MU proposal for downloading from individual EHRs is that it implicitly endorses a “tethered PHR” model – a PHR extension of an EHR. But that PHR is not really patient-centric, because it contains the patient’s data from the organization using the EHR. Over time, the data will broaden as EHRs import and reconcile data from other sources such as EHRs or Healthcare Information Exchanges, but most EHRs aren’t there yet. And “tethered” is only one of several approaches to patient-centric health records. Other flavors include independent personally-controlled PHRs such as Microsoft’s and Google’s; health record banks; payer-based PHRs such as Blue Cross; employer-based PHRs such as Walmart’s using Dossia. They all have their strengths and weaknesses, but the personally controlled PHR has recently made some significant headway, associated in part with the <a href="http://blog.directproject.org/2011/02/ehr-to-personally-controlled-direct-address-also-in-production.html">Direct Project announcement re Dr. Paolo Andre’s EHR</a> and <a href="http://geekdoctor.blogspot.com/2011/02/cool-technology-of-week_18.html">Beth Israel’s Direct Push to Healthvault</a>. If independent PHRs can be updated through a <b>standard transport</b> protocol (Direct secure SMTP), that securely pushes <b>standardized content</b> (e.g., CCD or CCR) into the PHR in a way that is structured and codified, as already required in Stage 1 MU, then the potential for a comprehensive, patient-centered record (not tied to any one provider) has increased. Now this isn’t magic – the patient or family member still needs to decide which data from the CCD are relevant and should be added to their master problem list, medication list, etc., as I’ve done with my own PHR. An ecosystem of innovative products (trackers, monitors) can then flourish around the PHR, given the influx of more robust data to operate on. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">In preparing comments to the HIT Policy Committee’s Meaningful Use workgroup, I’ve recommended that MU should focus on the goal: getting the information to the patient or caregiver’s hands in a way that they can use, not on inadvertently favoring an EHR-centric “tethered PHR” flavor. Let the EHRs do the behind the scenes work of transmitting the patient’s info into PHRs of the patient’s choice (which might be any of the flavors I mentioned), enabling patients to interact productively with a tool they like, rather than making them “polygamously engaged” to multiple EHRs/portals and encumbered with lots of files to manually import into PHRs. For patients who don’t want to use a PHR, they can still get their electronic copies (as in MU Stage 1). But for those who want the opportunity to have their electronic information together in one place, there’s a great opportunity for MU, defined in a way that allows flexibility and innovation, to leverage the Direct Project and the existing and emerging clinical content standards like <i>harmonized</i> (I like that word) <a href="http://jira.siframework.org/wiki/display/SIF/CDA+Consolidation+Project">CDA Consolidation Project</a> templates building upon CCD/C32. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">So, patient and family engagement: yes! Let this relationship between patients and HIT be <i>productive, patient-centered, </i><i>simple-to-use</i> and... <i>engaging</i>, please! </div>Unknownnoreply@blogger.com4