Participants

Notable Achievements

The RSNA Image Share project team, in coordination with the Sync for Science team, developed a set of components to connect current state-of-practice radiology systems (HL7 v2 radiology information system / DICOM3 PACS). These components include the following:

DICOMWeb Broker: A web service for adding DICOM-RS support to legacy PACS. The broker supports translating QIDO-RS and WADO-RS requests to the corresponding C-FIND and C-MOVE transactions to enable legacy PACS applications to participate in the S4S network.

FHIR Broker: A web service that accepts FHIR RESTful calls on behalf of an EHR and brokers them to DICOMWeb calls to a PACS.

Introspection Service: A web service that assists the FHIR Broker in authenticating research applications’ access to imaging data for a specific patient.

The components were packaged, along with a standalone PACS (DCM4CHEE) populated with a modest amount of test data in a Docker compose file available here: https://github.com/RSNA/s4s-stack. In our track we were able to load the Docker container on a new system and run it successfully.

Screenshots

Discovered issues

Limited participation was the main challenge the track faced. Specifically, the absence of a research application to query for and retrieve imaging studies. The track could potentially also include DICOM3 and DICOM Web-enabled PACS and EHR systems that could use the FHIR broker or integrate its functionality. This initial implementation focused exclusively on finding and retrieving images. Future development should focus on enabling access to imaging reports.

While the track as defined focused on image sharing for research purposes, the same set of transactions could enable access to images across sites for clinical care. We might consider broadening the scope if the track is repeated in future. We might also consider integrating this track into more generally scope tracks using SMART on FHIR to access medical records for clinical care and research.

Next Steps

Create a persistently available hosted version of the component stack. Initially this would simply be an endpoint developers of research applications could query. The next step would be to make available a UI providing the patient perspective of consenting in an EHR portal.

Attachments

Goal

Electronic attachments are a high priority for processing claims and other payer/provider interactions. Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest in experimenting with FHIR-based messaging for exchanging attachments. This track will explore the feasibility of this approach.

Notable Achievements

Started implementing the attachment resources and identified necessary improvements required to finish implementing the specification.

Learned about the enhancements to the Provider Directory resources so we can improve our current FHIR provider directory.

Gained knowledge on several tools that others are using.

Learned what we were supposed put into the sender and receiver when forwarding the Communication and Communication Response.

HealthLX completed the Attachment, Financial Management and Medical Device Tracks. On the Medical Device track, we worked with the track leader to implement an actual use case for which we have a client requesting an implementation by April of this year.

Screenshots

None

Discovered issues

No major issues mostly everything worked cleanly

Would be nice to leverage the track wiki content to start a FHIR Attachments IG.

Track would have benefited from an orientation presentation since some participants did not fully understand what happens at a FHIR Connectathon

Next Steps

It was recommended to create an addition to the Track for Clearinghouse Functions for the next meeting.

Start FHIR Attachments IG work (PSS already in place)

Automated Profiling From Domain Models

Goal

Please limit to one paragraph summary

Participants

Names and Company Names

Logos optional

Notable Achievements

Please limit to one paragraph summary

Screenshots

1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements

Discovered issues

What challenged the group?

What questions did you come away with?

Next Steps

Bulk Data

Care Management and Planning (Care Plan)

Goal

Advance the maturity of FHIR resources for care management (CarePlan, CareTeam, Goal, Condition, and others), the definition of computable clinical protocols (PlanDefinition, ActivityDefinition), and to document industry best practices for improving care coordination using shared care plans. This work will inform the development of more comprehensive implementation guides and profiles for care management based on FHIR Release 3 (STU), which is the primary target for testing in this track. This connectathon track will be coordinated with the Chronic Conditions track at Clinicians on FHIR where they focus on clinical interoperability and harmonizing differences between the technical and clinical perspectives of FHIR resources.

Participants

Academy of Nutrition and Dietetics

Allscripts

Cerner

Clinical Cloud Solutions

Healthcare Services Platform Consortium (HSPC)

InterSystems

Lantana Consulting Group

SAMHSA

Veterans Health Administration (VHA)

Notable Achievements

Please limit to one paragraph summary

Screenshots

1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements

Discovered issues

What challenged the group?

What questions did you come away with?

Next Steps

1 paragraph: now what?

Catalog

Goal

This track aims at testing and consolidating the set of new resources (EntryDefinition, ObservationDefinition, SpecimenDefinition) and profiles (catalog) that were added to the standard to enable the sharing of catalogs of health care products and services. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon uses a clinical laboratory compendium and focuses on the consultation of this catalog. The general scenario is "Query and retrieve the definitions of orderable tests and panels from a lab compendium, together with asked at order entry observations and specimens expected".The track is based on the R4 current ballot.

Participants

Claude Nanjo - University of Utah Health Care

François Macary - Phast

Michel Blondel - Phast

Notable Achievements

Success on the planned scenario. The performed interactions were: 1) List available catalogs on the server; 2) List the entries of a catalog; 3) Search by name and/or by category an entry in an identified catalog 4) Obtain the full details of an entry of a catalog. A major outcome is a set of search parameters and refinements to the EntryDefinition resource.

Screenshots

Discovered issues

Reverse chaining for search parameters is currently under-specified in the standard. It is only described through a couple of examples. It would be nice to provide the full grammar to construct such kind of parameters.

The naming convention for search parameters, using dash character as word separator (e.g.; code-value-date) is cumbersome and prevents from using current APIs (e.g. WebAPI from microsoft). Wouldn't it be better to use a camel case convention?

CDS Hooks

Goal

Gather implementor feedback on the draft 1.0 CDS Hooks specification, including feedback on the CDS Hooks security model. Additionally, we want to connect as many CDS Service providers and EHR vendors as possible, to demonstrate interoperable CDS.

Participants

We had 43 participants across a wide variety of EHR vendors, CDS Service Providers, and healthcare institutions. Below is a list of the companies who participated. This should not be considered a comprehensive list; however, effort was made to be as complete as possible.

EHRs

Allscripts

Cerner

eClinicalWorks

Epic

T-System Inc

CDS Service Providers

Alcidion

Cigna

Clinical Cloud Solutions

EBSCO Health

Elimu

Elsevier

First Databank (FDB)

Flatiron Health

HarmonIQ

Health Samurai

Healthwise

IMO

Interopion

Lush Group, Inc

McKesson Specialty Health

Northrop Grumman

Premier Inc

River Rock

Stanson Health

University of Utah

Wolters Kluwer

Notable Achievements

We had 7 EHR implementations of CDS Hooks, one more than the last Connectathon which is very notable. Additionally, we had a very large number of CDS Service providers implementing CDS Hooks for the first time; attracting additional individuals and companies into our community is very important to us. Additionally, we had two very successful breakout discussions in which we discussed several changes to the CDS Hooks specification and reached consensus on approaches.

Several participants successfully implemented a diverse set of use cases using CDS Hooks, demonstrating their service integrated with a variety of EHRs.

Screenshots

Infobutton on CDS Hooks

medication-prescribe in Cerner

Univ of Utah's Opioid CDS Service

Discovered issues

We realized several important changes to the specification that we are incorporating for the 1.0 CDS Hooks specification release. Some of these changes are breaking (which is always painful), but as a community we agreed these changes are correct and important to make for our 1.0 release.

Next Steps

The CDS Hooks community is continuing to work on on getting the specification ready for a 1.0 release. We logged several Github issues during the Connectathon and are actively working on pull requests to address each of these issues. We plan to release 1.0 of the CDS Hooks specification in Q1 2018 based upon the feedback from the implementors at the Connectathon, as well as the broader CDS Hooks community.

Next Steps

Clinical Research

Goal

Participants

Notable Achievements

Screenshots

1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements

Discovered issues

What challenged the group?

What questions did you come away with?

Next Steps

1 paragraph: now what?

Consumer Centered Data Exchange

Goal

The CCDE Track is focused on two scenarios from the consumer's perspective. There is the scenario where the consumer is interactively involved in the sharing of their health information via standards based Oauth and there is the scenario where the consumer is able to convey their privacy preferences and persist them in a a discoverable way.

Both of theses scenarios rely on FHIR standards, specifically in relation to the Consent and related resources.

The goal of the track is to advance the use of these standards to verify their applicability and goodness of fit for these scenarios.

C-CDA attachment was sent via DirectTrust and stored as both a C-CDA document and a series of resources mapped into FHIR resources.

Screenshots

Discovered issues

What challenged the group?

Explaining to Connectathon participants how use of DirectTrust certificates and trust framework can scale inter-organizational FHIR queries in an efficient and proven manner. We met this challenge on numerous occasions over the two days, and this was valuable.

The new IG for Expressing Context in Direct Messaging needs some extensions to better handle workflows that are valuable in health information exchange via Direct.

Lack of space around the table, slow wifi.

What questions did you come away with?

No clear signal from FHIR community on DirectTrust certificate-based solutions for scaling FHIR, as there are several alternatives.

Who should we approach and how do we get broader participation for an Implementation Guide for use of DirectTrust certificates in authenticating and authorizing FHIR queries in inter-organizational use cases?

How do we effectively coordinate with the FHIR community after this event? How do we bring our communities together. How do we work together effectively?

Next Steps

1 paragraph: now what?

Electronic Case Reporting

Goal

Electronic case reporting (eCR) has been maturing in the CDA product family, and some preliminary FHIR case reporting specifications have now been developed and are being balloted for comment. This track will explore various aspects of FHIR case reporting as they mature, beginning with trigger code representation and dissemination, initial Electronic Case Report (eICR) and Reportability Response (RR) instance generation, and eventually expanding to distributing decision support logic and other items for the support of reporting and management in future Connectathons. This track could include discussions on additional resource needs for these use cases and discussion of items in the current “For Comment” eCR ballot.

Participants

John Loonsk, CGI Federal

Srinath Remala, CDC

Rishi Tarar, Northrup Grumman Corp.

Sarah Gaunt, Lantana

Rick Geimer, Lantana

Notable Achievements

Successfully tested Subscription to Bundle resource containing triggering value sets across multiple servers and channels for both routine and emergency use cases.

Successfully created reportability response and supporting resources.

Partially created initial case report and supporting resources.

Identified issues with eICR profiles that will need correcting.

Screenshots

Discovered issues

eICR profiles need corrections (slicing issues, etc.)

Submitted change requests for Subscription

Next Steps

Triggering:

Consider using Bundle tags to differentiate between emergency and routine update use cases.

Consider profiles on Bundle and possibly ValueSet

Consider using Subscription for more than value set distribution (i.e. distributing CQL, etc.)

Working with FHIR server vendors to advance consistent implementation of Subscription.

Shepard change requests for updates to Subscription to include the resource URL when no payload is specified vs. just an empty notification that "something" was modified.

eICR and RR submission

Update eICR profiles to fix validation issues

Finish sample files for eICR and RR

Misc

Follow up with more EHR vendors on track results

Discuss FHIR messaging and it's applicability for this use case

Encounter

Goal

To get as much feedback as possible on property usage on the Encounter resource by scanning resource instances from as many servers as possible.

When using persist=true, server returned error about being unable to find Patient resource. When not using persist parameter, server returned all resources referenced by Composition (including the Patient resource). (Server subsequently went down so we were unable to test further)

Financial

Goal

To test the exchange of eligibility, claim, pre-authorization, supporting information (attachments) and requests for payment reconciliation, explanation of benefit and processing status between clients (both Postman and actual clients) and servers.

Participants

Mark Scrimshire (CMS)

Benoit Schoeffler (Almerys)

Paul Knapp (Knapp Consulting Inc.)

Louis Bedor (Cognosante)

Dmytro (Health LX)

Notable Achievements

Clients and servers successfully communicated.

Screenshots

Discovered issues

No discovered issues with the specification, some internet and VPN issues.

Next Steps

May 2018 trial of R4 Resources.

Genomics

Goal

Genomics consists of the Sequence resource and several profiles built on top of existing FHIR resources (DiagnosticReport-genetics profile, DiagnosticOrder-genetics profile, Observation-genetics profile). The Sequence resource is a core resource in FHIR Genomics. It is used to represent complex genetics data. We are focused on clinical genetics data reporting.

We will also look to compare current FHIR extension model with a component-based model. New genomics IG

Participants

Names and Company Names

Logos optional

Notable Achievements

HLA use case:
Modify of the PhaseSet extension element, PhaseSet may need to be a single Observation in HLA use case, discuss more if we use component to store the PhaseSet Information

Unification (Component based model):
Latest version of IG discussed.

Screenshots

1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements

Discovered issues

Next Steps

IHE-on-FHIR

Goal

Send one document to a server using the IHE MHD transaction. This includes a DocumentManifest, a DocumentReference and a Binary document

Retrieve the document from the server

Exercise Alarm Communication and Management

Participants

Diego Kaminker (Almadoc)

Oliver Egger (The Hub Zürich Association)

Steve Moore (IHE USA / Washington University)

Bertil Reppen

Logos optional

Notable Achievements

Please limit to one paragraph summary

Screenshots

1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements

Discovered issues

What challenged the group?

What questions did you come away with?

Next Steps

1 paragraph: now what?

Medical Device and Implantables Tracking using UDI

Goal

To use FHIR to record information about procedures performed at the point-of-care using medical devices (single-use, implantable, monitoring) and record the procedure (e.g. implant, monitoring), identity of the device(s) (e.g. UDI), references to patient, providers,etc.

This track was intended to validate the FHIR profiles developed to supproto the "Point-of-care Medical Device Tracking" (PMDT) integration profile developed by VA and AORN (Asssociation of PeriOperative Nurses) as an IHE Patient Care Coordination Technical Framework supplement.

Participants

Ioana Singureanu, VHA (Track Lead)

John Rhodes, Philips Medical Systems

Stephen Hollifield, HealthLX

Will Tesch, HealthLX

Richard Esmond, PenRad

Greg Gustafson, PenRad

Notable Achievements

In addition to testing out the Device and Procedure resources we also tested Medication, MedicationAdministration, and Location to support the requirements of a new IoT device. The personal injection device is intended to record and transmit the identity of the operator, the geolocation (using Location), the type, route, and medication dose (using Medication and MedicationAdministration).

We discovered these resources could be used with RFID tagged devices - using a needle application or could molded into a larger device to provider RFID for the larger implant. The metal alloys used in devices are carefully research to avoid impact on future diagnostic imaging (avoid shadows and echos).The UDI could be used to track devices to the unique id of tumor and share the id of the tumor over time, among various system.

Screenshots

Not applicable at this time; this specification is meant to enable automatic data capture of identities, procode time, and location.

Some implants can identity location of a lump and provide RFID:

Discovered issues

We need to track the a tumor (using a unique id) across systems, over a period of time as treatment are applied to the site. Can we use BodySite to represent a tumor and "treat" the body site?

We decided to use "Medication.supportingInformation" to specific a Location reference for the place where the device was used to self-deliver medication (e.g. chemo, insulin).

Next Steps

We will add "MedicationAdministration", "Medication", and "Location" to the set resources and profiles we could use to document point-of-care procedures.

Patient Match

Goal

Exercise the updated Patient $match operation

Participants

Brian Postlethwaite (Telstra Health)

Cooper Thompson (Epic)

Notable Achievements

Successfully the operation using fiddler to the 1 and only current implementation

Discovered issues

No new issues in the one implementation (which was facading existing functionality)

Next Steps

Really do need further implementation experience on this operation

Patient Track

Goal

The Patient Track continues to provide an introduction to FHIR and give participants an opportunity to get some hands on experience using the Patient resource. The Patient Track also provides participants with the opportunity to test their servers and clients using the TestScript resources that have been created--this testing is accomplished using the AEGIS Touchstone testing platform.

There are 4 unique Servers associated with scenarios in this track. These are:

IMO (Yunwei Wang)

Hausam Consulting Test Server (R4) (Robert Hausam)

Terminz (Peter Jordan)

Clinical Architecture 3.0.1 (Ron Ross)

There are 3 unique Clients associated with scenarios in this track. These are:

Postman (Robert Hausam)

Trifolia DEV Environment (Sean P McIlvenna)

Touchstone Testing Platform (Richard Ettema)

There were 46 test results reported. The test results broke down as follows:

Result Count %

pass 34 74%

fail 2 4%

partial 6 13%

note 4 9%

Code system supplement breakout

Terminology versioning breakout

Screenshots

Discovered issues

What challenged the group?

Haven't yet achieved consensus on the capabilities of and rules around code system supplements - will continue to work on this.

Have further work to do in determining how we need value set and code system versions to be represented and used in FHIR, and in achieving consistency across different terminology servers. Need this to be aligned at least generally in the conformance resources (e.g. CodeSystem, ValueSet, StructureDefinition).

What questions did you come away with?

Next Steps

Further enhance formal terminology testing.

Develop tests around value set and code system versions - that was planned for this time, but not progressed as far as we desired.

Versioned API

Goal

Develop a strategy and some technical techniques so that server operators and clients can indicate which version of the FHIR standard they wish to use for communication. This will be helpful for maintaining compatibility with a variety of clients without requiring server operators to maintain as much infrastructure and will help avoid distributing canonical urls for resources that are tied to a specific version specific endpoint.

Participants

Grahame Grieve (Health Intersections)

Bradley Strecker (Cerner)

Chris Gentz (Analysts)

Cooper Thompson (Epic)

Ewout Kramer (firely)

Kevin Olbrich (McKesson Specialty Health)

others...

Notable Achievements

MIME-type usage for versions

Requests

Client optionally specifies the version of the API request

'Content-Type' header

Odd for GET (and other) request verbs, but not forbidden

named 'application/fhir+json; fhirVersion=3.0' using the major and minor versions of the semantic version.

patch version levels will be ignored by the server

no version or no header are interpreted as the default version for the server