Consortium News

<< First  < Prev   ...   17   18   19   20   21   Next >  Last >> 
  • 09 Jan 2015 11:45 AM | Brian Kelley (Administrator)
    During the week of April 26 through May 1, 2015, a second sample group of providers will have the opportunity to participate in ICD-10 end-to-end testing with Medicare Administrative Contractors (MACs) and the Common Electronic Data Interchange (CEDI) contractor. The goal of end-to-end testing is to demonstrate that:
    • Providers and submitters are able to successfully submit claims containing ICD-10 codes to the Medicare Fee-For-Service (FFS) claims systems
    • Centers for Medicare & Medicaid Services (CMS) software changes made to support ICD-10 result in appropriately adjudicated claims
    • Accurate remittance advices are produced
    Approximately 850 volunteer submitters will be selected to participate in the April end-to-end testing. This nationwide sample will yield meaningful results, since CMS intends to select volunteers representing a broad cross-section of provider, claim, and submitter types, including claims clearinghouses that submit claims for large numbers of providers. Note: testers who are participating in the January testing are able to test again in April and July without re-applying.

    To volunteer as a testing submitter:
    • Volunteer forms are available on your MAC website.
    • Completed volunteer forms are due January 21.
    • CMS will review applications and select the group of testing submitters.
    • By February 13, the MACs and CEDI will notify the volunteers selected to test and provide them with the information needed for the testing.
    If selected, testers must be able to:
    • Submit future-dated claims.
    • Provide valid National Provider Identifiers (NPIs), Provider Transaction Access Numbers (PTANs), and beneficiary Health Insurance Claim Numbers (HICNs) that will be used for test claims. This information will be needed by your MAC by February 20, 2015, for set-up purposes; testers will be dropped if information is not provided by the deadline.
    An additional opportunity for end-to-end testing will be available during the week of July 20 through 24, 2015. Any issues identified during testing will be addressed prior to ICD-10 implementation. Educational materials will be developed for providers and submitters based on the testing results.

    For more information:

    Keep Up to Date on ICD-10
    Visit the CMS ICD-10 website for the latest news and resources to help you prepare. Sign up for CMS ICD-10 Industry Email Updates and follow us on Twitter.

    Retrieved Jan 9, 2015 from

  • 08 Jan 2015 3:22 PM | Brian Kelley (Administrator)
    First health information exchange in the country to tap its data to improve patient care
    PORTLAND, ME | January 7, 2015  | Retrieved from

    Knowledge is power. The folks who run Maine's statewide health information exchange have been keenly aware of this adage for some time – focused on not merely delivering information, but also on putting the vast amount of data they collect to work on helping providers give the best care they can.

    With their partners at HBI Solutions in Palo Alto, Calif., HealthInfoNet, which operates the statewide HIE, is helping hospitals, ACOs and physician practices put the power of near real-time data to work on improving patient care.

    The HIE has plenty of data to work with. HealthInfoNet’s comprehensive clinical data repository contains records for nearly all of Maine’s 1.3 million residents. It collects clinical information from 32 of the State’s 36 acute care hospitals and 326 ambulatory locations including primary and specialty care practices and long-term care facilities.

    Today, according, to its CEO, Devore Culver, HealthInfoNet has contracts for its predictive analytics package from five hospitals and the state's Pioneer accountable care organization. The HIE is the first in the country to adopt this type of model. And, from the trials that took place before the contracts were signed and the work the predictive analytics make possible today, it's a model that's mighty.

    Customers can use the analytics and predictive tools to study market share, clinical performance, population health and patient risk, all in real-time.

    St. Joseph Healthcare in Bangor, the first organization to use the new tools, is focused on cutting its 30-day readmissions rate.

    Jessica Taylor, RN, is a care manager in the organization’s internal medicine practice.
    “It’s easy to capture the patients that we know need a lot of help," Taylor said. "My goal was to reach those patients that are doing OK but might be getting into trouble and get them the help they need.”
    Sometimes a simple early intervention, like timely home care services for someone with congestive heart failure, can prevent a hospitalization, she explained.
    "Jessica is a long time user of the exchange," Culver told Healthcare IT News. "She is focusing on the patients that have not yet gone south – people who show signs of getting worse, catching people that otherwise would have fallen through the cracks," he said, noting that the predictive data helps caregivers identify patients who are at risk before their condition gets worst.
    "Every night we run all the transactions from the previous day, so we're never more than 24 hours behind," Culver said. "So that really is part of the power, is that its very, very, very current. In running that update of the data, HBI is recalculating the risk scores every day, too, based on the data. So it really is incredibly immediate, incredibly powerful."
    HBI Solutions President Eric Widen noted that automated close to real-time patients assessments eliminates 15-20 minute manual assessments: "We completely eliminate that work and save the organization thousands of hours of manual time by just automating the risk scores within that."

    Claims data, at best is 90 to 120 days old, Widen pointed out.

    "At worst, ours is going to be 24 hours old," he said. "You basically get a comprehensive risk profile on a patient updated every day. It provides risk of many different things, which helps the care manager understand what else the patient might be at risk for – risk of ED admission, risk of disease, its kind of a dashboard of risks."

    In addition to selling the service to HIE customers in Maine, HealthInfoNet is partnering with HBI Solutions to help exchanges outside of Maine set up similar tools for their customers. The two companies have met with a number of statewide and private HIEs in the past few months.
    “HealthInfoNet has been a leader in the HIE space for sometime and feel we have a lot to offer other HIE organizations as they set up similar services,” said Culver. He added that an HIE needs to provide additional value to its customers in order to be sustainable.
    “We believe this type of service is an important piece of the sustainability pie for the HIE and its customers," Culver said.
    In the case of Maine's HIE, "the stars aligned," Culver said. "Two organizations who are generally pretty forward thinking found each other and discovered that each had an asset the other one needed.
    "We had a lot of data, but not necessarily a way of doing this kind of stuff with it," he added. "HBI had a really interesting tool they'd been working on as a product of trying to predict variation of the genome and they thought they could apply to anything medical. And, lo and behold, we think we've proven that's true."

  • 08 Jan 2015 2:55 PM | Brian Kelley (Administrator)
    JASON Report Part II was released at the end of November, titled Data for Individual Health. The report aims to examine how to create a health information system that focuses on the health of individuals. The report focuses heavily on the critical need for the adoption of open APIs to foster interoperability. Claims are made in the report that the health data infrastructure does not have the capability to make the data accessible in a usable form or to represent it in an atomic format.

    The ONC has spent considerable time and money trying to foster interoperability through Meaningful Use the past several years. Putting the infrastructure in place to support CCD and CCR was the main focus of interoperability for Stage 1. Then Stage 2 introduced Consolidated CDA along with the Direct Project, which was touted to be a secure and simple protocol that would be easy to implement. So what does the JASON Report have to say about CDA and the efforts made towards interoperability so far?

    The report indicated that as a document standard that CDA did possess some “desirable characteristics.” There are three areas of the CDA approach that received positive comments in the report:
    • The CDA Header, one of the six key characteristics of a CDA document as defined by HL7, sets context for the entire document.
    • The human readability component of CDA was viewed as a positive feature. Human readability is also one of the six key characteristics of a CDA document.
    • Level 3 Semantic Interoperability. CDA documents which apply Level 3 Semantic Interoperability with full coding of the entries were seen as “a good example of an open standard that can be further evolved.”
    This is where the compliments end, which is not exactly a glowing endorsement of CDA.

    The chief complaint with CDA is that it is “really only a container for the information.” The report focuses in the importance of having open standards which embrace the concept of atomic data. While the report concedes that XML will allow for the parsing of the data to be used in an atomic way, they comment that disaggregating the data in this way “is made quite difficult.”

    The report does not go into details as to why the parsing of the data has been so difficult, but there have been obvious difficulties for each stage of Meaningful Use:

    Meaningful Use Stage 1. The requirements for Meaningful Use Stage 1 called for the infrastructure to be in place to send a CCD or CCR document. In a previous blog, I discussed how vendors would chose to test with CCR instead of CCD because it was simpler. The CCD of Meaningful Use Stage 1, the C32 version, had multiple sources of truth requiring anyone who wanted to understand the standard to go to multiple implementation guides. This did not make it easy to embrace the standard.

    Meaningful Use Stage 2. The requirements for Meaningful Use Stage 2 called for the use of C-CDA. The C-CDA standard aimed to solve the multiple sources of truth by combining the standards of nine different common document types into one C-CDA implementation guide. One of those nine document types was CCD. But, curiously, the ONC chose to utilize none of those nine document types, but rather four additional document types. These document types are structured using the C-CDA standard, but are not one of the included nine defined types. Needless to say, this adds to the difficulty of disaggregating the data as pointed out in the JASON report.

    If CDA is not an adequate standard for leading the industry to utilize atomic data, then what would be better? The report spends many more pages talking about the possibilities than they do rehashing what went wrong in the past. After the discussion of CDA the report analyzes the emerging HL7 FHIR standard, and details how REST and FHIR could become the foundation for the future of the health IT system. Look for future blogs that focus on FHIR. I look forward to your comments below [ click here to view / comment ].

    By Rob Brull | Retrieved from
    January 8, 2015

  • 08 Jan 2015 8:38 AM | Brian Kelley (Administrator)

    There is growing interest in the health care information technology community in an emerging data exchange technology known as FHIR (pronounced “fire”).

    FHIR, or Fast Health Interoperability Resources, is a proposed interoperability standard developed by the health care IT standards body known as HL7. Health Level Seven International (HL7) is a not-for-profit, ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing and retrieval of electronic health information.

    Stakeholders from across the HIT ecosystem are actively exploring, experimenting and testing FHIR. Part of the enthusiasm surrounding FHIR is due to the elegant simplicity of the technology.

    FHIR is attractive primarily because it is based on a truly modern web services approach (and one used by companies such as Yahoo, Facebook and Google). This approach makes it easier for systems to exchange very specific, well-defined pieces of information, rather than entire documents.

    Such specific pieces of information might be as simple as a patient’s gender or marital status. Today in HIT, the common standard is one based on what is known as C-CDA, or Consolidated Clinical Document Architecture. And unfortunately, C-CDA is designed to transfer entire documents, rather than a single piece of data or a simple list.

    [See also: The scariest aspect of the Sony hack for healthcare.]

    This means that today, when a physician requests just one piece of information about a patient, the system often needs to transfer multiple documents to fulfill the request. This process can often be inefficient, because a physician may have to search through many pages of information to find just one piece of needed data.

    FHIR, on the other hand, makes it simple for anyone to receive only, and specifically, the piece of information requested. FHIR also allows access to smaller or “granular” data elements that are not included in some clinical documents.

    In sum, the proposed FHIR-based standard will make exchanging health care information faster and much more efficient.

    The major technology change embodied in FHIR is a fundamental move away from a document-centric approach to a data-level access approach using application programming interfaces or APIs. Specifically, FHIR features a concept called “Resources,” meaning a very basic set of structured data.

    For example, a resource could be defined as a medication list, a problem list or lab results. Already in today’s system, standard coding sets such as Logical Observation Identifiers Names and Codes (LOINC) for lab results, or RxNorm for medications, allow software applications to exchange just the data that is needed and present it in a highly meaningful way to clinicians or consumers. What FHIR offers is tools for developers to assemble and present many much smaller data elements to enhance the context or meaning of the information.

    The consumer aspect is critical because the same technology can be used for patient engagement. FHIR will allow developers to access and use personal health care information to create innovative new apps. An app might be created to remind patients to take certain medications at the right time, for instance. The open Internet standards utilized by FHIR will make a personal health care “account” work much like any other secure app.

    An ‘app store’ approach
    In addition to offering the means to exchange healthcare data in much more granular pieces than ever before, FHIR is also easy for software developers to work with, which could prove to be a big boon to innovation.

    These technical capabilities provide the opportunity for a plug-and-play platform that is conceptually similar to the Apple app store. FHIR would allow developers to create new and innovative apps by using the Public APIs and following a well-defined set of rules. In this sense, the interface represents a true app store approach to healthcare data and interoperability.

    Today, many software vendors build their own APIs to share data with specific applications. Most vendors, however, would likely embrace a Public API offering a unified approach to share data with any application. This enables plug-and-play capability between systems, not just within systems. The ability of this interface to exchange data with any software using a Public API can foster an ecosystem of interoperability among health IT systems.

    Current and future market needs
    Health industry leaders and policy makers are increasingly focused on driving greater interoperability between and among health IT systems. That is, as value-based health care models expand, both payers and providers need secure ways to better connect and exchange analytics and information. 

    This particular opportunity is sometimes overshadowed in the discussion of FHIR. The uses of Public APIs are not solely for EHR vendors undefined HIEs can and should leverage Public APIs in order to expand their use cases. Indeed, a key issue for statewide HIEs will be leveraging the new Public APIs to support value-added services for their communities.

    FHIR squarely attempts to address these business needs, both by leveraging existing technologies in an easy-to-use and readily replicable “app-like” environment, and by providing truly granular data-level access as a step forward from today’s document-based exchange architecture.

    FHIR keeps common scenarios simple and attempts to provide more seamless connectivity standards. The proposed standard represents a smarter way to use technology by building on what is already in place while also providing the flexibility to meet future business needs. FHIR is not simply adding additional standards to an already overflowing kettle, but rather the next step in the evolution of standards that will truly promote interoperability.

    FHIR a possible standard?
    The Office of the National Coordinator JASON Task Force and others have made recommendations to the ONC to establish and maintain a set of public API standards. Assuming ONC follows the recommendations, EHR vendors would be required to use those Public APIs to obtain certification. If FHIR were to be designated as the Public API, the implications are far-reaching.

    FHIR technology represents a major opportunity to accelerate health care data interoperability across a wide range of currently disparate systems.

    Ultimately, FHIR may become a critical technology driver for increasing health care quality, increasing patient access and use of health information and improving outcomes

    Retrieved from

    January 8, 2015

<< First  < Prev   ...   17   18   19   20   21   Next >  Last >> 

Massachusetts Health Data Consortium
460 Totten Pond Road | Suite 690
Waltham, Massachusetts 02451

For more information,
please contact Arleen Coletti
by email or at 781.419.7818

join our mailing list

© Massachusetts Health Data Consortium