Record Connectathon 17 Outcomes Here

Apps for Imaging Research

Goal

Demonstrate the ability to make a consenting patient's imaging studies accessible for research applications using the SMART on FHIR-based Sync for Science transaction model.

Participants

• Chris Carr (RSNA), Steve Moore (Washington University), Wyatt Tellis (UCSF) - RSNA Image Share Project
• Brad Genereaux - Agfa Healthcare

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

Apps for Imaging Research track; FHIR Connectathon 17. Screenshot of sample results of imaging query.

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.

Participants

• Dynamic Health IT: Mike Vishak, Ozlem, Raychelle
• UHIN (Utah Health Information Network): Andrew, Blain, Zak, Cody, Ben, Matt, Jared
• Health LX: Will, Steven, Yuriy, Dmytro, Taars

Notable Achievements

• UHIN Team
  • Valuable connection were made.
  • 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?

Bulk Data

Bulk Data Gdoc

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?

Next Steps

• Back to the Catalog task force (under OO WG) to complement the EntryDefinition resource (datatype changes, value sets, search parameters)
• Next connectathon will test the catalog management interactions (create, update, retire entries ...) and catalogs of knowledge artifacts

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.

Clinical Reasoning

Goal

1. Demonstrate distribution of quality improvement artifacts through exchange of PlanDefinition, ActivityDefinition, Library, and Measure resources. 2. Demonstrate population-level measure evaluation 3. Coordinate with Bulk Data track to run a quality measure 4. Coordinate with CDS Hooks track to integrate decision support in an EHR

Participants

• Ben Hamlin, NCQA
• Anne Smith, NCQA
• Julie Scherer, Motive Medical Intelligence
• Seena Farzaneh, Motive Medical Intelligence
• Aruna Goli, Motive Medical Intelligence
• Lindee Chin, Edifecs
• Bas van den Heuvel, Phillips Healthcare
• Chris Schuler, HarmonIQ
• Bryn Rhodes, HarmonIQ

Notable Achievements

1. Added population-level measure evaluation to the CQF Ruler.

2. Evaluated Alcohol Dependence HEDIS Measure (ASF).

3. Evaluated BCS, CCS, and COL at the population level.

4. Imported and evaluated PlanDefinition resources for Diabetes Care Management decision support from Motive Medical Intelligence (MMI) using CQF Ruler.

5. Edifecs population health platform consumed MMI Diabetes Care Management decision support by calling MMI REXS CDS Hooks service. The CDS Hooks cards and qualifying criteria were presented in the Edifecs interface.

Screenshots

Cancer Screening Summary Measure Report:

Discovered issues

• What challenged the group?
• What questions did you come away with?

Next Steps

• 1 paragraph: now what?

Clinical Research

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

• 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.

Participants

Track Lead - Aaron Seib NATE\NewWave

Aahlad Karumuru - NewWave Bo Dagnall - DXC David Hay - Orion Jin Yang - Cambria Kathleen Connor - HL7 Working Group Kyle Bradford - LA Public Health Inst Ali Kahn - ESAC\ONC Man M Garr - DXC Mark Scrimshire - CMS Michele Mottini - CareEvolution Mohan Kasi - Cambia Peter Kim - NewWave Peter Murphy - DXC Rama Manne - NewWave Randy Ullrich - Humetrix Sandeep Giri - UCSF Steve Mickelson - Humetrix Joyce Dunlop - DXC

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?

Direct Track

Goal

• Evaluate two scenarios:

1. Use of DirectTrust network to send / query FHIR resources. Identify any issues or enhancements needed for this capability.
2. Utilizing DirectTrust certificates with the FHIR RESTful API to enable trust relationships to scale. Identify any issues or enhancements needed.

Participants

• Bruce Schreiber – MaxMD
• Calvin Beebe - Mayo Clinic
• David Kibbe - DirectTrust
• Don Jorgenson - Inpriva
• James Fisher — MedAllies
• Julie Maas – EMR Direct
• Lisa Nelson - Life Over Time Solutions
• Luis Maas – EMR Direct
• Thomas J Ramsey

Notable Achievements

Scenario	Participants	Asserter	Result	Note
Patient request for data	Client: MyPHD Wellness Manager (Direct Trust Source) Server: MaxMDFhirResource (Target FHIR Server)	Lisa Nelson	Pass	Important demonstration of individual access to health information - access to C-CDA or FHIR resources.
Patient request for data	Client: EMR Direct HealthToGo (Direct Trust target) Server: EMR Direct Stage Server (Source FHIR Server)	Luis Maas	pass	success for use case #3, 4, and 5
Patient request for data	Client: Direct mdEmail 3.0 (Direct Trust target) Server: MaxMDFhirResource (Target FHIR Server)	Bruce Schreiber	pass	Patient Direct address - patient queried for his own record and retrieved them.
Patient request for data	Client: Direct mdEmail 3.0 (Direct Trust Source) Server: MaxMDFhirResource (Target FHIR Server)	Bruce Schreiber	pass	C-CDA attachment was sent via DirectTrust and stored as both a C-CDA document and a series of resources mapped into FHIR resources.
Patient request for data	Client: EMR Direct HealthToGo (Target EMR) Server: Cerner DSTU 2 Secure - Patient Access (Source FHIR Server)	Julie Maas	pass
Patient request for data	Client: EMR Direct FHIR over Direct Client (Target EMR) Server: MaxMDFhirResource (Target FHIR Server	Bruce Schreiber	pass
Patient request for data	Client: EMR Direct HealthToGo (Target EMR) Server: Kaiser Permanente CTO EIS POC Server (Source FHIR Server)	Julie Maas	pass
Provider request for data	Client: Direct mdEmail 3.0 (Direct Trust target) Server: HAPI-3 (Source FHIR Server)	Bruce Schreiber	pass	Provider uses a Direct Message to query for a Patient's health data. The result was returned using Direct.
Provider request for data	Client: FHIR Over Direct Client (Direct Trust target) Server: EMR Direct FHIR over Direct Server (Direct Trust Source)	James Fisher	pass	Sent encapsulated message "GET /Patient/1234 HTTP/1.1". Received FHIR response in JSON format.
Provider request for data	Client: EMR Direct FHIR over Direct Client (Direct Trust target) Server: EMR Direct FHIR over Direct Server (Direct Trust Source)	Julie Maas	pass	Workflow IG using Context IG
Provider request for data	Client: Direct mdEmail 3.0 (Direct Trust Source) Server: HAPI-3 (Source FHIR Server)	Bruce Schreiber	pass	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.

Participants

• Brian Postlethwaite (Telstra Health)
• Cooper Thompson (Epic)

Notable Achievements

The Resource property usage app was tested against Telstra Health (44/44), Health Intersections (44/44), Epic (19/44), Accenture (44/44) and CQF Demo servers (19/44) with some good results found. Example Results

Also ran the tool against the CQF Demo PlanDefinition resource and works no issues (40/75). The tool is available on github: https://github.com/brianpos/FhirResourceScanner

Discovered issues

• Many servers don't support open searching
• Tooling needed to be able to run on local bundle files

Next Steps

• Publish the tool for others usage
• Seek others to run the tool on their own infrastructure/servers to get more feedback

FHIR Documents

Goals

• Test/update mappings/transforms from CDA to FHIR
• To be able to import a CDA and transform it into its equivalent FHIR resources
• Generate a fully bundled document from a Composition resource using the Generate Document operation
• Figure out what to do with Notes (e.g. History and Physical note)

Participants

• Sarah Gaunt (Lantana Consulting Group)
• Benjamin Flessner (Redox)
• Michael Hutton (Qvera)
• Corey Spears (Infor)
• Joel Francis (Canada Health Infoway)

Notable Achievements

Scenario/Goal	Participants	Asserter	Result	Note
Create and persist Document (bundle) from a Composition resource using $document operation	Client: Postman Server: http://test.fhir.org/r3	Joel Francis / Sarah Gaunt	Fail	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)
Create narrative document (C-CDA on FHIR from IHE Healthy Weight profile)	Client: HAPI UI Server: HAPI	Corey Spears	Pass	Updated CDA to FHIR XSLT transforms to support IHE Healthy Weight profile
Create document with section entries (C-CDA on FHIR from IHE Healthy Weight profile)	Client: HAPI UI Server: HAPI	Corey Spears	Pass	Updated CDA to FHIR XSLT transforms to support IHE Healthy Weight profile
Extract resources from document (C-CDA on FHIR from IHE Healthy Weight profile)	Client: HAPI UI Server: HAPI	Corey Spears	Pass	Updated CDA to FHIR XSLT transforms to support IHE Healthy Weight profile
Create document with section entries	Client: Qvera Server: Redox	Michael Hutton / Benjamin Flessner	Pass	Redox server parsed the CDA into FHIR composition (inline resources)
Create document with section entries	Client: Qvera Server: Dynamic FHIR Server	Michael Hutton / Raychelle Fernadez	Pass	Dynamic FHIR server parsed the CDA into FHIR composition + separate resources (e.g. Condition, Observation, etc.)
Display document	Client: Qvera Server: HAPI-3	Michael Hutton	Pass	Display the FHIR produced from Lantana translated CDA

Screenshots

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

Discovered issues

• What challenged the group?
  • Server issues
  • Slicing
  • Tooling differences that prevented use of other tools (e.g. Qvera tool unable to make use of Lantana CDA to FHIR tooling)
• What questions did you come away with

Next Steps

• Take some time to update FHIR slicing documentation
• Continue testing $document operation
• Update CDA to FHIR transforms to a one file solution/non web server dependent
• Update CDA to FHIR transforms to use a free parser (not SAXON-PE)
• Continue update of CDA to FHIR trasnforms to support IHE Healthy Weight Summary

FHIR Subscriptions

Goal

Mature FHIRcast, sustain and increase community involvement. Grow FHIR Subscriptions.

Participants

• Niklas Svensen - Sectra
• Leo Bergnehr - Sectra
• Jeremy Richardson - MModal
• Jim Schafer - PenRad
• Max Philips - Cerner
• Eitan Behar - Allscripts
• Segay Mintz - Allscripts
• Jenni Syed - Cerner
• Will Maethner - Epic
• Isaac Vetter - Epic
• Brad Genereaux - Agfa, II

Remote:

• Martin Bellehumeur - Siemens
• Hardik - Siemens
• Ashish - Siemens

Notable Achievements

• Sectra, Epic implemented a successful, single direction FHIRcast implementation for patient and imagingstudy synchronization.
• Began using github to track issues in force. [Jeremy]
• Kicked off a project to create an internet-accessible reference implementation.
• Began creating list of targeted usecases for FHIRcast specification.
• AEGIS implemented subscriptions and some testscripts for subscription

Discovered issues

• We're recording issues here: https://github.com/fhircast/docs/issues
• II did question if it's the correct working group to sponsor FHIRcast.

Next Steps

• Provide update to Imaging Integration group.
• Establish some recurring calls around https://github.com/fhircast/docs/issues/13
• Elliot will submit PSS to SSD SD
• Reference implementation
• Testscripts for may wgm for fhicast

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
• Reviewed IG model: File:Genomics-UnifedIG-201801.pdf

Discovered issues

• What challenged the group?
• What questions did you come away with?

Next Steps

• 1 paragraph: now what?

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.

Participants

• James Cheung, Kaiser Permanente
• Raphael Majeed, University Oldenburg
• Amina Shaikh, Philips Healthcar
• Brain Wright, Mayo Clinic
• Joshua Varner, Corepoint Health
• Tyler Tallman, Breeze EHR
• Victor Vaysman MD, MedSide Healthcare
• Swastika, BC/BS of Louisiana
• Ron Shapiro, Qvera
• Richard Ettema, AEGIS

Notable Achievements

• Continue to provide newcomer orientation and direction towards participation
• 25-30 attendees at the FHIR Overview and FHIR Testing breakout sessions on Saturday
• 9+ organizations successfully exchanged FHIR Patient resource
• 4+ organizations successfully executed FHIR TestScripts on AEGIS Touchstone

Screenshots

Discovered issues

• Enhance Create Patient Test Scripts for Server Assigned ID to validate that the resource ID returned is different than the resource ID provided by the client, if provided.

Next Steps

• Add ability to 'publish' results from Touchstone directly to the Connectathon Management Application.

Pharmacogenomics CDS

Goal

Upon order entry of a medication, check for drug-gene interactions and produce recommendations.

Participants

• Bob Dolin, Elimu Informatics (track lead)
• Aziz Boxwala, Elimu Informatics
• Kevin Power, Cerner
• Dave O'Larte, Cerner
• Xin Liu, Boston Children's Hospital
• Fan Lin, Xiamen University
• Lei Liu, Xiamen University
• Bob Freimuth, Mayo Clinic

Notable Achievements

• PGx CDS Service
  • PGx CDS Service interacts with EHR (via CDS Hooks), OMIC Data Store (via FHIR), and Terminology Server (via FHIR).
• OMIC Data Store
  • Interacts with PGx CDS Service (via FHIR)
• EHR
  • Order entry of a medication triggers a “medication-prescribe” CDS hook which invokes the PGx CDS Service and provides it with a FHIR MedicationOrder instance.
• Terminology Service
  • Interacts with PGx CDS Service (via FHIR) to see if the ordered drug is in an “Actionable PGx Drug” value set.

Screenshots

Overall worklow is shown in the following figure:

Discovered issues

• Challenging to deal with structural variations
• Challenging to represent star alleles, haplotypes, and genotypes (and their correspondence to variants)
• Multiple ways to represent variations (e.g. observation-genetics, PGx example, HLA resource)

Next Steps

• Add in additional drug-gene interactions (in addition to azathioprine/TPMT)
• Modify logic to leverage Ancestry where applicable to guide PGx recommendations
• Enhanced CDS functionality, such as: patient already on med (therefore suppress alert), provider has chosen to suppress a particular alert, etc.
• Deeper dive into interplay between star alleles and variants

Provider Directory

Goal

• Provide Guidance and get feedback on the current provider directory resources/IGs (Core/Argonaut/Validated Healthcare Directory)

Participants

• Brian Postlethwaite (Telstra Health)
• Tim Berezny (CareDove)
• Nikolay Ryzhikov (Health Samurai)

Notable Achievements

• Reviewed Canadian Referral IG and how it relates to Provider Directories, and compared it to an Australian directory IG that is also in progress at HL7 Au.
• Performed some testing on the Care Dove implementation using Fiddler (found some minor API issues).
• Health Samurai provide NPES data as FHIR API (interested in collaborating to make public)

Discovered issues

• Identified some of the duplicated content among the directory resources, but was able to explain why this is the case, and how to handle these
• Maybe some additional
• Since the introduction of the Endpoint resource, the HealthcareService's referral method should be re-validated

Next Steps

• The Canadian and Australian IGs on eReferral and Directory support will co-ordinate activities

Scheduling

Goal

• Pilot the Argonaut Scheduling Implementation Guide (https://argonautproject.github.io/scheduling/OperationDefinition-appointment-find.html)
  • Discovery of what works and what doesn’t
• Determination of Future steps
• Network with Fellow Schedulers
• Chat and Commune with the FHIR Community

Expected participants

Servers:

Name	Use Case 1	Use Case 2	Use Case 3	Use Case 4	Use Case 5
Cooper Thompson: Epic				X	X
Andrew Torres: Cerner			X
Brian Postlethwaite: Telstra Health (HealthConnex)	X
Eric Haas *Track Lead*: Health eData Inc (Flask Facade on Test server)	X

Clients:

Name	Use Case 1	Use Case 2	Use Case 3	Use Case 4	Use Case 5
Brandon LaRue , Eugene Yao: ZocDoc			X
Eric Haas *Track Lead*: Health eData Inc (Postman)	X	X	X	X	X

Notable Achievements

• Review of Prefetching Appointments Scenario
• Resolution of Outstanding Issues
• Simple Demonstration Application reflecting most basic scenario
• Future Plans
  • Final edits and updates to IG
  • Publishing date at end of February
  • Implementations based on IG in late 2018

Screenshots

• Argonaut Scheduling Implementation Guide
• Testing application(beta)

Discovered issues

• The prefetching scenario described in the IG lead to several breakout sessions to resolve the workflow and APIs needed for implementation.
  • Identified solution for each issue and were able to document the changes to the IG make prefetching more implementable.

Next Steps

• Future Plans
  • Final edits and updates to IG
  • Publishing date at end of February
  • Participation at DevDays USA in June ( Speaker TBD )
  • Implementations based on IG in late 2018

Terminology Services Track

Goal

• Formal Testing of Terminology Services
• Introduction to Terminology and Terminology Services
• Developing Terminology Servers and Clients
• Engaging/Involving Other Tracks with Terminology and Terminology Services

Participants

• Ettema Richard AEGIS.net, Inc.
• Ho John 3M Health Information Systems
• Schneider Joel NMDP / CIBMTR
• Kramer Ewout Furore
• Macumber Carol Apelon, Inc.
• Wang Yunwei IMO
• Calderero Michael Accenture
• Egelkraut Reinhard HL7 Austria
• Graham Carol Clinical Architecture
• Hausam Rob Hausam Consulting LLC
• Humpherys Kristen 3M HIS
• Jordan Peter HL7 New Zealand
• Kartchner Tosh 3M Health Information Systems
• McClendon Craig Accenture
• McClure Robert MD Partners, Inc.
• McIlvenna Sean Lantana Consulting Group
• Nachimuthu Senthil 3M Health Information Systems, Inc.
• Ross Ron Clinical Architecture
• Mike Lapshin Health Samurai
• Sagy Pundak Mintz Allscripts
• Patrick Werner Heilbronn University

Notable Achievements

• Track orientation breakout
• Formal testing of multiple terminology service operations on multiple terminology servers

• Track orientation breakout
• Formal testing of multiple terminology service operations on multiple terminology servers

There are 11 participants and 7 watchers.

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

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
    • 'Accept' header
      • provide a comma separated list of mime types in order of preference (i.e., 'Accept: application/fhir+json; fhir-version=3.0, application/fhir+json; fhir-version=1.0.2, application/fhir+json, application/json+fhir, application/json')
      • Don't use 'q' to indicate order
  • Server determines the version of the request and responds
    • Error conditions
      • if the resource in the request is not compatible with the version specified (i.e. it doesn't exist in that version)
      • if the server does not support the specified version
    • Response
      • Server uses the 'Accept' header to determine which version to use for the response
        • Use mime types in order specified, first one satisfied by the server should be used
        • Server should ignore versions it does not support
        • Ignore patch version if specified (i.e., `fhirVersion=3.0.1` is the same as `fhirVersion=3.0`)
        • If no version is specified, use the default server version.
      • Server should indicate the version used in the response by adding the `fhirVersion=3.0` parameter to the 'Content-Type' header of the response.
    • CapabilityStatement / Conformance
      • Server returns a CapabilityStatement or Conformance that is appropriate for the version of FHIR requested and the default version if it is not.
      • The capabilities may be different between versions. A server operator may choose to have older FHIR versions be read-only or not support searching or other operations.
    • Proposed `[base]/$versions` operation will return a list of FHIR versions supported by the server (optional, and obviously not supported on legacy servers).
• Versioned API urls
  • This approach remains useful when the header can't be specified or preserved
  • Not precluded by the MIME type approach
• All resources in a bundle/request must be the same version

Discovered issues

• Transforming Resources from one version to another is fraught with peril. It can work in some cases, but won't in many others.
• ValueSets and other terminology will be quite problematic between versions.
• Resources written to storage may become decoupled from the version information.
• There are nuances about the mime type approach with regard to normative resources that remain to be fully explored.
• OAuth scopes need to be carefully considered
• _format parameter behavior has not been explored

Next Steps

• Need some reference servers that implement this pattern for testing
• Identify test cases
• Try it
• formal proposal