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.

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 Plan

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?

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, change parameters)
• Next connectathon will test the catalog management interactions (create, update, retire entries ...) and catalogs of knowledge artifacts

CDS Hooks

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?

Clinical Reasoning

Goal

• Please limit to one paragraph summary

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

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

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

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

• Please limit to one paragraph summary

Participants

• Names and Company Names
• Logos optional

Notable Achievements

• Please limit to one paragraph summary

Discovered issues

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

Next Steps

• 1 paragraph: now what?

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

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

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

File:Con17 claim.PNG

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

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

Patient Track

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?

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

• Please limit to one paragraph summary

Participants

• Names and Company Names
• Logos optional

Notable Achievements

• Please limit to one paragraph summary

Screenshots

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

Discovered issues

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

Next Steps

• 1 paragraph: now what?

Scheduling

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?

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
• Code system supplement breakout
• Terminology versioning breakout

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?

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