Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and HIPAA for FREE!!

HL7 Releases New FHIR Update

Posted on April 3, 2017 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

HL7 has announced the release of a new version of FHIR designed to link it with real-world concepts and players in healthcare, marking the third of five planned updates. It’s also issuing the first release of the US Core Implementation Guide.

FHIR release 3 was produced with the cooperation of hundreds of contributors, and the final product incorporates the input of more than 2,400 suggested changes, according to project director Grahame Grieve. The release is known as STU3 (Standard for Trial Use, release 3).

Key changes to the standard include additional support for clinical quality measures and clinical decision support, as well as broader functionality to cover key clinical workflows.

In addition, the new FHIR version includes incremental improvements and increased maturity of the RESTful API, further development of terminology services and new support for financial management. It also defined an RDF format, as well as how FHIR relates to linked data.

HL7 is already gearing up for the release of FHIR’s next version. It plans to publish the first draft of version 4 for comment in December 2017 and review comments on the draft. It will then have a ballot on the version, in April 2018, and publish the new standard by October 2018.

Among those contributing to the development of FHIR is the Argonaut project, which brings together major US EHR vendors to drive industry adoption of FHIR forward. Grieve calls the project a “particularly important” part of the FHIR community, though it’s hard to tell how far along its vendor members have come with the standard so far.

To date, few EHR vendors have offered concrete support for FHIR, but that’s changing gradually. For example, in early 2016 Cerner released an online sandbox for developers designed to help them interact with its platform. And earlier this month, Epic announced the launch of a new program, helping physician practices to build customized apps using FHIR.

In addition to the vendors, which include athenahealth, Cerner, Epic, MEDITECH and McKesson, several large providers are participating. Beth Israel Deaconess Medical Center, Intermountain Healthcare, the Mayo Clinic and Partners HealthCare System are on board, as well as the SMART team at the Boston Children’s Hospital Informatics Program.

Meanwhile, the progress of developing and improving FHIR will continue.  For release 4 of FHIR, the participants will focus on record-keeping and data exchange for the healthcare process. This will encompass clinical data such as allergies, problems and care plans; diagnostic data such observations, reports and imaging studies; medication functions such as order, dispense and administration; workflow features like task, appointment schedule and referral; and financial data such as claims, accounts and coverage.

Eventually, when release 5 of FHIR becomes available, developers should be able to help clinicians reason about the healthcare process, the organization says.

HL7 Backs Effort To Boost Patient Data Exchange

Posted on December 8, 2014 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Standards group Health Level Seven has kicked off a new project intended to increase the adoption of tech standards designed to improve electronic patient data exchange. The initiative, the Argonaut Project, includes just five EMR vendors and four provider organizations, but it seems to have some interesting and substantial goals.

Participating vendors include Athenahealth, Cerner, Epic, McKesson and MEDITECH, while providers include Beth Israel Deaconess Medical Center, Intermoutain  Healthcare, Mayo Clinic and Partners HealthCare. In an interesting twist, the group also includes SMART, Boston Children’s Hospital Informatics Program’s federally-funded mobile app development project. (How often does mobile get a seat at the table when interoperability is being discussed?) And consulting firm the Advisory Board Company is also involved.

Unlike the activity around the much-bruited CommonWell Alliance, which still feels like vaporware to industry watchers like myself, this project seems to have a solid technical footing. On the recommendation of a group of science advisors known as JASON, the group is working at creating a public API to advance EMR interoperability.

The springboard for its efforts is HL7’s Fast Healthcare Interoperability Resources. HL7’s FHir is a RESTful API, an approach which, the standards group notes, makes it easier to share data not only across traditional networks and EMR-sharing modular components, but also to mobile devices, web-based applications and cloud communications.

According to JASON’s David McCallie, Cerner’s president of medical informatics, the group has an intriguing goal. Members’ intent is to develop a health IT operating system such as those used by Apple and Android mobile devices. Once that was created, providers could then use both built-in apps resident in the OS and others created by independent developers. While the devices a “health IT OS” would have to embrace would be far more diverse than those run by Android or iOS, the concept is still a fascinating one.

It’s also neat to hear that the collective has committed itself to a fairly aggressive timeline, promising to accelerate current FHIT development to provide hands-on FHIR profiles and implementation guides to the healthcare world by spring of next year.

Lest I seem too critical of CommonWell, which has been soldiering along for quite some time now, it’s onlyt fair to note that its goals are, if anything, even more ambitious than the Argonauts’. CommonWell hopes to accomplish nothing less than managing a single identity for every person/patient, locating the person’s records in the network and managing consent. And CommonWell member Cerner recently announced that it would provide CommonWell services to its clients for free until Jan. 1, 2018.

But as things stand, I’d wager that the Argonauts (I love that name!) will get more done, more quickly. I’m truly eager to see what emerges from their efforts.

When The EMR Goes Down, Doctors Freak Out

Posted on August 22, 2013 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Earlier this month, health IT superstar John Halamka, MD, MS posted a story talking about how network downtime within a hospital has changed over the past 10 years or so. I thought I’d share some of it with you, because he makes some interesting points about end user perceptions and sensitivities.

First, he tells the tale of a 2002 network core failure of Beth Israel Deaconess Medical Center, where he serves chief information officer. For two days, he reports, the hospital’s users lost access to all applications, including e-mail, lab results, PACS images and order entry, along with all storage. Or as he puts it, “For two days, the hospital of 2002 became the hospital of 1972.”

He then contrasts that failure with a recent one  (July 25 of this year) in which a storage virtualization appliance at BIDMC failed.  Because the hospital was loathe to risk losing data, he and his team chose a slower path to uptime — reindexing the data — which allowed them to avoid data loss. The bottom line was an outage of a few hours.

This outage was a different ballgame entirely, Halamka says. For example:

* In 2002, staff and doctors weren’t incredibly upset, but this time physicians were angry and frantic, with some noting that they couldn’t take care of patients without EMR access.  Here in 2013, end users expect network access to be like electricity, always there short of an act of God. Worse, though downtime simply isn’t acceptable, but procedures for dealing with it aren’t up to that standard yet, he says.

* Doctors are under an incredible set of regulatory burdens, including but not limited to Meaningful U se, health reform, ICD-10 and the Physician Quality Reporting System. They fear they can’t keep up unless IT functions work perfectly, he observes.

* Technology failures of 2013 are tricky and harder to anticipate. As he notes, back in 2002 servers were physical and storage was physical, but today networks are multi-layered and virtualized. While these things may add capability, they also crank up the complexity of diagnosing system failures, Halamka notes.

Halamka says he learned a lesson from the recent failure:

Expectations are higher, tolerance is lower, and clinician stress is overwhelming. No data was lost, no patient harm occurred, and the entire event lasted a few hours, not a few days. However, it will take months of perfection to regain the trust of my stakeholders.

This story does have one ray of sunshine in it — it demonstrates that increasing numbers of doctors depend completely on their EMR, a state devoutly to be wished for by many health IT leaders. But the price of having doctors throw themselves into EMR use is having them riot when they can’t get to the system. Clearly, hospitals are going to have to find some new way of coping with downtime.

Why BIDMC Is Shunning Epic, Developing Its Own EMR

Posted on July 31, 2013 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Though its price tag be formidable and installation highly complex, the Epic EMR is practically a no-brainer decision for many hospitals.  As Beth Israel Deaconess Medical Center CIO John Halamka notes, things are certainly like that in the Boston metro, where BIDMC’s competitors are largely on Epic or in the process of installing Epic.

Why are Halamka’s competitors all going with Epic?  He proposes the following reasons:

*  Epic installs get clinicians to buy in to a single configuration of a single product. Its project methodology standardizes governance, processes and staffing in a way that hospitals might not be able to do on their own.

* Epic fends off clinicians’ request for new innovations that the hospital staff might not be able to support. IT merely has to tell clinicians that they’ll have to wait until Epic releases its next iteration.

* Epic is a safe investment for meeting Meaningful Use Stage 2, as it has a history of helping hospitals and providers achieve MU compliance.

* CIOs generally don’t get fired for buying Epic, as it’s the popular move to make, despite being reliant on 1990s era client-server technology delivered via terminal services that require signficant staffing to support. (Actually, it does happen but it’s still rare.)

*  These days, hospitals have moved away from “best of breed” EMR implementations to the need for integration across the enterprise.  As Halamka notes, such integration is important in a world where Accountable Care/global capitated risk is becoming a key factor in reimbursement, so having a continuous record across episodes of care is critical. Epic seems to address this issue.

But BIDMC is a holdout. As Dr. Halamka notes in his blog, BIDMC is one of the last hospitals in Eastern Massachusetts continuing to build and buy components to create its own EMR. He’s convinced that going with the in-house development method — creating a cloud-hosted, thin client, mobile friendly and highly interoperable system — is ultimately cheaper and allows for faster innovation.

In closing, Halamka wonders whether his will end up being one of the very last hospitals to continue an ongoing EMR development program.  I think he’s answered his own question: it seems likely that BIDMC’s competitors will keep jumping on the Epic bandwagon for all of the reasons he outlines.

Will they do well with Epic?  Will they find later on that the capital investment and support costs are untenable? I think we’ll have the answers within a scant year or two. Personally, I think BIDMC will have the last laugh, but we’ll just have to see.

BIDMC’s Encryption Program Tames BYOD Security Fears

Posted on August 14, 2012 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Beth Israel Deaconess Medical Center has begun what it calls an “aggressive” campaign to make sure every mobile device in use by its staff and students is encrypted. This is interesting in light of John’s recent post about encrypting devices to meet HIPAA.  The following update comes from the GeekDoctor blog maintained by Halamka, a resource worth reading in its own right.

The initiative, spearheaded by the indefatigable CIO John Halamka, MD, MS, is massive in scope, affecting as it does 18,000 faculty members and 3,000 doctors, plus a large student population. Costly and time-consuming though it may be, I think it’s an object lesson in what needs to be done to make “bring your own device” a safe and sustainable part of hospital computing.

“It is no longer sufficient to rely on policy alone to secure personal mobile devices,” Halamka said. “Institutions must educate their staff, assist them with encryption, and in some cases purchase software/hardware for personal users to ensure compliance with Federal and State regulations.”

Halamka and his team already began training staff regarding smart phone devices connecting with the Exchange e-mail system using ActiveSync. Under the new regime, those devices must now have password protection.

Next, the Information Systems team is beginning the massive task of encrypting all mobile devices. They’re starting with company-owned laptops and iPad-type tablets, but expect to move out into encrypting other tablets later.

While the process is understandably complex, broadly speaking the IS department is going to take every device currently owned by the institution and give it a complete going over for malware and vulnerabilities, make sure the configuration meets security standards, then fully encrypt it to meet HIPAA/HITECH safe harbor criteria.

The next phase of the program will extend the checkup and encryption process to any personally owned computers and tablets used to access BIDMC data. I’ll be interested to see if people get squeamish about that. There’s a big difference, emotionally, between letting IS strip your work device naked and sharing your personal iPad.  But clearly, if BYOD is to have a future, initiatives like this will need to go on at hospitals across the nation.