View source for 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===

[[File:Image_share_s4s_postman_screenshot.png|300px]]

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?
===Next Steps===

==Bulk Data==
'''[https://docs.google.com/document/d/1Ps9OJVixnGO8qgLhxkprpZrH4icmBJC7-VAXLoOYd1U/edit#heading=h.wqdb1ohk3g0e 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===
[[File:CatalogTab.jpg]]

===Discovered issues===
* [http://build.fhir.org/search.html#has 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===
*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 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:
#Use of DirectTrust network to send / query FHIR resources.  Identify any issues or enhancements needed for this capability.
#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===
{| class="wikitable"
! style="text-align: center; font-weight: bold;" | Scenario
! style="text-align: center; font-weight: bold;" | Participants
! style="text-align: center; font-weight: bold;" | Asserter
! style="text-align: center; font-weight: bold;" | Result
! style="text-align: center; font-weight: bold;" |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===
[[File:DirectQuery.png]]
[[File:FHIRResponse.png]]
[[File:certificate_used_to_sign_jwt.jpg]]

===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===
[[File:Pasted image.png]]

===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===
{| class="wikitable"
|-
! style="text-align: center; font-weight: bold;" | Scenario/Goal
! style="text-align: center; font-weight: bold;" | Participants
! style="text-align: center; font-weight: bold;" | Asserter
! style="text-align: center; font-weight: bold;" | Result
! style="text-align: center; font-weight: bold;" | 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===
[[Image:Con17_FM_PK.PNG]]
[[Image:Con17_FM_PK.PNG]]
[[Image:Con17_FM_PK.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. [http://build.fhir.org/ig/HL7/genomics2/index.html 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:
   [[File:20180128 142218.jpg|250 px]]

===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:

[[File:Workflow.PNG]]

===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