Stakeholder’s Progress report for FHIR

The following blog entry is a guest post from Grahame Grieve, creator of Fast Healthcare Interoperability Resources (FHIR):

"During the week of Sept 14th to 19th, HL7 held a working meeting during which the organization worked on further developing the FHIR specification.

FHIR is an important new standard, not just because it does what the existing specifications do in a simpler fashion, but because it does entirely new things as well.  Because of this, market interest and hype concerning FHIR is astonishing (see Wes Rishel’s comments ) . The FHIR project team is aware that there is a duality here: expectations and excitement about FHIR are high, but what we have published is still an early beta, and FHIR is not yet ready to meet the expectations that people have about it.  We intend and expect to get there, but it there is still a lot of work to be done.

One of the key gaps the project team has identified is that the clinical content parts of the specification are not as solid as the underlying technical framework. We know that the strength of FHIR isn’t because we’re clever, but because we keep testing it through implementation experience, particularly connectathons – a relentless cycle of test, refine, test…. Our regular developer connectathons are continuing to grow in participation, depth and sophistication, but they don’t test of FHIR’s clinical features well. So this meeting, we did something new: we held a clinical connectathon – a group of clinicians using the FHIR specification to communicate with each other about some prepared clinical scenarios. Like our first technical connectathon, the potential of the specification was clear, but we identified a number of areas where we need additional development before FHIR is ready for real world usage. We plan to make clinical connectathons a regular feature in the future.

During this meeting, we started preparing the next full release of FHIR – DSTU (Draft Standard) 2. We anticipate publishing this in the middle of 2015. It will feature new functionality for clinical records, assessments, claiming, consent management, and more, and we agreed to a number of significant changes to the specification in response to implementer experience. Several organizations (including ONC and HSPC ) and countries are working on implementation guides for FHIR, and their experiences are starting to drive the specification and the development of additional implementation tooling.

Up to now, FHIR has primarily been a standards project: a group of people with a core task of producing a standard. But now, the FHIR project and management teams are going to start placing increasing focus on engaging with the wider implementation community. Connectathons are effective forums for validating the specification, building an active implementer community and seeding specific exchanges. One important part of this will be ever closer cooperation between HL7 and IHE as IHE starts adopting FHIR in the future."

For a more detailed technical progress report, see Grahame's Website.
.

More Argonaut Deliverables

Micky Tripathi sent this update last evening.

Dear Argonaut Steering Committee Member,

I’m writing with a quick project update for your information.

FHIR DSTU2 Ballot.  The effort to keep the Argonaut-relevant components of FHIR on schedule was successful.  The FHIR DSTU2 ballot was opened on April 3, 2015.  All of the Argonaut-relevant FHIR Resources and associated DAF Profiles are complete and on the ballot.

·         Grahame’s description of the ballot decision is here:  http://www.healthintersections.com.au/?p=2332

·         A list of all of the FHIR DSTU2 implementation guides is here:  http://hl7.org/fhir/2015May/iglist.html

·         The current version of the Argonaut Implementation Guide is here:  http://hl7-fhir.github.io/argonauts.html

·         The complete FHIR DSTU2 version for ballot is here:  http://hl7.org/fhir/2015May/

·         A list of all published versions of FHIR is here:  http://hl7.org/fhir/directory.html

Argonaut Testing and Implementation.  Implementation and testing efforts are picking up steam, though with everyone’s immediate focus on preparing for and attending HIMSS, we don’t expect to see intensive testing until after HIMSS, when attention will turn from FHIR DSTU1 demonstrations to Argonaut FHIR DSTU2 implementations.

·         Over 30 organizations are now registered on the testing tracking document:  https://docs.google.com/spreadsheets/d/1JAVbVh_8M6e6amNh-btVMC114zBlJe4XytDNKIOMyZM/edit#gid=2060997323

·         The Argonaut reference implementation server will be updated after the HIMSS conference to include the full set of Argonaut Resources and Profiles and the first version of the Argonaut OAuth/OIDC security implementation guide.

·         After the HIMSS conference we will increase our reach out to motivate testing activities by implementation partners, who will at that point be prepared to focus their energies on Argonaut FHIR DSTU2 implementation.

The Argonaut Project Charter

Yesterday, a group of private sector stakeholders including athenahealth, Beth Israel Deaconess Medical Center, Cerner, Epic, Intermountain Health, Mayo Clinic, McKesson, MEDITECH, Partners Healthcare System, SMART at Boston Children’s Hospital Informatics Program, and The Advisory Board Company met with HL7 and FHIR leadership to accelerate query/response interoperability under the auspices of ANSI-certified HL7 standards development organization processes.

All wanted to publicly release the charter we created.  It’s important that this charter is broadly circulated and understood.

As you’ll see from the charter, each of the participants has agreed that all specifications and artifacts developed during the course of the project will be made available to the entire community via an Open Content License.

The scope of the work includes three deliverables:

FHIR Data Query Profiles. A set of FHIR Resources and accompanying profiles that enables query/response of the discrete data elements contained in the Meaningful Use Common Data Set.  The work will be completed for inclusion in the May 2015 HL7 FHIR Draft Standard for Trial Use revision 2 ballot.

FHIR Document Query Profile. A FHIR resource and profile that enables query/response of IHE X* metadata resources, and specifically, transition of care and patient summary CCDAs.  The work will be completed for inclusion in the May 2015 HL7 FHIR Draft Standard for Trial Use revision 2 ballot.

Security Implementation Guide. Based on the SMART OAuth 2.0 and OpenID Connect profiles, a final guide will be completed the week of Apr 1, 2015.  The Security Implementation Guide will eventually be incorporated in the HL7 balloting process, but for this project will be developed in parallel to accompany the FHIR Data Query and Document Query Profiles and Implementation Guides.

The Argonaut project is time limited and focused on just those three specific deliverables in 2015.  It is not a new organization nor is it competitive with any other effort.

It leverages the existing Data Access Framework efforts from ONC, is compatible with the IHE MHD profile for document exchange, and provides incremental first steps in support of the broader Healthcare Services Platform Consortium initiative.   It is complementary to the CommonWell and the various state/regional HIE initiatives.

Participation in Argonaut includes sponsors, pilot participants, and the community (anyone who wants to stay in touch with the progress of the work).

We’re working on a one page summary which will illustrate the value of the work to patients, providers, and payers as well as innovators who will find it much easier to develop modular applications using FHIR than the current CCDA over Direct approach required in Meaningful Use Stage 2.

Finally, we’ve been very careful to decouple the Argonaut work from Meaningful Use.  Although we believe FHIR should be included in future certification testing, it should not be a regulatory requirement until appropriate pilots, testing, and revision are completed.   We’ll use the six objective maturity and adoptability criteria enumerated by the Standards Committee to evaluate the appropriateness of FHIR for the Meaningful Use program including:

Maturity of Specification
Maturity of Underlying Technology Components
Market Adoption
Ease of Implementation and Deployment
Ease of Operations
Fit for purpose

I believe the combination of FHIR/OAuth/REST will align well with the stated goals/objectives of the Federal Healthcare IT Strategic plan and the upcoming Interoperability Roadmap.    

FHIR will not solve every problem and we need to be careful to under promise, but the notion of a learning healthcare system based on the kind of data liquidity we have in other aspects of our lives (social media, electronic banking, smartphone apps) seems like the right trajectory to me.

The Experience of Interoperability Thus Far

As I travel across the country and listen to CIOs struggling with mandates from Meaningful Use to ICD-10 to the HIPAA Omnibus rule to the Affordable Care Act, I'm always looking for ways to reduce the burden on IT leaders.

All have expressed frustration with the health information exchange (HIE) policies and technologies for care coordination. quality measurement, and patient engagement.

As a country, what can we do to reduce this anxiety?

Meaningful Use Stage 1 brought some interoperability especially around public health reporting. Stage 2 brought additional interoperability, with well defined content, vocabulary, and transport standards for transitions of care.

Most CIOs have implemented certified EHRs and the required standards.  Here’s a capsule summary of what I’ve heard

HL7 2.x

HL7 messaging addresses lab result and public health use cases very well.   Lab results interfaces are straight forward, however there is still some need to reduce optionality in implementation guides so that the average lab interface costs $500 and not $5000.    Public health transactions for immunizations, reportable lab, and syndromic surveillance are standardized from a content perspective but  there is still a need to specify a single transport mechanism for all public health agencies.

CCDA/Direct

CCDA documents address transitions of care use cases reasonably well.  CCDA is easier to work and

parse than CCD/C32 because it has additional constraints and specifications, but there is still enough optionality that merging CCDA data into an EHR can be challenging.    In addition, most EHRs generate a CCDA automatically and include all data that may possibly be relevant.  In some cases, this leads to C-CDAs that are rendered at 50+ pages.   We need to reduce optionality so that CCDAs are easier to generate correctly and parse.  EHR workflow needs to better support the creation of clinically relevant documents with narrative and data more specific to transitions.

Direct was a good first step for transport - we needed to pick something.  We could have required sFTP, REST, SOAP, SMTP/SMIME or even Morse Code as long as it was completely standardized. Unfortunately, we picked multiple options.   Some EHRs use XDR (a SOAP transaction) and some use SMTP/SMIME.   Whenever standards have an "OR", all vendors must implement an "AND". XDR must be translated into SMTP/SMIME and SMTP/SMIME must be translated into XDR.   The reality of Direct implementation has show us that this optionality provides a lot of plumbing challenges.   Certificate and trust issues are still an ongoing project.   Getting data from medical devices via Direct is challenging since devices tend to use heterogeneous transmission protocols. Finally, SMTP/SMIME was never designed for large payloads of multiple files, so sending datasets greater than 10 megabytes can be a struggle.   The use of XDM for zipping files before they are sent is overly complex to use as part of a transport protocol.

Although Direct works, it is often not well integrated into the EHR workflow.

FHIR, as discussed in multiple recent posts, can help address these challenges and leverage the lessons learned.  The FHIR concept is that every EHR will provide a standardized interface for the query, retrieval, and submission of specific data elements and documents using a web-based RESTful transport mechanism and OAuth security.   This use case can easily support unique modules or “bolt on” application functionality to EHRs.    It significantly simplifies the interfacing challenge, works for large payloads, and minimizes optionality.   There are no multiple transport options, no certificates to manage, and the query/retrieve processes can occur behind the scenes, enabling smoother workflow.

FHIR can even be helpful as a transition strategy while Direct is still used for pushing payloads between EHR.   If FHIR/REST/OAuth replaced the XDR/XDM options of Direct, that provides a glide path to the eventual end to end replacement of Direct with FHIR

Once FHIR is available, EHR vendors should design a user experience that follows the IEEE definition of interoperability - “the ability of a system or a product to work with other systems or products without special effort on the part of the customer. "

In summary, think of HL7 2.x as good enough for messages  pushed between systems,  Direct/CCDA as suitable but challenging for pushing XML documents between systems, and FHIR as a means to integrate multiple platforms via the use of application program interfaces that support the simple query/retreat/submission of data among applications.

FHIR will solve many of our interoperability challenges with appropriate support from EHR developers for clinically relevant workflow. We have to be careful not to oversell it, but for many use cases, FHIR is our best hope for the future.

What is the Architecture of a Modern Platform?

Platform businesses require technology that promotes interoperability and scalability.  For those who live in platform companies day-to-day, my thinking below may sound obvious, but for those who are thinking about a cloud journey, the list of technologies below may be helpful.

Storage and compute functionality in the cloud enables agility via "infrastructure as code" products such as Terraform.    Terraform enables virtual server spin up on demand within applications to provision and manage any cloud, infrastructure, or service.   Each cloud provider has strengths.    Customers like Google Cloud Platform because of BigQuery, which scales infinitely.  Customers like Amazon because of the tools like Comprehend Medical and Sagemaker.   Customers like Azure because of its integration with existing Microsoft components. 

Similarly, database functionality such as MySQL or PostgreSQL can be rapidly deployed using a front end service such as Google's SQL Cloud that makes it easy to set up, maintain, manage, and administer relational databases on Google Cloud Platform.

Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management. It was originally designed by Google, and is now maintained by the Cloud Native Computing Foundation. 

For healthcare applications, it's clear that Fast Healthcare Interoperability Resources (FHIR) interfaces for inbound and outbound data exchange are the right approach to application/EHR integration.    Highly scalable FHIR services are available via HAPI FHIR on Smile CDR . Google Health's FHIR endpoint is also a good choice.

FHIR is best for exchanging summary data, as well as making EHR data available to an application more broadly.   For HL7 version 2, the Google Healthcare API supports a Minimal Lower Layer Protocol  (MLLP) entry point and a message repository (along with cloud publication/subscription notifications).

And of course, modern network security requires data be stored in encrypted form as well as in transit in encrypted form.  This simple idea will mitigate numerous security risks.

I recently met with well respected industry leaders and asked how Mayo Clinic can future proof its Platform  efforts.    I was told

"Ensure that infrastructure as code is used to deploy storage and compute.   Ensure relational databases can be deployed and managed on the cloud hosting platform.   Use Kubernetes to automate application deployment.  Embrace hosted FHIR and API management services."

As we evaluate new partnerships and collaborations, we do a technical deep dive to avoid locally hosted, siloed, and proprietary approaches, instead favoring a cloud native architecture using Terraform, Kubernetes, and FHIR.

As Wayne Gretzky taught us, you need to skate where the puck will be.    These cloud native architectures are clearly where the puck is going.

The September HIT Standards Committee

The September HIT Standards Committee was one of the most important meetings in the history of the group.   We heard pivotal reports from the NWIN Power Team about Query/Response standards as well as from the JASON Task Force.   Together they gave us important guidance to accelerate FHIR, REST, and OAuth, aligning healthcare query/response standards with the technology approaches used in every other industry.  We were also advised to polish existing CCDA standards in the short term while working on the longer term FHIR initiatives.

Dixie Baker and David McCallie presented Query/Response recommendations suggesting that use cases for 2017 certification be limited to:

*Query a named external health care organization for a document containing a specific patient’s data
* Respond to query with requested document, list of documents, or non-availability of
document
* Allow both synchronous and asynchronous queries

They proposed that certification be based on functional requirements that

* Move the industry in the direction of broad use of RESTful, FHIR-based services, including services to support query for both documents and discrete data elements
* Simple query of a known external entity for a document containing an identified patient’s information

They also recommended that short term efforts should focus on specific improvements  to facilitate query for, and selective retrieval of, a range of clinically useful CCDA documents, including but not limited to implementation specifications to support “on demand” retrieval of a simple current summary (problems, allergies/intolerances, current medications, recent labs, etc.), and specifications for a complete longitudinal summary, in addition to the current encounter-by-encounter documents.

Finally, they voiced strong support of efforts to accelerate development of FHIR-based services and FHIR profiles, consistent with recommendations of the JASON Task Force

Next, Steve Posnack and Mike Lipinski presented the early work on defining the use cases for the data provenance initiative.  They emphasized that no standards have been chosen or evaluated for maturity.   We’re currently in a requirements gather phase.

Next Steve and Mike presented an overview of the 2014 Edition Release 2 EHR Certification Criteria Final Rule.

The press has widely reported that ONC abandoned the 2015 rule, when in fact, they simply changed the nomenclature to name rules based on the year they are finalized.   This new rule offers a very reasonable balance of optional criteria that fix previous certification problems such as the inability for HIEs to certify transport only capabilities.

The NCPDP Real Time Benefit Check Analysis Task Group provided an overview of their efforts to bring cost and benefits information for pharmaceuticals to all stakeholders - payers, providers, and patients - based on the use of common data elements and data sources.

Finally, David McCallie presented a brilliant overview of the JASON Task Force review of the JASON Report.

The key takeaway - the general conclusions of the JASON report, which lack operational workflow details, was turned into a set of concrete recommendations very similar to those of the NwHIN Power Team - FHIR query/response for discrete data elements using RESTful transport and OAuth.

I look forward to the October 15 joint meeting of the Policy and Standards Committees in which we will try to move forward the agenda for the next year, hopefully embracing some of the principles discussed today.

An Alternative Proposal for Certification

Some have suggested that my comments over the past few months about the Meaningful Use program, MACRA/MIPS, and Certification imply that we should just give up - throw out the baby with the bath water.

That’s not what I’ve written.

Here’s a clarification.

I believe MACRA/MIPS is the right trajectory - create a set of desirable policy outcomes, then enable clinicians to choose technology, quality measures, and process improvements that are relevant to their practice.

Although the current MACRA formula is overly complex, it’s the right idea and I’m confident that CMS will revise the notice of proposed rulemaking appropriately.    My metric for MACRA’s success is simple - can a clinician keep three goals in mind while seeing a patient and be rewarded if successful i.e.

Ensure care is delivered in the most appropriate location in the community (urgent care, home care, rural hospital)
Focus on wellness/prevention
Avoid redundant and unnecessary testing, medications, and procedures

My issue is that MACRA currently “inherits” the flawed 2015 Certification Rule that is a kitchen sink of immature standards and a black hole for developers.   Overly zealous regulatory ambition resulted in a Rule that has basically stopped industry innovation for 24-36 months since it has listed every use case for every purpose including those unrelated to Meaningful Use and MACRA.   For vendors, every “OR” means an “AND” - developers must implement everything in the Rule because some stakeholder will demand every transaction in the regulation.   There was little curation in the Rule and most of the HIT Standards Committee recommendations to limit scope were ignored.

Here’s my recommendation for the path forward.   When the MACRA/MIPS rule is finalized it needs to reduce or eliminate dependency on the 2015 Certification Rule.  I realize that is highly unlikely because the Obama administration is drawing to a close and as of June 2016, there was not enough time for clearance processes to consider any major changes in regulations.   However, the entire HIT ecosystem is begging CMS to realize that the 2015 Certification Rule is mostly burden without benefit  - it paralyzes the industry for years without increasing interoperability.   Maybe subregulatory guidance can help diminish the role of the 2015 Certification Rule in MACRA/MIPS if regulatory change is impossible.

I’ve said this many times before, but here it is again for clarity.    There are 3 kinds of interoperability - push, pull and view.

To push data from one place to another you need a directory of endpoints (could be a provider, patient, payer, quality registry, or clinical trial database), a means (technical or policy) to trust those endpoints, and  a transmission standard to send data to an endpoint.    The right approach is to use a FHIR-based query/response for endpoint addresses, a private industry enabler for trust (such as DirectTrust, Surescripts, Commonwell etc) and a RESTful approach to push data from point to point, although the Direct protocol will suffice, given the regulatory and political history of the past 5 years.   Remember, Direct was a political compromise.  REST was always the desired technical solution.

To pull data from one place to another you need a master patient index/record locator service, a consent registry, and a query/response transaction for the data.    The right approach is to use a FHIR query/response for the master patient index/record locator service, and a FHIR query/response to request the records.   Consent can be handled in policy, technology or both.

To view data from one EHR in another EHR you need a means to identify the patient (probabilistic matching based on name/gender/data of birth or a national healthcare identifier).   You need shared authentication and authorization of trust such as OAUTH2/OpenID and a means of calling a remote viewer using a URL (a RESTful approach)

If I were King for a day, I would require certification of only 5 things

a.  Use of OAUTH2/OpenID to demonstrate an organization is a trusted exchange partner
b.  Use of a FHIR-based query to request the electronic endpoint address for a push transaction.
c.  Use of  a RESTful approach to push data to an endpoint
d.  Use of a FHIR-based query to request an enumeration of a patient’s record locations
e.  Use of a FHIR-based query to exchange the actual record (a common data set of key elements using the best available vocabulary standards)

We should limit certification to production testing of an EHR’s ability to do those 5 things.  The result would be seamless interoperability controlled by providers and patients, empowered by the vendors.

Developers would then return their programming resources to innovation and meeting their customer needs.

If Brexit taught us anything, it’s that over regulation leads to a demand for relief.

Pythagoras' Theorem has 24 words

Archimedes’ Principle has 67 words

The Ten Commandments has 179 words

The US Declaration of Independence has 1300 words

As a comparison, the 2015 Certification Rule document has 166,733 words.

As I’ve said in an earlier post, we need to step back and ask what we’ve done to ourselves.  We can be thoughtful and incremental about addressing regulatory zeal and we should start by eliminating the concept of Certification as it exists, replacing it with only 5 criteria that are easy to understand and measure.

Looking Forward in 2015

As an eternal optimist, I always look forward to the year ahead and forget the bruises of the year that has passed.

What innovations can we expect in 2015?

In previous posts, I’ve discussed the emergence of FHIR to support standardized query/response APIs for EHRs.  I’ve discussed the “post EHR era”  and the rise of new workflow tools.  I’ve emphasized the importance of social, mobile, analytics and cloud.

How is all of this going to come together in 2015?  

Let me illustrate three examples from recent discussions with industry leaders.

1.  Radiology Clinical Decision Support  - The 2014 Sustainable Growth Rate bill contained completely unrelated mandates for radiology ordering clinical decision support:

(3) MECHANISMS FOR CONSULTATION WITH APPLICABLE APPROPRIATE USE CRITERIA.—
(A) IDENTIFICATION OF MECHANISMS TO CONSULT WITH
APPLICABLE APPROPRIATE USE CRITERIA.—
(i) IN GENERAL.—The Secretary shall specify qualified clinical decision support mechanisms that could be used by ordering professionals to consult with applicable appropriate use criteria for applicable imaging services.
(ii) CONSULTATION.—The Secretary shall consult with physicians, practitioners, health care technology experts, and other stakeholders in specifying mechanisms under this paragraph.
(iii) INCLUSION OF CERTAIN MECHANISMS.—Mechanisms specified under this paragraph may include any
or all of the following that meet the requirements described in subparagraph (B)(ii):
(I) Use of clinical decision support modules in certified EHR technology (as defined in section 1848(o)(4)).
(II) Use of private sector clinical decision support mechanisms that are independent from certified EHR technology, which may include use of clinical decision support mechanisms available from medical specialty organizations.
(III) Use of a clinical decision support mechanism established by the Secretary.

(B) QUALIFIED CLINICAL DECISION SUPPORT MECHANISMS.—
(i) IN GENERAL.—For purposes of this subsection, a qualified clinical decision support mechanism is a mechanism that the Secretary determines meets the requirements described in clause (ii).
(ii) REQUIREMENTS.—The requirements described in this clause are the following:
(I) The mechanism makes available to the ordering professional applicable appropriate use criteria specified under paragraph (2) and the supporting documentation for the applicable imaging service ordered.
(II) In the case where there is more than one applicable appropriate use criterion specified under such paragraph for an applicable imaging service, the mechanism indicates the criteria that it uses for the service.
(III) The mechanism determines the extent to which an applicable imaging service ordered is consistent with the applicable appropriate use criteria so specified.
(IV) The mechanism generates and provides to the ordering professional a certification or documentation
that documents that the qualified clinical decision support mechanism was consulted by the ordering professional.
(V) The mechanism is updated on a timely basis to reflect revisions to the specification of applicable appropriate use criteria under such paragraph.
(VI) The mechanism meets privacy and security standards under applicable provisions of law.
(VII) The mechanism performs such other functions as specified by the Secretary, which may include a requirement to provide aggregate feedback to the ordering professional.

Current EHRs do not support these requirements.   However, as I wrote about previously, Decision Support Service Providers or third party apps would nicely complement existing EHR ordering features.  However, these services must be integrated into EHR workflow or if separate, offer the convenience of a smartphone user experience.

Cloud or app, the necessary functionality to integrate innovative decision support with an existing EHR would be empowered by FHIR.

2.  Closed loop handoff management

Existing EHRs are suitable for managing individual patients during an individual encounter.  Handoffs such as referral management, care management and integration with post acute providers is still clunky.    FHIR based APIs could enable third party dashboards and workflow engines to ensure referrals are pre-authorized, appointments are kept, and lab results are followed up on.  Just as with novel clinical decision support, I see closed loop handoff management as complementary to existing EHRs and could be offered in either cloud or app formats.

3.  Patient Generated Healthcare Data

As Eric Topol recently posted,  the era of the shared medical record (not an EHR/PHR arbitrary division) is upon us with patients having fluid access to their data for download/view/transmit.   Also devices in the home such as glucometers, FEV1 monitors, pulse ox, scales, and blood pressure cuffs will provide important data to manage patient wellness.   Getting such data into EHRs will require an API and FHIR is the logical bridge between cloud/app sources of patient generated data and EHRs.

In 2015, we’ll have the second FHIR Draft Standard for trial use, a single OAuth implementation guide and early adopters opening their EHRs for a new generation of cloud services and apps.   Direct and CCDA will co-exist for a few years, but eventually, simple JSON-based APIs using REST will eliminate the need for Direct.

Yes, 2015 will bring the Meaningful Use Stage 3 notice of proposed rule making, the ONC 10 year interoperability roadmap and the federal HIT Strategic plan, all of which are important.

But the real quantum leap will be the private sector’s efforts, leveraging FHIR to bring clinicians value-added services and apps (time savings, quality improvement, and efficiency gains) that EHRs have not delivered on their own.

Reflections on the US HIT Policy Trajectory

I’m in China this week, meeting with government, academia, and industry leaders in Guangzhou, Shenzhen,  Beijing, Shanghai,  and Suzhou.    The twelve hour time difference means that I can work a day in China, followed by a day in Boston.    For the next 7 days, I’ll truly be living on both sides of the planet.

I recently delivered this policy update about the key developments in healthcare IT policy and sentiment over the past 90 days.

I’ve not written a specific summary of the recently released Quality Patient Program proposed rule which provides the detailed regulatory guidance for implementation of MACRA/MIPS, but here’s the excellent 26 page synopsis created by CMS which provides an overview of the 1058 page rule.

In general, it has many positive provisions.

The industry is welcoming the delays and accommodations it includes, especially the use of 2014 certified records for the 2018 year and the small practice exemptions which recognize the technologies/people/processed needed to succeed under MACRA/MIPS could overwhelm independent clinicians.

The Senate replacement for the Affordable Care Act continues to be debated and there is concern that loss of medicaid dollars may eliminate funding streams that supported healthcare IT.   It’s too early to tell where the ACA repeal/replace activity will converge.

What can we say about the IT policy direction of the US right now?

1. There seems to be great consensus that all stakeholders need to focus on enhancing interoperability technology and policy in support of care coordination, population health, precision medicine, patient/family engagement, and research.  

2.  There is also a consensus that usability of the IT tools in the marketplace needs to be enhanced.   Although the major EHR vendors are working on usability improvements, I believe the greatest agility will come from startup community via apps that get/put data with EHRs using APIs based on evolving FHIR standards.    Here’s my sense of each vendor’s approach

Epic - will support open source FHIR APIs at no cost for the use cases prioritized by the Argonaut working group and HL7.  Will also support proprietary Epic APIs for Epic licensees.

Cerner - similar to Epic with additional SMART on FHIR support

Meditech - will support open source FHIR APIs and give encourage developers to work with customers to leverage the SQL-based Meditech data repository at each customer site.

Athena - will support open source FHIR APIs at no cost but give much more sophisticated workflow integration through the more disruption please program, which involves revenue sharing with developers.

eCW - the department of justice settle should lead to additional eCW support for standards based data exchange.  

3.  Many organizations in industry, government, and academic are thinking about patient identity strategies.  It’s too early to know what solutions will predominate but leading contenders are biometrics (fingerprint, image recognition, palm vein geometry etc.), a voluntary national identifier issued by some authority (public or private sector), or some creative software solution such as OAuth/OpenID/Blockchain etc.  In July, I will co-chair a national consensus conference on patient identifiers hosted by the Pew Charitable Trust.   I’m hoping we achieve consensus on a framework that accelerates the availability of such an identifier for multiple purposes.

4.  Several groups are thinking about how best to converge our heterogenous state privacy policies, specifically focusing on  the role of the patient as data steward.   We can radically simplify privacy protection if the patient is the agent by which information is shared.

5.  Finally, there seems to be an overwhelming sentiment that the concept of certification  and prescriptive IT policy should be replaced by an outcomes focus.    Rather than counting the number of Direct messages sent, giving organizations the flexibility to each data using the the most locally appropriate technology but then holding them accountable for a result of that data exchange i.e. reduced readmissions, reduced redundant testing, reduced errors seems to be well aligned with a move to value-based purchasing.

In theory the members of the new Healthcare Information Technology Advisory Standards Committee (which replaces the former Policy and Standards Committees)  will be named in July.    I look forward to hearing about the initial challenges the group will tackle.   I’m hopeful they will choose some of the issues mentioned above.

In several recent lectures, I’ve reinforced my optimism for the future of the healthcare IT ecosystem.   I believe the next few years will be filled with market driven innovation, encouraged by new consumer demand for healthcare process automation and supplemented by low cost, cloud based utility devices such as the machine learning and image recognition APIs offered by Google and Amazon.    It will be a great time for entrepreneurs, providers, and patients, all of whom are fatigued after years of Meaningful Use, ICD10, and accelerating  numbers of quality measures.   As a CIO, I’m looking forward to doing what my customers want me to do instead of being told what I must do.

What is Patient and Family Engagement?

I recently participated in a nationwide (not the United States) healthcare IT planning effort and one recommendation was universal availability of patient portals.    Several reviewers commented that patient portal is a loaded term - it implies that clinicians control the data and patients are given a view into it.   One person said, “that’s so 10 years ago”

BIDMC has been working with patient/family shared medical records, Open Notes and various consumer-facing apps since 1999.      Over that time we've discovered that patients typically do not want raw data, they want something actionable - the tools necessary to assist their navigation through the healthcare process.

A few years ago, Adam Bosworth, the leader of Google Health and later KEAS, met with me to explain his journey with patient and family engagement.  He spent a few million in venture funds to build a website that helped patients understand their lab results.   Patients visited once and never again.   He then spent a few million creating online care plans.  Patients visited once and never again.  He then spent millions creating a social network for healthcare that enabled teams of people to come together to support each other’s wellness.   That worked!

Our challenge is that we do not know precisely what patients want.  It would be hubris for any IT leader to speak for all patients.   We need to try many different technologies and let the patients decide.

My friend e-patient Dave pointed out in a recent post that my comments about downloads sounded very patient unfriendly.   I explained that the context of my comments was a reaction to the Meaningful Use requirement for View/Download/Transmit.    I completely support the notion that patients and families should have fluid access to all their data, but in 2014 when the Meaningful Use Stage 2 regulation was written, it felt too early to dictate just how that should happen and I commented that download and transmit required more thought.

I made the comment that no patient at BIDMC has asked for the CCDA download of their medical record, a raw xml file of data, since there are few tools that make such a download useful.  Patients  do ask for improved healthcare enabled by technologies that turn the data into wisdom.

Now that it’s 2016 and we have more experience, we’re seeing the emergence of apps such as Apple’s Healthkit and CareKit that put the patient in charge of healthcare data downloaded to their phone.    I wrote this about HealthKit's  ability to make View/Download/Transmit truly useful to all.    We’re releasing our first HealthKit/CareKit app and here’s a description of some of the “data spigot” features:

“Every patient has a customized care plan that is seamlessly synced from the electronic medical record via FHIR interfaces.  All outpatient medications are listed and updated in real time when a provider makes a change.  Patients are encouraged to adhere to their prescribed medication regimen and can also track their intake of “as needed” medications.  Providers define a care plan of non-medication activities that are part of a patient’s treatment.  These may include diet, exercise, or special instructions.

An essential part of staying healthy is the plan and thought process laid out in the health care providers’ notes.  All too often these are hidden in the silos of individual electronic health record systems.  BIDMC@home will harness the capabilities of iOS 10 HealthKit Health Records to serve as a secure, patient controlled, shareable database of medical records.  Under the umbrella of the Open Notes initiative pioneered at BIDMC, patients will be able to view and download their notes from BIDMC, transforming their phones into true personalized health records, and giving patients control of how their health data is shared.”

The BIDMC approach is to create application programming interfaces (APIs) using FHIR for structured data, unstructured data, and images that enable an ecosystem of crowdsourced apps to put the data under patient control.     In my discussions with e-patient Dave, he pointed out that FHIR does not yet include every element in the health record.   He's right but we need to pick some standard for information exchange and I believe FHIR is our best hope for data liquidity.    Today it includes the Meaningful Use Common Data Set and with every HL7 ballot its completeness will improve.

If anyone interpreted my comments about downloads to mean that patients don’t want shared medical records, I apologize.   I meant to say that I believe patients want more than raw data - that they want tools that help them more easily interact with the healthcare system.    As BIDMC moves beyond portals to patient controlled apps, we hope to make that happen.

In the meantime, we do make the Meaningful Use downloads available in our patient portal, Patientsite for those who want the CCDA-based XML summaries of each visit.   We also have the tools to create a download of a patient’s longitudinal record in the CCDA XML format upon request.    We’re all on this journey together and just as the early Blackberry was replaced by the modern iPhone, I’m guessing that CCDA view/download/transmit will be replaced by apps that deliver great functionality to patients from APIs for data access.

The Path Forward for Query/Retrieve

In 2009, I wrote about The Genius of the AND  in thinking about the different standards requirements of “Blue Button” versus "transitions of care".    We accepted CCR and CCD for the first stage of Meaningful Use as a means of buying time to allow the CCDA to be more fully defined.

In 2014, we’re faced with a similar issue as we specify query/retrieve standards to “pull” healthcare data from various sources for care coordination, care management, and population health.

At present, the industry has implemented several functional approaches to query/retrieve, each incorporating both open standards and proprietary implementations:

CommonWell
Epic Care Everywhere
Cerner Resonance
eClinicalWorks P2P and eHX
eHealth Exchange/Healtheway
Surescripts
Regional HIEs such as the MassHIWay

Differing standards and architectures are used based on workflow, use cases, and policy constraints.  Some are synchronous and some are asynchronous.  It's too early in the process to declare any of the enabling open standards as either winners or losers.    Rather than regulate an answer (i.e. XCA must be used, FHIR must be used), it is better at this point to embrace functional criteria for query/retrieve capabilities that will enable an ecosystem to develop as the market  evolves.    Adoption will be our metric for success, and we'll be able to reduce optionality over time by evaluating implementation experience.

Interoperability in other industries, taking examples from Google, Amazon, Facebook, Apple, and Alibaba, is based entirely on RESTful, JSON/XML, and OAuth approaches for open APIs that enable and authorize data-level and document-level exchanges.    We are in a transitional period between an older standards profile (IHE XCA) that is complex (particularly for today's agile, multi-platform environment)/does not support data-level open APIs and an emerging standard (FHIR resource definitions & profiles) which is based on currently prevailing architectural and design principles/does support both document- and data-level access.  The dilemma is that this emerging standard requires some focused development attention before it's ready for prime time.  Although healthcare is indeed a bit delayed in its adoption of information technology, its needs are quite similar to those of other industries, so it is not an edge case that requires a different approach.  To help align healthcare with current technology trends, it is critical that we not lock ourselves into an older healthcare-specific standard -- else we will suffer the consequences of higher costs, longer development cycles, and less compatibility with current enterprise and consumer technologies.      Based on everything we know about the work to date in HITSP, HITSC, S&I, SDOs, and HIEs,  the best approach for the future seems to be:

Vocabulary - centralize all vocabulary resources for download/real time retrieval at the value-set level -- curated and provisioned by the NLM's Value Set Authority Center.

Content - both profile-constrained document and discrete data approaches should be supported.  A constrained CCDA based on a small number of templates that limit vocabulary and metadata optionality and are focused on a small number of high value use cases is a reasonable document format for the next 5 years.   An entry-level set of FHIR resource definitions and profiles can be developed in the next 12-24 months as an open API that supports both document-level access to static CCDAs and data-level access.  That is a reasonable discrete data approach for the next 5 years that will serve high-value clinical use cases for the near-term but, more importantly, build a gateway to rich interoperability founded on JSON/XML approaches for the future.

Transport/Security - We should accept both SOAP/SAML and REST(HTTP)/OAuth 2.0 as reasonable approaches for the next 5 years -- though we anticipate a continuing and accelerating decline in support for SOAP/SAML, with a corresponding increase in adoption of HTTP/OAuth, across all IT environments.

Thus, we should allow multiple approaches to enable the marketplace for the next 2 years, while working to constrain CCDA and complete FHIR resource definitions and profile specifications.       in 2017, we'll have enough experience with query/retrieve and adequate standards maturity to begin convergence to fewer standards in a way that still supports the older standards for those who don't want to "rip-and-replace" but also provides a pathway for those who would like to start building on newer standards to carry them further into the future.

We believe that incentives for cross-boundary sharing (e.g. MU incentives, as well as emerging market incentives) will work better to move the industry forward than forcing technical compliance to complex standards.   We should focus on the outcome rather than the process.

Networks require considerable additional work beyond the implementation of particular standards.  With this recommendation, we are encouraging the evolution of multiple robust networks that enable and facilitate query/retrieve, with the expectation that these networks will create appropriate bridging techniques to other networks, in response to incentives and market demands.

What about HIE governance?

HIE is still largely a highly heterogeneous and locally-dispersed regional activity based on local policies, technologies, and use cases.   Forcing a single governance approach in the next 2 years will quash innovation, limit adoption, and negatively misalign incentives.

ONC should have a role in defining outcomes, but not prescribing standards yet, at this critical juncture where some are maturing and fading but the successors haven’t fully emerged yet.  There are active communities effectively developing solutions.  That includes SDOs, broad industry groups, and the actual networks created by CommonWell / HealtheWay / Surescripts.  This is more than some kind of vague “invisible hand of the market”, there is real work happening with responsible players with whom ONC can collaborate.

The Affordable Care Act and new economic incentives are aligning payers, providers, and patients to share data.   These economic incentives are more powerful than meaningful use regulation and should be allowed to shape the standards and governance of HIE for the next 2 years.    In 2017, as the standards have matured, and the marketplace has made implementation choices, the notion of a single national standard for query/retrieve should be revisited.

The Path Forward for Meaningful Use

Below is my assessment of the current Meaningful Use program and a proposal to better serve the needs of stakeholders.  I’m likely going to violate many rules with this post.   First, it’s over 1500 words, which is not ideal for social media.     Second, there are many who will find my conclusions politically unpopular.   I’m not criticizing people, I’m just commenting on ideas.   Finally, many of these topics do not have black and white answers. I hope my suggestions improve upon our current trajectory.

Where We Are

1.   I believe that the Meaningful Use programs have served their purpose.

Stage 1 created a foundation of functionality for everyone.   That was good.   Stage 2 tried to change too much too fast and required an ecosystem of applications and infrastructure that did not exist.   Clinicians struggled to engage patients and exchange data because they could send payloads but there were few who could receive them.    Stage 3 makes many of the same mistakes as Stage 2, trying to do too much too soon. It requires patient accessible Application Programming Interfaces (APIs) without specifying any standards.   It requires sending discharge e-prescriptions although pharmacies cannot widely support the cancel transaction that is essential to discharge medication management workflow.   It requires public health transactions but CMS has no authority to require public health authorities to standardize the way they receive data.  

Clinicians cannot get through a 12 minute visit, enter the necessary Stage 3 data elements, reconcile problems/allergies/medications from multiple institutions, meet the demands of the  Stage 3 clinical quality measures, make eye contact with patients, and deliver safe medical care.  There needs to be a new approach.     The same thing is true about certification.    I believe that early stage certification set a floor on EHR capability that was appropriate.   Certification is NOT good for the next stage of maturity, which will be driven by heterogeneous use cases and dynamic technology evolution.  Certification is now at the point where it threatens usability, interoperability, and EHR quality, while at the same time diverting research and development resources of health IT developers and providers.

2. I believe that volitional Information Blocking does not really exist.

There may be incompetence that feels like blocking but I’ve never encountered a competent organization with a business need blocking the secure exchange of information. I realize that there are folks in Congress who believe that a new crime called Information Blocking necessitates civil/monetary penalties and enforcement.    I have never encountered a Chief Information Blocking Officer at a health IT developer or provider organization.   The barriers are lack of enabling infrastructure, data governance, uniform policies, appropriately constrained standards, and economic incentives.  Focusing on information blocking is a distraction.

3.  I believe we cannot solve every societal problem through regulation.

The layers of requirements in Meaningful Use, the HIPAA Omnibus Rule, the Affordable Care Act, ICD-10 and the Medicare Access & CHIP Reauthorization Act of 2015 (MACRA)  are so complex and confusing that even government experts struggle to understand the implementation details.    Each of the regulations leads to various audits.  My experience is that even the auditors do not understand the regulatory intent and ask for documentation that far exceeds the capabilities of existing technology.   I was recently asked to support a Meaningful Use audit because the auditor wanted proof that a clinician performed a certain task during the reporting period (a report with a time and date stamp was not enough).   Maybe a video of a clinician at a keyboard with a calendar/clock on the wall in the background?

4.  I do not believe that adding numerous structured data elements and new quality measures to existing software creates disruptive innovation.  We need a business imperative for change and innovation based on the needs of customers.

I’ve already seen the rise of the Care Management Medical Record at our ACO, enabling care managers to examine data from all the EHRs in the community and identify gaps in care/variance from expected protocols.   Patient Relationship Management applications are in development, making healthcare more like other service industries.   None of this is driven by prescriptive regulation.

5.   I believe that health IT developers have already committed to piloting and developing Application Program Interfaces (APIs).

Creating regulation before there is any industry experience as to what works makes little sense.   Government can help with issues such as data governance principles, rationalizing  privacy policy,  and coordinating federal agencies but should not specify workflow or business process.  

What We Should Do

1.  Replace the Meaningful Use program with Alternative Payment Models and Merit-based Incentive Payments as part of MACRA.

Stage 2 and Stage 3 will not improve outcomes.   If alternative payment models offer compelling reimbursement for health and wellness, then clinicians and hospitals will adopt products and change behavior to achieve that goal.

2.  Replace certification with enabling infrastructure.

To accelerate interoperability we need a national provider directory, a master patient index/relationship locator service, a consent service, a certificate management service, and test beds for developers to exercise these services.   Today in Massachusetts we exchange over 3,000,000 patient records per month among 500 organizations because we created such enabling infrastructure backed by data governance (common policies and agreements).   Certification will not accelerate interoperability.

3.  Consider evolving the role of ONC to become a focused policy shop (supported by advisory committees) with a narrowed scope such as identifying ways to reduce errors, improve safety, enhance quality, accelerate interoperability, and meet the needs of diverse populations.

It could also provide transparency and true coordination for actions of government, communicating the IT efforts of agencies including DOD/VA.   ONC has become distracted by grant making, political agendas (see “information blocking” above), and expansive certification ambition.  It's time to narrow the scope and enhance the effectiveness of this important agency.

4.  Stop considering health IT developers and providers as the enemy.

Some believe health IT developers are responsible for creating information silos or resisting interoperability.   Some believe clinicians are lazy or greedy, requiring  government mandates to become patient-centric.   I’m sure there are exceptions, but in general, both are myths.   I’ve said that there are a few effective ways to influence clinician behavior - align incentives, give them a better work/life balance and help them avoid public humiliation (malpractice assertions, poor quality scores, negative Yelp reviews).   A partnership of government, payers, providers, patients, and health IT developers working together to achieve common goals is possible if there are mutually aligned incentives, such as the ideas embodied in value-based purchasing/MACRA.

5.  Focus our efforts on a few things that really matter.

The Federal Interoperability Roadmap has 117 goals.    The certification program has so many objectives that it takes a few hours just to read them all (summary slide below).

How about a laser-like focus on interoperability that includes just 3 objectives?

-ability to use FHIR to read a provider directory (could be hosted by government such as CMS as part of the national provider identifier or the private sector such as Surescripts, DirectTrust, or an HIE) and send a Direct message to that provider.

-ability to use FHIR/OAuth to read a relationship locator service (could be hosted by government or the private sector such as Surescripts, Commonwell, Sequoia, or HIE) and perform a query/response of the MU Common Data Set using a FHIR API.

-ability for a patient to download the MU Common Data Set using an app (that is curated/reviewed to ensure security and data integrity) using FHIR/OAuth or appropriate variants of OAuth such as HEART.   Several folks have contacted me to discuss the real purpose behind the consumer API requirement in the ONC and CMS rules.  Some suggest it was motivated by special interests who want to monetize patient submitted data.   Some suggest that it is an enabler for future provider to provider transactions.   Some say it is the best government lever to motivate the industry to move from messaging to APIs.    I’m not sure which interpretation is correct, but it is certainly true that providing data to the patient should be one of the focuses of interoperability.

Since MACRA will base payment on wellness which requires care coordination, providers will demand appropriate interoperability features when buying an EHR product.     Additionally, an independent third party such as KLAS could publish unbiased statistics about the actual experience of interoperability by speaking with hundreds of clinicians and staff.    Recently all the major health IT developers agreed to have their interoperability measured by KLAS via customer interviews using this questionnaire. 

I’m really trying to be helpful here and incorporate the overwhelming feedback I’ve heard from stakeholders.    More Meaningful Use and Certification criteria are not the answer.    Paying for outcomes that encourage government, payers, providers, patients and health IT developers to work together, instead of being adversaries, is the path forward.

A Followup on the MU Path Forward

After last week’s post about my suggested path forward for Meaningful Use,  I received a large number of comments.   I thought it would be useful to summarize them and clarify some of my opinions.

In general, 95% of commenters agreed that CMS should pivot the concept of Meaningful Use functional requirements into pay for performance rewards for achieving outcomes via MACRA.

Several commenters pointed out that the MU program has different approaches for Medicaid providers and Medicare providers.       Medicaid funding is available to help providers purchase technology.  Medicare providers received stimulus in the past and now are entering the penalty phase for not attesting to Meaningful Use.  I did not mean to suggest that Medicaid funding should cease before EHRs are fully deployed in Medicaid provider locations.    My suggestions referred to the Medicare programs and penalties for not implementing prescriptive functional requirements.

I was asked to clarify my thoughts about certification.    Today’s certification program includes onerous requirements that consume vast amounts of resources for items not related to interoperability.   If we focus on three goals (provider to provider push,  provider to provider pull, and patient pull), then a streamlined certification program validating those three functions would make sense.   Just as a DVD player includes a sticker guaranteeing “Blu-Ray” compliance, I can imagine a streamlined certification program that issues “stickers” for each of the three interoperability goals, reassuring clinicians that the health information exchange claimed is fully functional in the products they buy.

I was asked if I was criticizing CMS or ONC work.    I’m really not criticizing anyone.   I’m suggesting that the work done in the past was foundational, but the future requires a different approach - outcomes based incentives.    I’m confident that CMS and ONC staff can evolve existing programs into this new approach.

Finally, some have advocated for a transitional approach along the road to FHIR, since existing standards such as IHE XDS/XUA are already in the marketplace.     I realize that we cannot go from cars to jet planes without a few intermediate steps.  However, we have to proceed very carefully because for vendors, every OR becomes an AND.   If we say that you could use IHE XDS or FHIR, we will run into impedance mismatches. Not only will vendors have to implement every option, they will have to implement step up/step down conversions between organizations that use different options.   In general, optionality is the greatest impediment to interoperability.      If the entertainment industry decided that laser disc and Blu-Ray should be used simultaneously, our home systems would become very complex and hard to maintain.   While I understand that some optionality could be offered during a transition period, I am advocating for a move to FHIR/OAuth as the ONLY approach, with minimal optionality, as quickly as is practical.

I look forward to the continued comments - let’s keep the dialog going!

How Does a Platform Reduce Barriers to Innovation?

One of our Mayo Clinic Platform team, Emily Wampfler, recently forwarded me an overview of MIT's Platform conference

Read the Barclay's piece.   It notes that 55,000 people changed focus from product support to a platform service line orientation, remarkably enhancing business opportunities.

Few organizations in healthcare have created a Platform which connects data producers and consumers, standardizing security, enhancing reliability and accelerating agility.     What is the urgency to embrace a Platform approach to healthcare?   

 I believe a Platform strategy is the best way to reduce barriers to innovation.   What specific barriers?    I have my own opinions but also asked colleagues like Dr. Craig Monsen, CMIO of Atrius.   Our examples are not related to any single institution we've worked at (Atrius, BIDMC or Mayo) but are drawn from multiple decades of experience in healthcare.

Operational
Innovation efforts compete with staff time required for day to day activities
Innovation efforts may disrupt efforts to standardize work in an organization
Innovation efforts may not be aligned with the immediate goals and priorities of leadership

Technical
Innovation efforts may require data standards that are emerging or not yet implemented
Innovation efforts may require clarification of data use rights 
Innovation efforts may require novel IT infrastructure

Business
Innovation efforts may require significant time investment from IT, Information Security, Compliance and Legal
Innovation efforts may require new policymaking about intellectual property ownership
Innovation efforts may require clarity about unrelated business income for a 501c(3) public charity
Innovation efforts may require finalization of slowly evolving regulations (ONC information blocking rule, CMS interoperability rule)

 Legal
Innovation efforts may require re-evaluating security, privacy, conflict of interest and consent policy
Innovation efforts may require clarification about what projects are operations(as in HIPAA Treatment, Payment, Operations) versus research

What can a platform do to mitigate/eliminate these barriers?

 If senior management (Executives, Board) broadly communicates that a Platform effort will require short term additional work but the resulting standardization of technology, process, and people will simplify future work, then the organization will tolerate the extra effort and disruption.    I think of it like building a house.    Anyone who has ever done a major construction project knows about the dust, delays, and inconvenience of building.   However, when the project is done, there are decades of enjoyment to follow.

 Although data standards constantly evolve, a Platform creates a single place to get/put data using whatever technologies exist today while permitting transition to what's next when it's available.    Although EHR data extraction today may require third party tools or proprietary work arounds, once the data is flowing to a Platform then collaborators can access data via a single point of authorization and authentication  without any dependency on the EHR itself.   I've used this technique to make data available to innovators using FHIR long before FHIR was part of EHRs.   The Platform can embrace emerging standards like FHIR R4 long before such standards are native to the EHR.

 Data Use rights are a key issue and require a consensus of internal/external stakeholders.   I will detail some of the issues about Ethical Uses of data in my next post.   A Platform which serves as a single point of data input/output enables the consistent enforcement of data use policy.

 I recently worked on a project that required a novel business relationship between a 501c(3) Public Charity and an existing EHR vendor.   The business people agreed it would be unrelated business income and would be taxed.    Once a template was developed for unrelated business income arrangements, it was no longer a barrier.  Similarly, intellectual property rights covering developments made using data from a Platform require a standardized policy.   For example, is de-identified data made available for innovation at low cost with the notion that derivative intellectual property creates an ongoing revenue stream OR is the data cost initally high with the notion that derivative intellectual property is unencumbered?  A platform enables easy monitoring and execution of such arrangements

 In sum, a Platform can be an organizing framework for operational, technical, business, and legal stakeholders to create a set of standardized, templated use case variants without having to re-negotiate every new innovation project or collaboration.   In my experience, without a single enterprise approach (call it a single front door) to connecting data producers and consumers, there is unlikely to be innovation agility in healthcare.

In the first 100 days at Mayo, many stakeholders will weigh in on these issues.     I'll report on lessons learned along the way.

The January HIT Standards Committee

The January HIT Standards Committee focused on two important topics, the future of the Standards and Interoperability (S&I) Framework and the xtandards needed for provenance i.e. who generated the data and I can I trust it?

Stan Huff and Arien Malec presented the process that the Standards & Interoperability Task Force  will use to evaluate the best way to harmonize standards in the future.   Typically Standards Development Organizations (SDOs) create and curate standards but sometimes there is a need to select among competing standards or combine the work of multiple SDOs into an implementation guide.   The Healthcare IT Standards Panel (HITSP) did this kind of harmonization.   When HITSP was  sunsetted during the transition from the Bush to the Obama administration, the S&I Framework was created to fill the harmonization role, since the Healthcare IT Standards Committee (HITSC) served in advisory capacity to ONC, not doing the granular work of implementation guide writing.     Questions to be asked  by the Task Force include:

Is there a continued need for the S&I Framework (or an equivalent process) to advance standards and implementation specification development?

The task force will evaluate the “What” (what should be done) and the “How” (by whom, in what forum, with what processes)

We all look forward to their work.

Lisa Gallagher presented the work of the Data Provenance Task Force.  Their  remarkable set of recommendations that were applauded by all.

The Task Force recommended that the Data Provenance Initiative should focus on the following:

Where did the data come from? (“source provenance”)
Has it been changed?
Can I trust the data?

The Task Force recommended that these questions be answered using 4 transaction types, in the following order of priority (although they are roughly equal in priority)

*With exchange of data between EHRs
*At the point of origin/data creation in an EHR or HIE
*With the transfer of data from a Patient Controlled Device (PCD) or a Personal Health Record (PHR) to an EHR system
*At the point of data creation in a PCD or PHR

They recommended that the CCDA and FHIR be the target technologies for provenance standards taking into account existing work including

*CDA/C-CDA Provenance
*FHIR Provence Project
*Privacy on FHIR Projects

Finally, they recommended that for health information exchange, both push (Direct) and pull (SOAP/REST query/response), that the provenance of the content should be lossless ie. there is data integrity from the point of origin to the point of use.

Much discussion followed and the Committee agreed that we needed to define lossless i.e. what if the data is mapped into a different vocabulary or different format?   Arien Malec agreed to prepare a straw man definition of lossless.

The committee voted to support these recommendations and formally deliver them to ONC.

The next few months will be very busy for the HIT Standards Committee as we review the Federal HIT Stategic Plan, the Ten Year Interoperability Roadmap, and the Meaningful Use Stage 3 Notice of Proposed Rulemaking.    Exciting times ahead.

Enabling Nationwide Interoperability

Today’s post is co-written by Micky Tripathi, CEO of the Massachusetts eHealth Collaborative, and me.

It’s been over 10 years since ONC head David Brailer and HHS Secretary Tommy Thompson published the “The Decade of Health Information Technology”, one of the goals of which was to create a “a new network to link health records nationwide.”  Since the beginning, government planners have advanced the notion of a national-level network, at first suggesting a single “national health information network” architecture, which was later modified to be a “nationwide health information network” built on a foundation of federally-subsidized regional health information organizations (RHIOs) working together across the country.  More recently, the ONC Interoperability Roadmap, recognizing that the building blocks of universal interoperability could not be so neatly erected, leans on the idea of “coordinated governance” of networks.

While these frameworks have paid homage to the concept of nationwide network as a “network of networks”, we have yet to crisply define the stitching needed to form this nationwide network quilt.  This issue hasn’t been so pressing up until now because there were relatively few networks – the “last mile” problem was the bigger concern.  Network formation is evolving rapidly, however, which has made more pressing the question of what it means to connect networks in a uniform way.

We believe that there are five key interoperability transactions that need to be operationalized across networks in order to achieve the goal of nationwide interoperability.  Those are:

1.  Patient matching/identification

2.   Provider directory supported by a FHIR query/response transaction

3.   Constrained CCDA payload with little to no optionality

4.  Data-level FHIR API for MU common data elements and a document-level FHIR API for a CCDA supported by a standard schema and controlled vocabularies

5.  OAuth/OpenID Trust fabric supported by appropriate HIPAA/state/local policies for consent

There are obviously many other interoperability functions that have value in the market, but we believe that those are best left to individual networks to provide within their networks as their customers and stakeholders see fit and are willing to pay for and enable.  This is exactly how other network-based industries have developed.  Wireless connections work seamlessly across networks even though within their networks they don’t all use the same standards or offer the same functions (e.g., Verizon users can do more with each other than they can with AT&T users, for example, which is also true for iphone users).

We obviously made some decisions about what to relegate to within network.  For example, what about a record locator service?  We do appreciate the value that record location can provide, but given the variation in network architectures that exists today and the policy complexity involved, we see this as a capability that is best left for the future.  We also caution against letting the perfect be the enemy of the good.  It’s important that we begin with achievable, practical steps and grow from there.

How would this be accomplished?  Network development is now at the point where the private sector – a small group of existing networks such as CommonWell, Epic CareEverywhere, Surescripts, DirectTrust, the eHealth Exchange – should assemble to roll up their sleeves and agree on practical, federated solutions to these five issues.  And if the experiences of other network industries is any guide, once a critical mass of networks launches such functions according to open industry standards, the rest of the market will soon follow.

In our various speaking events at HIMSS this year, you’ll hear a call to action from  Micky and me to move this agenda forward.

A Dispatch from HIMSS

Unfortunately, I was unable to attend HIMSS this year because a special request from Andy Grove, the former CEO of Intel.  He asked me to serve with Roni Zeiger (Smart Patients, Google Health) and John Mattison (CMIO of Kaiser) as co-presenters for the first annual Marc Shuman Anti-Medical School Lecture in San Francisco, sponsored by the Grove Foundation.   When Andy calls, you listen.

My second in command at BIDMC, Manu Tandon, attended HIMSS on my behalf and sent the following analysis of the key themes he experienced.

"Interoperability is big at HIMSS in 2015.    The challenge of patient identification and finding the location of patient records are important informatics problems to solve.

I spoke to Surescripts and the CommonWell Health Alliance.   Surescripts is piloting with 3 vendors and CommonWell is embraced by many vendors.  The participating EHR system can send  a patient match request and if matched ask for list of documents available and then send a request to get documents (CCD, lab reports etc). I asked about consent – they don’t plan on storing that at the HIE level and depend on the requesting systems.  I asked Surescripts about a charge model. They are developing it.  It may be transaction based for each document received. Their current data set for 230 million patients is prescription oriented.  They would like to collect Admit/Discharge/Transfer (ADT) transactions and documents to enhance their model. They will also support the direct protocol transport functionality to send/receive ADTs.

I  spoke to Epic’s Judy Faulkner about this. She seemed supportive of the idea of a record locator service . She said they have been working on this for a year. Her view was that Surescripts has the most covered lives at the moment.  When I asked about charges she said that Epic will pass on Surescripts fees to the providers.  Epic is also still working on the consent issues.

Also, Epic is focusing on patient management solutions. They have a patient facing mobile based app for appointment scheduling, video visits, personal health device data integration and paying bills via credit cards. They also have upgraded the patient facing portal and have a bedside solution for patients to see their upcoming procedures and to communicate with their care team.

Meanwhile, over at the CommonWell booth, there was a promising demo using the CommonWell broker (Relay Health) to route FHIR transactions among three CommonWell member vendors in a pilot project that demonstrated the power of using FHIR to move discrete data instead of CCDAs.  These vendors (Cerner, McKesson, and AthenaHealth) showed near-real-time propagation of medication records and problem lists in the FHIR demo.

I can’t tell you how many vendors have the story line 'just give us your claims and financials data and we have the prettiest dashboards to show back to you'.  Several established vendors offer an Extract/Transform/Load/data model tool to collect data from administrative, financial and clinical systems to create a warehouse. Price point is $3-4 M to implement. Some smaller companies are offering services that sit on the wire and track HL7 transactions to build analytics in real time. Many are focusing on Population health. Some have shiny dashboards. Some can pull data from devices  (scales, glucometers, BP monitor) and feed analytics engines.

They is a entire area devoted to interoperability demonstrations.  There are many use cases of data transfer based on point to point exchange.  Will be interesting to study that from a scalability perspective.

I found a vendor that offers 'Enterprise Output Management'  managing printers (who can use color, follow me printing, if one goes down, divert jobs to another etc).

One vendor would like every patient and doctor to wear a tag so they can show who is where at any time.  The network team will love all that traffic.

HIMSS tracks who is in the midst of replacing their major clinical systems etc. about 170 projects going on in New England according to them.

A very busy time for CIOs."

The August HIT Standards Committee

On August 22nd, the HIT Standards Committee held it's 50th meeting.   We began this milestone meeting by thinking Farzad Mostashari for his national service via a formal proclamation highlighting his accomplishments.  Richly deserved.

Liz Johnson and Carol Bean then presented an Implementation Workgroup update, describing the findings from the Implementation/Usability hearing on July 23rd and presenting test scenarios which will hopefully replace/augment the existing certification scripts.  

They key idea is that scenarios would mirror real clinical workflow from registration to evaluation to transition of care, using the same data and building upon each incremental data entry step.   Such an approach not only reduces the burden of certification but also ensures the EHR is more than disconnected functions built to satisfy disconnect certification criteria.   In effect, scenarios demonstrate the usability of integrated functionality.   I'm also hoping that these scenarios remove some of the certification demonstrations are not part of attestation workflow.    In my view, certification should only include the minimum functionality clinicians need to support attestation and nothing more.   As I posted in my blog yesterday, creating too many regulatory demands can stifle innovation.

Next, Dixie Baker presented an NwHIN Power Team Update finalizing the recommendations for future transport standards.   She reviewed the work of Blue Button Plus, HL7's Fast Healthcare Interoperability Resources (FHIR), and the S&I Framework's RESTful Health Exchange (RHEx) to identify industry trends and emerging standards.   The team concluded that combination of RESTful transport supported by a specific implementation guide and supplemented with OAuth2/OpenID for authentication holds great promise as a simpler to implement approach than currently required in Meaningful Use.   The team also concluded that FHIR has many appealing simplifications as a content standard.      The Standards Committee recommended pilots and once we have real world experience with the combination of RHEx/OAuth2/OpenID/FHIR we should seriously consider their incorporating into future stages of Meaningful Use.

Finally, Lauren Thompson and Jodi Daniel provided an ONC update, highlighting work to accelerate HIE, patient/family engagement, and safety.

At our September meeting we'll present initial recommendations for image exchange and early thinking about how to represent advance directives in EHRs.

Making progress.

The JASON Report

On 4/09/2014, AHRQ released the JASON report, facilitated by Mitre.   JASON is an independent group of scientists who advise the United States government on matters of science and technology.

The intent of the report is to make recommendations for a new healthcare IT architecture to accelerate interoperability.

When reading the report, it’s best to focus on the big ideas and ask how those concepts can be aligned with a a stepwise multi-year approach to address technology and policy challenges.

1.  Like the PCAST report, which heavily inspired the JASON report, there is a stated need for a common mark-up language for healthcare including controlled vocabularies.    Today, that language is the CCDA and the vocabularies are available from the National Library of Medicine’s Value Set Authority Center.   In the next few years, it’s likely that  Fast Health Interoperable Resources (FHIR) will become the new markup language, given that it is simpler to implement and parse than the existing CCDA.   The work to refine FHIR is already in progress at HL7 and the HIT Standards Committee.   The report distinguishes between the medical “chart” or “record” data verses structured data storage.      There is valuable research work in progress and emerging products to leverage natural language processing, turning unstructured notes into actionable knowledge.

2.  The report notes the importance of application programming interfaces (APIs) to support architectures that are agnostic as to the type, scale, platform, and storage location of the data.   In Meaningful Use Stage 2, the interoperability focus is on push models - sending data from one EHR to another EHR as structured, importable information.   I agree that our next areas of focus should be query/response.  API is  a very general term and Massachusetts  (MassHIWay) has created the necessary RESTful and SOAP approaches to support populating a master patient index, consent/privacy preferences, and real time query of healthcare data.  The MassHIWay is very well aligned with the first phase architecture that Jason recommends as a good starting point to accommodate real-world constraints, per the graphic below.

3.  The report suggests that all data be encrypted at rest and in motion.   Meaningful Use already requires encryption of data in motion.   HIPAA requires compensating controls for data at rest, one of which is encryption of client devices.

4.  The report describes separation of key management from data management.   The Direct protocol, which is a required part of Meaningful Use Stage 2, implements certificate management to ensure security and data integrity from point of data origin to point of use.   The report describes highly granular consent, enforced with certificates.   That principle is similar to the S&I framework Data Segmentation for Privacy work, which has been codified in HL7 standards.

5.  The report notes that data should be surrounded with corresponding metadata, context, and provenance information.   EHRs typically include time/date stamps, authorship information, and other contextual information with most transactions, so the suggestion is reasonable.

6.  The report suggests that EHR data be represented as discrete data elements (atomic data) with associated metadata.   The Meaningful Use Common Data set for Stage 2 already requires that.

7.  The report  recommends adoption of the “robustness principle”: be liberal in what you accept and conservative in what you send.   The 2015 Notice of Proposed Rulemaking suggests that certification in 2015 include testing of that principle.

8.  The report identifies a need to support clinical trials and clinical research while also protecting patient privacy.    The I2B2 project, which has been further generalized by the ONC QueryHealth project, is a good start.

My implementation suggestions for ONC and the Standards Committee to implement JASON recommendations are summarized as

1.  Evolve CCDA transition of care documents to FHIR
2.  Replace Direct with a RESTful approach for “pushing” records
3.  Adopt a query/response RESTful approach for “pulling” records
4.  Adopt a simple HL7 2.x admit/discharge/transfer message that records patient consent preferences for disclosing data from an institution
5.  Adopt I2B2 to support a learning healthcare system

I want to thank the JASON group for re-emphasizing the importance of the trajectory we’re already on, identifying milestones for success we can use to evaluate our progress.