Wednesday, April 11, 2012

SIFramework Face to Face

The rest of this week is the S&I Framework Face to Face meeting.  This morning's session is for project leads.  Since I happened to be here, I attended.  The project leads did go through some updates on their status, and I thought I'd share some of the more significant (at least to me) details:

First of all, Doug Fridsma introduced two new coordinators for the S&I Framework project.  Now, as some of you know, many of the the current contracts supporting the S&I initiative expire this Federal fiscal year (ending September 30th).  So, I observed the elephant in the room and asked the obvious question about how the initiative would be maintained given that it would be losing its funding.  Doug pointed out to me that ONC has regulatory authority, and so the S&I program could move forward using ONC budget allocations to move forward the agencies regulatory requirements to promote standards and certification.  Phew.  That's a relief.  I think.  At least we won't be left with a set of specifications that there is nobody to support, although I still wonder about the long term plan to make the initiative sustainable.  I've heard little about that since it's inception.

Hans Buitendijk reported on the Laboratory Reporting Interface initiative.  Basicially, the material is now being balloted in HL7, so that workgroup is on R&R.  However, there is also a Laboratory Orders Initiative starting (big surprise there).  While Hans referenced the LRI and eLincs work that has been done in that space, he is also aware of several other activities that have already taken place (having been involved in several of them):
My hope is that the great work that Clem McDonald (of NLM and LOINC fame) did on the Common Lab Observations for HITSP is finally put to use.

The Public Health Reporting Initiative reported on its work to reduce the variability in data standards across the various jurisdictions.  They have some 30 use cases that they are trying to harmonize data elements for.  They have been doing some mapping to the Data dictionary work coming out of Transfers of Care and Query Health.  My hope, consistent with some of the work that has been done for Cancer Registries, is that eventually we can move to a model of using CDA for much of this content.

Three of the current S&I Projects are funded outside of ONC sources, including esMD (electronic submission of medical documents), LCC (long-term care), and public health reporting.

LCC is working on a longitudinal care plan.  LCC is presently working on supporting exchange of assessment data, currently being piloted by one of the Beacon Communities (Geisinger).  Consolidated CDA is going to be updated to provide some NEW templates to support better representation of assessments, and it will hopefully also support the needs of the CMS CARE program to harmonize assessments across long-term care agencies.

The CIC (Cross Initiative) workgroup reported out on their accomplishments.  One of them is that the initial work on the CEDD (Clinical Element Data Dictionary) is now available in USHIK.  CEDD isn't a TLA, so they are thinking about a name change to HDD (Healthcare Data Dictionary).

Several times today I heard the phrase "S&I Framework 2.0".  Given the outcomes on AHIC 2.0 and HITSP 2.0, I hope they decide to come up with a different way to talk about restructuring S&I.  Maybe they should just move directly to V3 ;-)

   Keith

Tuesday, April 10, 2012

Writing to and Reading From /dev/nul in MeaningfulUse Stage2


John Moehrke brings up an excellent point in his post on Meaningful Transmissions into Oblivion.

There is an assumption in Meaningful Use that a Certified EHR will both send and receive summary of care records formatted according to the standard at 170.205(a)(3), transported using the standards at 170.202.  But this is never spelled out in detail.
§170.314(b)(1) Transitions of care—incorporate summary care record. Upon receipt of a summary care record formatted according to the standard adopted at...
Two words:  Upon receipt.  But where in the rule does it ever say that an EHR must be able to receive such a thing?  There's a whole section on "View, Download and Transmit" under patient engagement.  There are discussions about being able to create clinical summaries in the correct format to give to the patient , or to Create and transmit a summary care record (in §170.314(b)(2) immediately following the above).  But nowhere in the rule is the term "Recieve" used in the context of "receive of summary of care record" using any of the standards specified.  And don't even get me started on the clarity in 170.202 and the various places that it is used.

With no receive requirement, we are effectively writing to /dev/nul


Now, I'll bring up another problem that is caused by something  missing from the rule.

Today, providers are expected to create either a CCR or a CCD (using HITSP C32) to provide a summary of care record.  In the future they will need to create a Consolidated CDA document of some sort.  What happens to the provider who is using a 2014 Certified EHR but still needs to be able to access CCD/CCR documents from his trading partners that are either still generating CCD or CCR documents, or for which a historical CCR/CCD document is available.  There's no "backwards compatibility".  At the very least, a Stage 2 certified EHR should be able to view a CCD or CCR that was created under the prior certification criteria.  After all, it is just a stylesheet transformation.

Without that requirement, we are effectively trying to access patient history by reading from /dev/nul

HealthIT Standards 101: The EDI Standards


This is the second in a Series I’m calling HealthIT Standards 101.  In this post, I’ll discuss the EDI standards used in Healthcare IT.  A quick disclaimer here:  I'm not much of an EDI standards geek outside the HL7 space.  While I know HL7 very well, I have only read NCPDP and X12 specifications.

Electronic Data Interchange Standards in Healthcare IT
There are a number of standards used in healthcare that work similarly and are based on Electronic Data Interchange standards.  These standards are designed to be independent of the communication technology, and simply describe the syntax and format of communications in terms of the text characters used to represent the information.

A unit of communication is described as a transaction or a message depending on which standard you are reading.  I’ll use the term message in this post to describe both.  There are two EDI standards from which these standards originate:  UN/EDIFACT, and X12.  The NCPDP Script standard used for ePrescribing in the US still retains its EDIFACT origins and syntax.  HL7 Version 2 messages used for a variety of Healthcare integration works very similarly to the EDIFACT standard (in fact, you can use a similar processor for both HL7 and NCPDP standards).  HL7 messages don’t follow the EDIFACT syntax rules for message headers or escaping special characters.

These EDI based messages begin with a header identifying the kind of message being sent.  That header is followed by a number of components called segments.  These are provided in the sequence specified by the message specification.  Each segment is further divided into fields, which contain a value using a data type specified by the standard.  Messages, segments and fields are delimited by special characters which vary depending upon the standard.  In some cases, fields can be further subdivided into components and subcomponents.  A single segment or groups of segments can repeat (these are called loops in the X12 world), allowing complex structures to be communicated.

The X12 EDI format was developed by ASC X12 (Accredited Standards Committee X12), and primarily serves US industry.  The X12N Insurance subcommittee of X12 develops the standards that are used for health insurance transactions in the US.

HL7 Version 2

An example HL7 Version 2 message follows
EVN|A01|198808181123||<cr>
PID|1||PATID1234^5^M11^ADT1^MR^MCM~123456789^^^USSSA^SS||JONES^WILLIAM^A^III||19610615|M||C|
  1200 N ELM STREET^^GREENSBORO^NC^27401-1020|GL|(919)379-1212|
  (919)271-3434||S||PATID12345001^2^M10^ADT1^AN^A|123456789|987654^NC|<cr>
NK1|1|JONES^BARBARA^K|WI^WIFE||||NK^NEXT OF KIN<cr>
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||||ADM|A0|<cr>

HL7 created the first release of HL7 Version 2 was created more than 20 years ago (in 1989), and addressed just a few message types.  Version 2 was an update of the HL7 Version 1.0 standard released in 1987 that harmonized HL7 with the syntax being used in ASTM standards used for similar purposes.  There have been several major and minor releases of the Version 2.0 standard since then.

Commonly implemented messages in the standard include ADT (Admission, Discharge and Transfer) which is used to support those functions in admission and registration systems, practice management integration with EHR systems, and general integration with master patient indexes.

The ORU message supports unsolicited updates and results for various diagnostic testing results (including labs and imaging), and is often used for test reporting in both inpatient and outpatient settings.

When ordering is automated (using CPOE), HL7 provides a number of messages to support ordering of tests (e.g., the OML for laboratory ordering), medication orders (in inpatient settings), and other kinds of orders (e.g., Diet).

While ORU is most commonly used to support reporting of structured results, it can also be used to communicate narrative test results, but was not designed to capture the necessary details to manage the reporting process.  The MDM messages in HL7 Version 2.- provide greater capability to manage test reporting using documents, rather than structured messages.  These are commonly implemented to communicate completed reports to EHR or hospital information systems.

While the ORU is probably the most commonly implemented message for communicating between from outside organizations into a healthcare provider, the HL7 VXU (unsolicited Vaccination Update) is commonly implemented by ambulatory providers to communicate vaccination information out to local and state public health agencies.

The most commonly implemented release of HL7 Version 2.0 is the US is probably HL7 Version 2.3.1, which is one of the options permissible under Meaningful Use Stage 1 (see the section on regulations below).  There are a number of implementation guides that support public health reporting for lab results, immunizations, and syndromic surveillance.  HL7 Version 2.5.1 was also an option for Meaningful Use Stage 2, and is being proposed as the single standard to use for these purposes and for receiving lab results into an EHR in Stage 2.

While Meaningful Use selects HL7 Version 2 for various uses, administrative simplification (HIPAA) regulations in the US require the use of X12 messages for payer (insurance) transactions, and NCPDP messages for ePrescribing (HITECH/Meaningful Use, eRX rules, and HIPAA) and communication with pharmacy benefits managers (PBMs).

NCPDP Script
An example NCPDP Prescription message follows.
UNA:+./*’
UIB+UNOA:Ø++1234567+++77777777:C:PASSWORDA+77Ø163Ø:P+19971ØØ1:Ø81322’
UIH+SCRIPT:ØØ8:ØØ1:NEWRX+11ØØ72+++19971ØØ1:Ø81322’
PVD+P1+77Ø163Ø:D3+++++MAIN STREET PHARMACY++61522Ø5656:TE’
PVD+PC+6666666:ØB+++JONES:MARK++++61522198ØØ:TE’
PTT++19541225+SMITH:MARY+F+333445555:SY’
DRU+P:CALAN SR 24ØMG::::24Ø:ME+EA:6Ø:38+:1 TID -TAKE ONE TABLET TWO TIMES A
DAY UNTIL GONE+85:19971ØØ1:1Ø2*ZDS:3Ø:8Ø4+Ø+R:1’
UIT+11ØØ72+6’
UIZ++1’

NCPDP Script was first created in 1997 to support communication of prescription information between providers, pharmacies, payers and intermediaries.  NCPDP Script uses the UN/EDIFACT syntax for EDI communications, and defines messages for (not a complete list):

·        Communicating new prescriptions (NEWRX)
·        Receiving notification of filled prescriptions (RXFIL)
·        Requesting a Refill (REFREQ/REFRES)
·        Changing a Prescription (RXCHG/CHGRES)
·        Cancelling a Prescription (CANRX/CANRES)
·        Requesting and Receiving Medication Histories (RXHREQ/RXHRES)

The two most significant version of NCPDP Script for US use are Version 8.1 completed in 2005, and version 10.6 completed in 2008.  The former was required under HIPAA, one or the other is required for Meaningful Use certification and under ePrescribing regulation.  The latest version of Meaningful Use standards proposes the use of version 10.6 only.

X12
An example X12 message follows.
ST*276*0001~
BHT*0010*13**19961115~
HL*1*20*1~
NM1*PR*2*ABC INSURANCE*****PI*12345~
HL*2*1*21*1~
NM1*41*2*XYZ SERVICE*****46*X67E~
HL*3*2*19*1~
NM1*1P*2*HOME HOSPITAL*****SV*987666~
HL*4*3*22*0~
DMG*D8*19201210*M~
NM1*QC*1*SMITH*FRED****MI*123456789A~
TRN*1*1625032606~
REF*BLT*111~
AMT*T3*8513.88~
DTP*232*RD8*19960831-19960906~
HL*5*3*22*0~
DMG*D8*19201115*F~
NM1*QC*1*JONES*MARY****MI*234567890A~
TRN*1*1622241518~
AMT*T3*7599~
DTP*232*RD8*19960731-19960809~
HL*6*2*19*1~
NM1*1P*2*HOME HOSPITAL*****SV*124567890~
HL*7*6*22*1~
DMG*D8*19451101*M~
NM1*IL*1*MANN*JOHN****MI*345678901~
HL*8*7*23~
DMG*D8*19651101*M~
NM1*QC*1*MANN*JOSEPH****MI*345678901-02~
TRN*1*16270853402~
REF*1K*961681010827~
REF*BLT*131~
AMT*T3*4899.5~
SE*34*0001~

X12 was chartered by ANSI as an Accredited Standards Developer more than three decades ago.  They are (along with HL7 and NCPDP) one of six Designated Standards Maintenance Organizations for maintaining standards used with HIPAA transactions.  The Insurance Subcommittee (X12N) of X12 is responsible for development of EDI standards used in the Insurance industry, and develops the transactions used in Healthcare.

There are two principal versions of X12 which are significant in Healthcare.  The 4010 series was allowed to be used from the inception of HIPAA up until January 2012, and was to be replaced by the 5010 series.  Due to implementation delays, CMS announced an enforcement delay until June of 2012.

There are a number of different kinds of transactions which use the X12 transactions.  Some of the more significant include:

Transaction  Description
837              Claims
835              Claim Payment Notification
275/277       Claims Attachments Request/Response
276/277       Claims Status Request/Response
270/271       Eligibility Request/Response
278              Referral Authorization

EDI and XML
EDI refers primarily to an older, text delimited syntax popular before XML came to the fore.  The standards listed above all use this older, text-based forms of electronic data interchange.  However, the standards organizations have also developed XML renditions of the EDI standards.  NCPDP created a separate XML implementation guide for NCPDP 8.1.  It now includes the XML Schema in versions since version 10.5 (see the Basic Guide to NCPDP Standards).  HL7 published XML encoding rules for its Version 2 standards in 2003.  While X12 has created XML encodings for some of its standards, I am not familiar with many systems used in Healthcare that do anything with them.

XML formats are often used inside “Interface Engines”.  These are software applications traditionally used to support EDI messaging.  Many Interface Engines are able to switch between the traditional EDI syntax, and either a proprietary XML format, or the standard XML syntax for the same message.  Using an XML syntax inside an interface makes it very easy to transform messages between formats using a variety of XML tools.  The most commonly used tool is XSLT, a W3C standard language defined to enable transformations of XML documents.

While HL7 created an XML Syntax for its Version 2 standards, they created a whole new architecture using XML for their CDA and Version 3 standards, which I’ll talk about next time.

Monday, April 9, 2012

How does the ICD10 Delay Impact MeaningfulUse Stage2

The ICD-10 proposed delay was published for inspection in the Federal Register today with a 30-day comment period starting from the date of publication in the Federal Register (expected to be 4/17).   Included also in the publication were proposals for a Health Plan Identifier and changes to the requirements for a National Provider ID for certain providers.

One question I'm sure to get if I don't address it now is how the proposed delay would impact Meaningful Use Stage 2.  Two ICD-10 vocabularies are included in the current Meaningful Use 2014 Certification Criteria

ICD-10-CM is a standard required under the 2014 criteria for recording the encounter diagnosis in summaries used for transitions of care [see §170.314(b)(2)(F)], those that can be viewed, downloaded or transmitted [see  §170.314(e)(1)(i)(B)(2)(vi)], and in clinical summaries provided to patients [see §170.314(e)(2)(ii)(F)].

ICD-10-PCS is one of the two standards allowed under the 2014 criteria (the other is CPT-4/HCPCS) for recording procedures, and immediately follows the links above.


ICD-10-CM is also use to record preliminary cause of death in the inpatient setting [see §170.314(a)(3)(ii)].

So, we have 7 requirements in the 2014 Criteria that an EHR must satisfy in order to be certified for Meaningful Use under the 2014 criteria.

As a meaningful User, if your reporting period starts in Calendar Year 2014 (for eligible providers), or in Fiscal Year 2014 (October 1, 2013) for Hospitals, you must be using an EHR that has been certified to the 2014 criteria.

Without the delay, your EHRs would have been ICD-10 capable on October 1, 2013 already.  With the proposed delay, your EHR must support both ICD-9 and ICD-10 codes.  This is because meaningful use requires summaries to use ICD-10, but your payers would require you to use ICD-9 (until the new date October 1, 2014).

This creates challenges for EHR vendors because they would have to support both requirements under the current set of proposals.  If the Meaningful Use rule were to change to use the current set of billing codes, that would also cause challenges because a vendor would either have to certify that they support both in one system, or go through "gap certification" to meet the requirements of the ICD-10 change over.

This would seem to have pretty severe impacts on a commercial EHR implementations.  The effects of the intersection of the two proposed regulations does not appear to have been considered in the regulatory impact analysis.

According to what I've heard about  Encounter diagnoses with respect to meaningful use, they were meant to be used clinically.  Given that, it seems logical that they should use the same vocabularies as the problem list (SNOMED CT at present), rather than billing vocabularies.  Making this change would simplify things somewhat for developers and implementers of Certified EHR technology.  But that only addresses issues around encounter diagnosis and preliminary cause of death.  It doesn't address issues around procedures, because EHRs would still have to cut over in October for hospitals.

Switching to PCS sooner would alleviate the latter issue, but as the proposed rule indicates, this still creates a double-switchover problem for hospitals.

There's really no easy solution to the ICD-10 problem.

Saturday, April 7, 2012

Review the Proposed Stage2 MeaningfulUse CQMs

EHR Incentive Programs ? A program of the Centers for Medicare & Medicaid Services

News Updates | April 6, 2012

CMS has Posted the Proposed CQMs under the Stage 2 NPRM on the CMS Website


CMS has posted the full set of proposed Clinical Quality Measures (CQMs) for 2014 as part of the Medicare and Medicaid Programs Electronic Health Record (EHR) Incentive Programs Stage 2 Notice of Proposed Rule Making (NPRM). The public can review the CQMs and submit feedback online.
Proposed CQMs
The proposed CQMs are outlined in two tables that describe each measure and provide additional information for eligible professionals (EPs), eligible hospitals, and critical access hospitals (CAHs) beyond the descriptions listed on the National Quality Forum (NQF) website.


Some of these measures are still in development; therefore, the descriptions provided in these tables may change before the final rule is published. When possible, links have been provided for measures that have corresponding information on the NQF website. If a measure does not have an NQF number, it means that measure has not yet been endorsed.

Public Comment
Public comments regarding these measures should be submitted using the same method required for all comments related to the proposed rule. You can submit public comments online through the federal regulations website
The deadline for public comments relating to the proposed CQMs and other aspects of the Stage 2 NPRM is May 7, 2012.

Want more information about the EHR Incentive Programs?
Make sure to visit the EHR Incentive Programs website at http://www.cms.gov/EHRIncentivePrograms for the latest news and updates on the EHR Incentive Programs.

Centers for Medicare & Medicaid Services logoDepartment of Health and Human Services logo


Friday, April 6, 2012

HealthIT Standards 101

This started out as a single article, but after I got through the first section, it's clear that this has become a series.  What I wanted to accomplish is to provide Executive, IT Managers and Implementers of Healthcare IT with an overview of applicable Healthcare Standards, along with a brief explanation of their key features and how they work.  This first post provides an overview for the series. 


Health IT Standards 101

There are a variety of standards used in the Healthcare Industry to enable interoperable exchange of information.  IEEE (a standards and professional organization) originally defined interoperability (in perhaps the most oft-quoted definition in Health IT standards) as:

The ability of two or more systems or components to exchange information and to use the information that has been exchanged.

A more customer focused definition comes from the IEEE website:

Ability of a system or a product to work with other systems or products without special effort on the part of the customer. Interoperability is made possible by the implementation of standards.

I really like this definition, because it talks about the impact of the standard on the part of the consumer, rather than the innards.  The standards these definitions speak of are standards for information and communication technology.  These are often referred to as IT Standards, ICT Standards (more common outside the US), or even more specifically, Healthcare IT Standards.

There are a variety of different kinds of standards.  Standards can be classified based upon the functionality standardized, the syntax that they use, or their purpose of use. Putting each of these into context:

·        Functionally:
IT standards can support transport of communications between systems, define the content used in exchanged, or describe particular computations or operations performed by a system. I covered some of this classification model in a previous post.

·        Syntactically:
The standards can use traditional text-based forms of electronic data interchange (EDI), use XML, ODL, IDL or UML, or binary data formats (e.g. ASN.1) for exchange.

·        Purpose:
Health IT standards can support treatment, payment or operations, or a combination of those.

Who creates Standards?
Standards are developed by a variety of Standards Development Organizations (SDOs).  Interestingly enough, there are few “standard” definitions for the term SDO.  The American National Standards Institute (ANSI) is a body that accredits (essentially certifies) standards bodies, based on a number of rules.  They describe an SDO as including professional societies, industry and trade associations and membership organizations that develop standards within their area of expertise.  That’s a bit weak, since it doesn’t really define other than by who engages in the activity.  The US government does have a pretty good definition which I’ve summarized in the section on Government Participation below.

People involved in the development of standards include:
·        Health IT Developers (geeks like me)
·        Healthcare Providers
·        Policy Makers and Influencers
·        Consumers and Consumer Advocates

Sadly, the most under-represented population is consumers of Healthcare and their advocates.

The major developers of Healthcare IT related standards in relevant to the US include:
·        Health Level Seven International (HL7) [various]
·        Digital Imaging and Communication in Medicine (DICOM) [Imaging]
·        Accredited Standards Committee (ASC) X12 [Insurance Transactions]
·        National Council for Prescription Drug Programs (NCPDP) [ePrescribing]
·        Regienstrief (LOINC) [Laboratory Vocabulary]
·        International Health Terminology SDO (IHTSDO) [Clinical Terminology]
·        International Standards Organization (ISO) [various]
·        ASTM International (ASTM) [various]
·        Institute of Electrical and Electronics Engineers (IEEE) [Medical Devices]

Other IT standards organizations have a major impact on Healthcare, including:
·        World Wide Web Consortium (W3C) [XML, HTML]
·        Internet Engineering Task Force (IETF) [Internet]
·        Organization for the Advancement of Structured Information Standards (OASIS) [Business use of XML]

What other kinds of organizations are Involved?
Profiling bodies don’t necessarily create standards, but instead show how to use existing standards to support solutions to specific use cases in implementation guides (or profiles).  While these organizations don’t claim to create standards, they often are very hard to distinguish from an SDO. 

·        Integrating the Healthcare Enterprise (IHE) [EHR, HIE, and various Medical Specialties]
·        Continua Health Alliance [Home Health Devices]
·        CAQH/CORE [Payer Transactions]
·        ONC Standards and Interoperability Framework (S&I) [EHR]

Industry Associations play an important role in the promotion of Healthcare IT standards.
·        Electronic Health Records Association (EHRA) [EHR]
·        NEMA [Imaging]
·        Workgroup for Electronic Data Interchange (WEDI) [Payer Transactions]

Professional Societies also play an important role:
·        Health Information Management  Systems Society (HIMSS)
·        American Health Information Management Association (AHIMA)


US Government Involvement

The US government advocates for, uses, participates in, develops and mandates the use of standards.

According to the US government, a standards development organization is a body, international or domestic, that provides an open and balanced forum for the planning, development, establishment, or coordination of voluntary standards through a consensus based process (paraphrased from OMB Circular A-119, last revised in 1998 and now under review).  In the US the use of voluntary rather than government mandated and/or created standards are preferred by law (see notes under UTILIZATION OF CONSENSUS TECHNICAL STANDARDS BY FEDERAL AGENCIES in 15 USC 252).

Most of the Federal Agencies involved in Health IT standardization operate within Health and Human Services (HHS), and include (not a complete list):
·        Centers for Medicare and Medicaid Services (CMS),
·        Centers for Disease Control (CDC),
·        Food and Drug Administration (FDA),
·        Office of the National Coordinator for Healthcare IT (ONC), and
·        National Library of Medicine (NLM)
·        Others (see the HHS Org Chart)

Other agencies involved include:
·        Veterans Administration (VA)
·        Department of Defense (DOD)
·        National Institute of Standards and Technology (NIST)

The DOD and VA are major procurers of Healthcare and Healthcare IT.  NIST is involved from the perspective of standards development, certification and testing.

CMS, ONC, and FDA are major regulators of Healthcare IT, and require the use of certain standards in a variety of regulations.  Major regulations promoting the use of Health IT standards include:
·        Transactions and Standards Rules [CMS/HIPAA]
Mandates the use of X12, NCPDP, ICD, NDC and CPT for Claims Transactions
·        ePrescribing Rule [CMS/Medicare Part D]
Mandates the use of NCPDP Standards for ePrescribing
·        Meaningful Use Incentives [CMS/HITECH]
Requires the use of certified EHR systems which implement standards.
·        Meaningful Use Standards and Certification [ONC/HITECH]
Defines requirements of EHR systems for certification.

ONC is both a regulator and a developer of standards through its “Standards and Interoperability Framework” program.  It develops implementation guides through a consensus process that it has defined; promotes them to the HIT Standards Federal Advisory Committee (which it appoints), requires them to be used by State HIE organizations it has funded through HITECH grants, and proposes them for use in Federal regulation.

Subsequent posts will address
·        EDI and related Standards (including HL7, X12 and NCPDP)
·        XML Based Standards (including HL7 CDA and V3)
·        Vocabulary Standards (ICD, SNOMED, RxNORM, NDC, LOINC, CPT)
·        Profiles of Standards (IHE)

Thursday, April 5, 2012

ONC/Million Hearts/American Heart Association Announce the Beat Down Blood Pressure Video Challenge HealthIT4UBP

This looks like fun. I might even participate.

-- Keith


HealthIT.gov

ONC/Million Hearts/American Heart Association Announce the Beat Down Blood Pressure Video Challenge (#HealthIT4UBP)
Share your story to win! 

In an effort to crowd source better ways the public and health care professionals can leverage technology to manage high blood pressure, the Office of the National Coordinator for Health Information Technology (ONC) in partnership with Million Hearts, an HHS initiative to prevent a million heart attacks and strokes in five years, and the American Heart Association announces a Beat Down Blood Pressure Video Challenge. This is the second in a series of 2012 health IT video challenges through which members of the public are encouraged to develop and submit a short, compelling video sharing how they use health IT or consumer e-health tools to manage high blood pressure. A $1000 cash prize will be awarded to winners in several categories with a $500 prize for the popular choice award. Entrants won't need highly specialized equipment—a standard video recorder or phone with a video function will work.

The public and health care professionals are encouraged to enter to win! Videos should demonstrate how health IT or consumer e-health tools are used to support blood pressure control through activities such as routine monitoring of blood pressure, taking blood pressure medications as prescribed, and maintaining a healthy lifestyle that helps lower blood pressure. For inspiration, check out the winning videos from the Healthy New Year Video Challenge at: http://healthynewyear.challenge.gov/

High blood pressure (aka "hypertension") affects one in three adults in the U.S. and is sometimes referred to as the "silent killer" because it damages the brain, heart, eyes, and kidneys while causing no symptoms. If left untreated, high blood pressure can result in strokes, heart attacks, and kidney failure. Fortunately there are steps that each of us can take to prevent or manage high blood pressure and technology can help!

You can enter the contest yourself or help to spread the word about it to others using the Twitter hashtag #HealthIT4UBP. ONC's one-stop shop for consumer information on health IT—HealthIT.gov—already features several compelling stories about how health IT has helped people and their health care providers save lives, beat cancer, and weather a natural disaster. The video challenges are a chance to add your story to the mix and win cash prizes.

To learn more about this challenge and others, please visit: http://bloodpressure.challenge.gov/. All challenges will be featured on http://www.challenge.gov/. The video challenge series will run throughout 2012.

About ONC's Consumer e-Health Program

This video challenge is one of many ways that ONC's new Consumer e-Health Program is working to promote patient and family engagement in health through technology by improving consumer access to their electronic health information; spurring innovation to develop new ways to make that information actionable; and shifting attitudes so people feel comfortable using new tools and health information to be better partners with their health care providers in their health and health care.