Panelists:

  • Stanley Crane, CTO, InteliSys Health (moderator)
  • Dan Gottlieb, Technical Lead, SMART Health IT Project, Boston Children's Hospital


  • Vik Kheterpal, MD, Principal, CareEvolution, Inc.


  • Laura Heermann Langford, Chief Operating Officer, Healthcare Services Platform Consortium (HSPC)


  • Janet Campbell, Vice President of Patient Experience, Epic



To participate in the discussion please post a comment below. Comments will be made anonymously, if you would like to be identified or contacted after the event is over, please include your name. Your registration email address can then be used to contact you after the event.

  • No labels

13 Comments

  1. Anonymous

    Remember that FHIR resources are but a new way to specify data containment (containers), not really a lot different than HL7 v2 or NCPDP messages or HL7 CDA/CCD documents.  That said, it's really cool that it also behaves as an API.

  2. Anonymous

    Work flow may be enabled by an orchestration of FHIR APIs in prescribed and predictable sequences.

  3. Anonymous

    As the industry improves workflow interoperability, how do you balance just-in-time CDS with the very real alert fatigue clinicians experience?

  4. Anonymous

    The question for platform developers (e.g., EHR systems), is whether they allow read only access or full read/write capabilities (e.g., via FHIR APIs)?

  5. Anonymous

    CommonWell incorporates business & legal interoperability frameworks to govern access to patient data.  How does the SMART Health IT proect support business & legal interoperability?

  6. Anonymous

    An open API will allow an app ecosystem to flourish. CARIN alliance might help here...

  7. Anonymous

    Our challenge in using a number of FHIR test servers and sandboxes is that very few actually support FHIR AuditEvent and Provenance resources, to support assurance requirements for authenticity, audit and accountability.  Note that this is a requirement specified in the FHIR Implementers Safety Checklist (see #9):  http://hl7.org/fhir/safety.html

  8. Anonymous

    Our EHR vendor exposes a FHIR API which our third-party integration partners are thrilled about, however, the EHR vendor offers no filtering via the API.  For example a payer interface may only be allowed to access those patients attributed to the payer's population.  This would seem to expose a large PHI issue if the payer is left to their own filtering.  Any technical suggestions to lead our EHR to filter the API?

    1. Anonymous

      find a better vendor

    2. Anonymous

      FHIR based API specifications require the same amount of specificity and clarity as implementation guides/profiles based on other standards.  Therefore, if there is need for a more filtered data set that should be consistently available across platforms, either a new or updated API specification needs to be created and agreed to by the industry so expectations on what data it will or can serve up will be clear to everybody using that vs. another API.

  9. Anonymous

    HIEs have the ability to send an aggregated clinical summary to the patient.  It would help facilitate patient directed exchange if HIEs could be considered as a covered entity and/or allowed to share their information with the patient.

  10. Anonymous

    All these advances in new EHR versions are nice. But, it costs a lot for a provider to move to a newer version which has lot of functions that are listed on these slides. How can a medium or a small provider efficiently move to a newer version without causing a lot of money?

  11. Anonymous

    One of the panelists hit the nail on the head with the fact that API really only liquefies the data.  In order for that data to be useful and trusted downstream we need robust data quality and feedback which are much more difficult to achieve.  We should pick a few prioritized data use cases for API and concentrate on getting those right and of high quality. Trying to do too many use cases at once is much like trying to boil an ocean.