Page tree

HL7 FHIR Connectathon 22 Outcomes Report

Atlanta September   2019


Thank you for your help!

You will need to open this document in Google Docs to edit - if you haven’t, you probably have a box that says “Open With” at the top of the page. Click it! :-)


Click on your track name in the Table of contents and then click the link that pops up in blue and it will jump to your section of the document.


Let me know if you have questions!    Sandy Vance


Please provide the following information in no more than one page:


        1 paragraph summary: what was the track trying to achieve

        1 list of participants (with logos if you have time and energy)

        1 paragraph: notable achievements

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

        1 paragraph: discovered issues / questions (if there are any)

        1 paragraph: now what?

Table of Contents

ArgonautR4 / US Core


The Argonaut R4 Implementation Guide is a copy of the the US Core Implementation Guide STU3 which is based on FHIR R4. This guide is the basis for further testing and guidance by the Argonaut Project Team. The guide will retain the US Core artifacts and names and provide additional content and guidance specific to Data Query Access for the purpose of ONC Certification testing of the servers for conformance to the profiles and be capable of responding to all of the “supported searches” specified in the Argonaut Data Query Implementation Guide Server .









         T-System Inc

         Dynamic Health IT



         Postman Collections    ( Argo team based on Synthea Data )







Progress Reports:  


Karen -TriNetx


Tested with Epic, CareEvolution, Meditech


Smart and CareEvolution able to do multipatient search

EHR not supporting multipatient search


Helpful for getting idea on roadmap to get to bulk data able test data to process it.



  CareEvolution Inc


Tested the following servers using our client:


- Epic - able to get data, had some errors / warnings that we reported via Zulip, did not analyze their details (Danielle here only sunday)


- Cerner - able to get data, had some errors / warnings that we reported via Zulip , did not analyze their details (Drew not here)


- DynamicHealth - able to get data, some errors on MedicationRequest due to our client not supporting having a Patient as the requester (and generating the wrong error message)


- Not able to test Meditech server: it does not support CapabilityStatement yet, that our client needs.


- T-System fixed their server and we were able to test successfully: imported Patient, Practitioner, Encounter, Observation, Medication Requests, DiagnosticReport - no errors


- Tested our server using Inferno - got some errors we have to analyze (a combination of wrong systems for coded data and some empty required elements apparently)


Inferno tested all servers as above and found similar issues:

   +Onc site, carenexus,


Postman Collection/Synthea:

loaded Synthea Patient to reference Server ( Hapi  R4) as successfully searched and validated all resources (using custom validator based on IG  for US Core 3.0.1)


Issues discussed during breakout sessions:


Follow up discussions on Provenance and M erge vs Unmerge - Zulip chat in Argonaut stream and Subscriptions stream

Issues discussed during Breakouts: Our key objective is to identify problems with existing US Core 3.0.1 profiles.

         MIssing data when the binding is required and there is no unknown codes

         MedicationRequest intent for self-prescribed substances?

         Progress on Provenance

         Merge vs Unmerge ( Combine vs Uncombine)

        Servers requiring Status :

        Mismatch of Search Conformance between Profile of Same type

        Patient identifier profiled to exclude masking

        Implanted Device Profile too restrictive - how to limit to implantables during search.


Next Steps


The US Core Guide is currently in a comment period for update.  This is closing shortly and the comment will be considered prior to publishing.  We will be following up and entering these comments for further consideration for discussion by the community.


Saturday 2-3 PM Room M 103 (Capacity 30 People)

Our key objective is to identify problems with existing US Core 3.0.1 profiles.

         Brief introductions of all

         Collect open issues, priorities

         MIssing data when the binding is required and there is no unknown codes

         need to add clinicalStatus for Allergies and Condition to the list  - (tracker)

         resource is not valid to profile - no way to DAR it

         Client wants the data

         what would you do?

         Next steps

         Remove ‘ CarePlan.text.status’ from missing data

         Add operationOutcome when missing and fail the request.

         MedicationRequest intent for self-prescribed substances?

         clarify that is alway going to be order?

         required binding with no "unknown"  current tracker for R5 is getting pushback and wanting use case for this.

         Next steps

         Make it more explicit that self-prescribed will be ‘order’

         technical corrections:

         comparator expectation extension being stripped

         Must support link is missing from profile introductions.

         Progress on Provenance

         Merge vs Unmerge ( Combine vs Uncombine

         Background and discussion to socialize this issue

        Handled different ways…

        Goals: way to know why data is disappeared and still retain information you care about and maintain privacy



Sunday 2-3 PM Room International 7


Progress Reports:  


Karen -TriNetx


Tested with Epic, CareEvolution, Meditech


Smart and CareEvolution able to do multipatient search

EHR not supporting mulitpatient search


Helpful for getting idea on roadmap to get to bulk data able test data to process it.



  CareEvolution Inc


Tested the following servers using our client:


- Epic - able to get data, had some errors / warnings that we reported via Zulip, did not analyze their details (Danielle here only sunday)


- Cerner - able to get data, had some errors / warnings that we reported via Zulip , did not analyze their details (Danielle here only sunday)


- DynamicHealth - able to get data, some errors on MedicationRequest due to our client not supporting having a Patient as the requester (and generating the wrong error message)


- Not able to test Meditech server: it does not support CapabilityStatement yet, that our client needs.


- T-System fixed their server and we were able to test successfully: imported Patient, Practitioner, Encounter, Observation, Medication Requests, DiagnosticReport - no errors


- Tested our server using Inferno - got some errors we have to analyze (a combination of wrong systems for coded data and some empty required elements apparently)



Onc site, carenexus,



Follow up discussions on Provenance and M erge vs Unmerge


Servers requiring Status :


Add a Sentence --

Servers are encouraged to support a query for resources without requiring a status. If business requirements prohibit returning all Resources with all statuses they SHALL follow the guidelines here.


e.g.  for Epic:


- Allergy  ( requires clinicalStatus )

- Condition ( requires category )

- MedicationRequest (requires status )

- DocumentReference ( require category )



        client need to code for this

        So the patient not really a SHALL is it really a SHOULD?

        is it unambiguous when fail that is a "hidden status requirement" ( testing perspective )


        Documentation erroneously states to put in




should be ...




Mismatch of Search Conformance between Profile of Same type


specifically DiagnosticReport


Do servers distinguish Search capabilities by Type or by Profile?


if by type then the Search Conformance should agree between profiles


if by profile then the Search Conformance does not have to agree between profiles

- but the CapabilityStatement currently does not handle.

- need to document this in: ``

- unable to document programmatically for each combo ( without custom extensions )

- differentiate by meta.profile or category for DiagnosticReport?





Bulk Data

Summary : This track focused on testing clients and servers that use the bulk data export operation ( ) and refining the early draft spec for a bulk data import operation ( ).


Michele Mottini

CareEvolution Inc


Client only

  1. We connected successfully with the CMS R4 server (after a couple of fixes), downloaded and imported Patient + ExplanationOfBenefit + Coverage
  2. We connected successfully with the Microsoft STU3 server - after adding support in our client for the non-standard _destinationType and _destinationConnectionSettings parameters. Downloaded and imported 24 Patient, 451 Encounter, 122 Condition, 1198 Observation, 73 DiagnosticReport, 84 Medication, 97 MedicationRequest, 35 Goal. Error on some Goal without a subject (that for some reason is actually optional in STU3 - but we require)
  3. Participated in discussions about $import - we are somewhat skeptical on it, and it is most likely not something we are going to implement in our system (we have trouble enough implementing $export!)



Vladimir Ignatov

Boston Children’s Hospital


  1. Fixed the conformance statement of to match the latest requirements.
  2. Fixed the R4 data (it was generated with an early version of Synthea and did not conform to the latest R4 spec).
  3. Improved some of the error messages in
  4. Created a bulk data testing tool available at
  5. Created a library for working with bulk data files and converting between different formats available at
  6. Experimented a little with $import
  7. Did a test run of the bulk data server against the HAPI bulk data server.


Patrick Grennan

One Medical

  1. Built proof of concept $import for our internal FHIR server
  2. Contributed one of our use cases to the spec repo


Yunwei Wang


  1. Tested six bulk data servers using Inferno Bulk Data test client
  2. Added tests for export operation’s _type parameter
  3. Added tests for delete export content request
  4. Discussed several Bulk Data export IG issues with the community


Jack Liu/Narasimhan Madabusi



  1. Deployed FHIR server instances for interoperability testing.
  2. The current $export implementation require additional parameters for destination. Adding support for default storage so the API behaves according to the spec.
  3. Participated in the $import discussion.


Kalyani Yerra

Premier Inc


  1. Created a Bulk Data Client to interact with the CMS DPC sandbox.
  2. Successfully retrieved the Explanation Of Benefits Resources, Coverage and Patient from the DPC sandbox.


Nick Robison

US Digital Service


  1. Successfully integrated a couple of bulk clients in our temporary data sandbox.
  2. Addressed a number of conformance and implementation issues that hadn’t yet been surfaced.
  3. Chatted with developers of existing systems about their experiences and recommendations for us moving forward.


Bas van den Heuvel


  1. Tested the PhilipsOnFhir FHIRProxy bulk-data implementation (export and import) and FHIRViewer application.
  2. Used PostMan to contact the microsoft bulk data end-points. Client did not work as the server depends on non-standard extensions.
  3. Import tried based ndjos file. Input json was mapped On Parameters object.

Code available on .


Phil Langthorne

Prometheus Research


  1. Updated bulk data client to comply with the balloted spec for $export
  2. Tested client against IBM implementation
  3. Participated in $import discussions



Albert Wang and Lee Surprenant


Lessons Learned: only mentions GET but we think POST is more appropriate since its potentially costly to retry.  FHIR Operation framework defines that operations can be invoked via either, but no one is using POST for bulk data.

        We use basic authentication for now. Also, we had our CapabilityStatement behind this auth.  This caused problems for inferno and one other client.

        NDJson slide at FHIR BULK DATA API - was confusing (no ‘[‘ or ‘]’ or ‘,’)



        Added support for proper GET request (only POST was working when we arrived)

        Learned about $import use cases

        Successfully tested with Postman and client from Prometheus Research

        Discussions about future directions; interested in bulk export to Parquet in analytic format

Care Planning and Management

Summary: This track focused on applying evidence-based clinical practice guidelines at the point of care to create and share individualized patient care plans.


         Academy of Nutrition and Dietetics


         Clinical Cloud Solutions




         CMS/ONC eLTSS Initiative


         LTC Innovation (LTCI) and VorroHealth

         Namaste Informatics

         Veterans Health Administration (VHA)

Notable Achievements:

       Progress on approach for representing Nursing care planning guides using Plan/ActivityDefinition. Intended to provide nursing guidance at point-of-care, may result in creation or addition to a patient’s care plan, including patient-specific Goals.

       eLTSS FHIR IG team updated and teste implementations with compliance with published IG.

       Updated IBM’s new open source FHIR R4 server with initial support for PlanDefinition $apply operation.

Discovered Issues:

       Questions on use of CommunicationRequest to request agreement or denial from practitioner to join a patient’s care team associated with a CarePlan. Will include this in Patient Care WG discussion this week.

       Inadequate tooling to complete validation and testing of CQL logic included in CKD use case defined in the balloted CPG-on-FHIR IG.

       Linking and de-conflicting multiple care plans for a patient, especially when distributed across multiple provider organizations. Need example and prototype with linked care plans.

Now What?

       Include use of CQL and/or FHIRpath conditions in PlanDefinition to select relevant activities for inclusion in a CarePlan, or exclude activities that should not be included based on current patient record.

       Continue discussion on a dedicated Zulip thread for care planning. Identify specific objectives for development and integration at next connectathon.

       Testable software implementing support for care team management, including inviting/adding new team members and subscription/notification of care plan changes.


CARIN Blue Button





Real world testing of the CARIN Blue Button IG


List of participants:







Cambia Healthsparq


AaNeel Infotech







Cambia Journi

Patient Price

Harvard Medical School

BCBS Tennessee


Notable achievements:


The group set up seven servers with data by the end of the connectathon. Eleven client apps have connected to the servers and pulled data.













b.Well app





Discovered issues / questions:


The lack of volume of synthetic data. Lack of consistency of data (some are doing STU3 or R4). Did not get a chance to get into implementation guide gaps (for example: terminologies).

Inconsistencies in the security authentication of servers.


Now what?


Will address the discovered issues at that next connectathon (tentative date December 9)




CARIN Consumer-Facing Real-Time Pharmacy


PURPOSE: The purpose of this track was to test the implementation approach for the consumer-facing Real-Time Pharmacy Benefit Check that will allow consumers to access their pharmacy benefit information and a discount/cash price information for their prescription medications.  This information includes on/off coverage, Out of Pocket costs, therapeutic alternatives, and cash price through an API that would be accessible by the consumer through a third-party application.  More information here:



Humana (Payer/PBM)

B.Well (Consumer App)

MedSavvy (Consumer App)

CoverMyMeds (Intermediary)



Notable Achievements:

Mobile app developer was able to request patient benefit information and cash price for 5 different scenarios and receive back information to display to the user. 




Discovered Issues:

       Need to figure out how to handle drugs that don't have "common" NDCs

       Needs to be better defined "null" states (ie pricing isn't known or drug isn't covered) and make these states more explicit

       Need a universal directory for both payor and cash APIs

       Use NCPDP ID for pharmacy over NPIs

       Show pricing information with whether it's copay or deductible


Now what:

We will work on building the IG based on the feedback we received from participants



CCDA IAT Atlanta


The goal of the IAT this time was to work on consistency and quality of information representation.  We focused on a number of key areas that had been identified as concerning to implementers:

       Encounter-based documents

       Being explicit about human readability and rendering


       Representation of data as it changes over time

       C-CDA Rubrics and the USCDI Process



Abigail Watson (Symptomatic), Andrew Statler (Cerner), Anglie Glotstein (Cerner), Anne Smith (NCQA), Benjamin Flessner (Redox), Brett Marquard (Wave One Associates), Didi Davis (Sequoia Project), Ed Donaldson (Office Practicum), Emma Jones (Allscripts), Gay Dolin (Namaste Informatics), George Dixon (Allscripts), Jessica Ordoyne (Dynamic Health IT), Joe Lamy (, John D’Amore (Diameter Health), Linda Michaelsen (Optum), Matt Elrod (MaxMD), Matt Rahn (ONC), Matthew Dugal (Dynamic Health IT), Nick Radov (UHC), Raychelle Fernandez (Dynamic Health IT), Rob Samples (ESAC), Sarah Sims (Patient Insight), Shayaan Munshi (eClinicalWorks), Sumanth Bandaru (Dynamic Health IT), Swapna Abhyankar (Regenstrief Institute), Wendy Talbot (NCQA)



  1. Created some great Workflow diagrams that are being shared with implementers
  2. Had a discussion about Quality Measurements in CDA documents
  3. Walked through examples to identify consistency and quality issues
  4. Had a long discussion about Provenance
  5. Reviewed the new CDA Scorecard UI.
  6. Had a good discussion about the next version of USCDI.


We have a full set of minutes about what occurred at our confluence page:



       We need to get more implementers involved in the IAT, especially some of the non-traditional vendors who are developing CDA engines or CDA drop-in libraries

       There are still lots of quality concerns.  We will continue feeding identified issues to SDWG for inclusion in the Companion Guide.


Now What?

We may not continue the CDA IAT track at the Connectathon since many of our vendors/implementers need to be in multiple tracks and running the IAT through all quarters of both days doesn’t allow for that.  We will be looking for new ways to hold the IAT.  As well, we need to reach out to the implementers to get their pain points and have more cross-vendor discussions of how to solve the issues the implementers have, rather than the ones that the spec writers are having.


CDS Hooks




The first goal of the CDS Hooks track is to facilitate CDS Clients and CDS Servers with their implementations of the 1.0 specification.


The secondary goal aligns with Argonaut discussions around meeting PAMA use-cases with CDS Hooks (including the notion of systemActions), and SMART Web Messaging.  The track encourages participants to be able to apply ratings from systemActions, use suggestion cards for alternate imaging orders, and  leverage SMART Web Messages to swap orders when more input is needed from the provider. 


IG -

Argonaut call notes -





AIM Specialty Health, Cerner, Elsevier, Epic, First Databank (fdb), IMO/Namaste Informatics, Mayo Clinic, McKesson, Medlinx, Microsoft, SMART Health IT, T-System Inc., University of Pittsburgh, Waveone, Wolters Kluwer



Notable achievements


Implementing v1.0 - info / suggestions / SMART app link cards

       CDS Services - First Databank, Mayo, McKesson, Medlinx, University of Pittsburgh, Wolters Kluwer

       CDS Clients - Cerner, Epic, T-System


PAMA Scenarios


        CDS Services - Mayo, SMART Health IT / Microsoft (Sandbox)

        CDS Clients - Cerner, T-System

        Discussions - AIM Specialty Health, IMO/Namaste Informatics

       Cerner and T-System were able to apply PAMA ratings via system actions


SMART Web Messaging (incl PAMA scenario 3)


        CDS Services - SMART Health IT / Microsoft (Sandbox), Wolters Kluwer

        CDS Clients - Cerner, T-System

       Cerner and T-System were able to receive SMART Web Messages from Wolters Kluwer to interact with the scratchpad

       Cerner integration with PAMA Demo App pending








Discovered issues / questions

       qCDSM id vs GCode

       'adheres/does not adhere' versus 'appropriate/not appropriate'

       HCPCS modifiers

        expanding selectionBehavior beyond at-most-one

       Reducing duplicate CDS cards

       overlap with ‘CDS Hooks Dynamics’ topic below

       CDS Client behavior for displaying/removing/re-invoking cards



Now what?


More testing is needed on PAMA scenarios, including further participation around systemActions and SMART Web Messaging scenarios.    Looking forward to v1.1 of the spec, additional discussions and testing should explore override reasons, providing feedback to CDS Services, and additional workflow-oriented guidance.


Clinical Genomics



The CG WorkGroup is finalizing QA and vetting examples for the final push into publication of the FHIR Genomics Reporting IG (universal realm, DSTU). The track aimed to identify, categorize, and eliminate all errors/issues preventing examples from validating. The main tools used for this were the java validator, HSPC sandbox’s validation tool, and uploading profile StructureDefinitions to local HAPI servers.



  • Jamie Jones (SMART Health IT/Boston Children’s Hospital)
  • Patrick Werner (MOLIT)
  • Bret Heale (Intermountain)
  • Joel Schneider (NMDP/CIBMTR)
  • Dora Finkeisen (MOLIT)
  • Alexander Zautke (Firely)


        Notable achievements

Worked with ontoserver and others towards supporting and troubleshooting inclusion of , HGVS, and other genomic terminologies/nomenclatures. Trackers filed and followed up on for missing functionalities in supporting LOINC answer lists, level of errors raised by referencing unsupported code systems, broken links occurring from referencing locally defined codes, and recent changes to the publisher. Recently updated concepts were more fleshed out with textual guidance, and steps to facilitate alignment with other IGs using Genomics were laid out.





       Discovered Issues

        Multiple errors caused by known issues in publisher framework.

        Unsupported core extension from CG WG identified in mCode IG, need to push for realignment with updated component guidance.

        HSPC profile upload tool unable to support StructureDefinitions with answer lists from

        “Must Support” flags very loosely defined.

       Next steps

        Publish universal IG pending final Tx error resolutions.

        Streamline adoption/alignment of universal guidance with other IGs.

        Follow up on “Must Support” usage, consider providing additional guidance for adoption into US-realm.

Clinical Reasoning


       This track focused on 3 main areas:

        How can we use bulk data specification to support quality reporting at scale

        Continuing to test STU3 and R4 measure specifications

        Testing PlanDefinition use cases including Clinical Guidelines, decision support, and public health






        Dynamic Content Group

        Dynamic Health IT






        Motive Medical Intelligence



        The Joint Commission


Notable Achievements

       For measure testing:

        Successfully tested the following measures

        CMS124, 125, 130, 165 in STU3

        Testing identified issues with CMS104 and 108 in STU3

       For decision support

        Successfully tested Opioid Recs #10 and #11 STU3 and R4 with the patient view hook

        Identified issues with usage in the order-select hook (via the CDS Hooks sandbox)

       For bulk data import, identified a path forward,

        Will be using a file of Bundles, one bundle per Measure

        Successfully tested with “proxy” servers that provide bulk data import support on top of a FHIR server generically:$import


Discovered issues/Questions:

        Discussions with public health: ESRD is currently using PlanDefinition, trying to run those definitions on the Clinical Reasoning reference implementations

        Issues with running R4 measure and plandefinition content, addressed several, found more

        Containerized reference implementations were helpful overall


Now what:

       Incorporate feedback on bulk data usage to the DEQM Implementation Guide

       Incorporate feedback on authoring to the QM Implementation Guide

       Pull implementation guide and connectathon feedback in to R5 specification

       Continue expanding supported measure packages and test cases



Cross Org App Access



       EMR Direct



       Health Gorilla

       Community Care HIE




       One Medical


       Test scalable ecosystem trust models for security and privacy, enabling cross-organization query and reusable credentials

       Generate discussion about how to recognize certain classes of users, clients, or servers, reducing friction in ecosystem use of FHIR and working to develop best practices

       Discuss policy issues

Notable Achievements

Multiple parties used JWT-based authentication in their FHIR clients to successfully authenticate to FHIR servers also supporting evaluating the JWT in a token request. Here is one such JWT for those who would like to investigate further:


We had even more interest in policy breakout sessions than technical ones at this connectathon. This level of participation suggests community readiness for narrowing down an app validation process and corresponding certificate details.

We also tested trusted dynamic client registration, and writing to and reading from the Carequality directory. Trusted dynamic client registration is intended to accompany JWT-based authentication in a complete trusted workflow which also includes a validation certificate on the server side.

Discovered issues

       Required scopes for client credentials inconsistent across servers

       Header handling not fully spec’d (should ignore on back end; accept back should be application/json)

       Server advertisement of UDAP support not well supported; consider hosting the certificate at .well-known/udap and including in metadata a list of available endpoints signed by certificate

       Certificate-based client registration and the corresponding server endpoint is not yet supported by many, but based on this weekend’s conversations, many more see the potential benefits and added security, and are interested in building support 

Next steps

       Additional development of profile into a more formal IG to provide more specific workflow details

       Invite implementers on client and server sides to test use of certificates; developer support materials and a collaborative opportunity may be helpful

Da Vinci Alerts


Da Vinci Payer Coverage Decision Exchange

SUMMARY - When a patient moves from one payer to another, care continuity can be affected by payer continuity of coverage. CMS has indicated that they will begin to require the transfer of data about all the active treatments from the prior payer to the new payer and any relevant additional data to optimally continue appropriate care in real time to avoid any gaps in care or avoidable morbidity, mortality or utilization. This use case applies initially to payers under select Medicare and Medicaid plans.

Payer Coverage Decision Exchange FHIR Approach:

1. Payer-to-Payer Exchange (Non-Member Authorized) CommunicationRequest OR Patient-Authorized Payer-to-Payer Exchange (OAUTH)

2.Communication OR Send Active Treatment


1. Coverage Information Exchange (PDEX)

2. CarePlan (Care Management, LTSS)

3. Prior Authorization (PriorAuth)

4. Attachments

5. ???




CDEX Event Code


Patient Examples

1 – Patient found, active CarePlans present, bundle created but not sent


Patient found, active treatment present. Bundle in process, not yet sent.

Joe Smith

1 -Patient found, active CarePlans present, bundle sent


Patient found, active treatment present, bundle included in message.

Joe Smith

2 – Patient not found

not done

Patient not found.

Carrie Abubu

3 – Multiple patients found, need more information

on hold

Patient not unique, provide additional data.

Jeff Smith 1/12/1980, 74047

Jeff Smith 1/12/1980, 20002

4 – Patient found, treatment data present, no active treatment


Patient found, no active treatment.

Jessica Taylor

5 -- Patient found, treatment status unknown


Patient found, treatment status unknown




CDEX Event Code


Patient Examples

1 – Patient found, active CarePlans present, bundle created but not sent


Patient found, active treatment present. Bundle in process, not yet sent.

Joe Smith

1 -Patient found, active CarePlans present, bundle sent


Patient found, active treatment present, bundle included in message.

Joe Smith

2 – Patient not found

not done

Patient not found.

Carrie Abubu

3 – Multiple patients found, need more information

on hold

Patient not unique, provide additional data.

Jeff Smith 1/12/1980, 74047

Jeff Smith 1/12/1980, 20002

4 – Patient found, treatment data present, no active treatment


Patient found, no active treatment.

Jessica Taylor

5 -- Patient found, treatment status unknown


Patient found, treatment status unknown




Report Out and Connectathon Info:

Da Vinci Payer Data Exchange



       This track focused on the challenge of handling Payer-to-Payer exchange without Member Authorization. Some plans do not issue members with coverage information that is specific to an individual member. For example for families the subscriber is the most granular identifier. However all plans use an internal unique member identifier.



       Significant discussions took place to clarify how payers could support a coverage based search for a unique member. A request should include any, or all of the following, with a hierarchy of preference:: Member Identifier, Subscriber id, Plan/Group Identifiers. The query must provide Beneficiary information as a Patient resource reference. A question for consideration is whether plans should return information that include a unique member identifier of some type when a unique match to a member is successfully achieved.

       Report Out Deck:

       Next steps: Test Coverage Search and inclusion of Coverage resource in communication bundles when unique Member Id at target plan is not available.

Da Vinci PDEX Drug Formulary

       The Drug Formulary track provides patients with information about what drugs are covered by different health plans.  This includes whether the drug requires prior authorization, has a quantity limit, or is part of a step therapy.


        Dave Hill, MITRE

        Jake O’Donnell, MITRE


        Prime Therapeutics


        Draft IG is available:

        Reference client:

        Client code:

        Reference server:

        Server code:


        Now what?

        Complete ballot reconciliation and schedule block vote


Da Vinci PDEX Plan-Net

        The Plan-Net track aims to allow information about providers and healthcare organizations to be exchanged via FHIR. This includes contact and accessibility information (specialty, office hours, languages spoken), and information about the relationships between providers, organizations, and payers.


  • Stephen MacVicar, MITRE
  • Dave Hill, MITRE




        Now what?

  • Gather feedback on the IG
  • Add more functionality to the reference implementations

          Add pharmacy data and location-based searches to server

          Add more complicated searches to client

Da Vinci Prior Authorization



What the track trying to achieve:

To bring together people working with different classes of medical and personal health devices and different uses to try out information exchanges, code and test, and trade knowledge, code, and other resources. Work on next versions of HL7 FHIR Implementation Guides for Personal Health Devices and Point-of-care Devices.


Participants :

Breakthrough Solutions Foundry: Todd Cooper

Lamprey Networks / Continua / Personal Connected Health Alliance: Brian Reinhold

Medtronics: Myron Finseth

Draeger Medical: John Dyer

Philips Healthcare: Stefan Karl, Ana Kostadinovka, John Rhoads (track lead)

HL7 Japan: Masaaki Hirai



Division of labor plan for IG revisions

Device or simulation data from Draeger and Philips to LNI server, text dumps

Reference results too much to include here - see attachment on Devices Track page


Discovered issues:

Need to support search by parent in Device resource

Need implementer-directed outreach and tutorial material

Now what?

More prototyping and testing

Another iteration of both implementation guides to



Direct / Certificates

This track’s Scenario 1 explores the use case of sending a FHIR query over a Direct message and receiving the FHIR response back within a Direct message.





       EMR Direct


Notable achievements


Testers used the latest version of the Context IG to encapsulate a FHIR query and response into a Direct message transaction (messages sent and received both contained the same transaction ID). 


A newer, related track, Cross Organization Application Access, expands on the certificate-backed use cases initially tested within Scenario 2 of this track. Please refer to  Cross Organization Application Access summary for additional information.

DME and Home Health Orders

We successfully completed the goal of testing the scenarios 2 and 3.

Participants: David Bruinsma Colonial Med

Gary Bartlett, Brightree

Rasiel Rodriguez, Brightree

Hiren Patel, Brightree

Tom Bruinsma, Colonial Med

Nandini Ganguly, Scope Infotech Inc

       Notable achievements:

        Created a working fhir server capable of receiving a ServiceRequest bundle using a custom operation to populate related resources$submit



Evidence Based Medicine


        The primary goal of the EBM Track was to commit the Evidence Resource (and accompanying Clinical Reasoning explanatory pages, EvidenceVariable Resource, Statistic DataType and OrderedDistribution DataType) to the R5 FHIR build.  

        The secondary goal was to prepare recommendations for modification of Group Resource to support Evidence Resource usage.


  • Brian Alper, EBSCO Health, Track Lead
  • Khalid Shahin, EBSCO Health
  • Harold Solbrig, Johns Hopkins University
  • Richard Zhu, Johns Hopkins University
  • New friends introduced:

          Matt Elrod, MaxMD

          Alexander Goel, Cancer Care Ontario

          Rich Boyce, University of Pittsburgh

        Notable achievements:

          add “information” to Group.type code list

          add “Evidence” to Reference list in Group.member.entity

          add new element: Group.characteristicCombination with code datatype and code either intersection (for grouping characteristics with AND) or union (for grouping characteristics with OR)

          add valueExpression to value[x] list in Group.characteristic.value[x]

  • Created 7 variants for how to handle “characteristics = A or B or C” concept instead of “characteristics = A and B and C”

          Suggested approach:

          6 other variants considered - Old way ,   Sept. 10 way ,   Alfonso (has required count) ,   Brian’s old way ,   Characteristic.valueReference (ValueSets) , and   Harold doesn’t recommend way .

        Now what?

  • Review materials in R5 build to prepare phase 1 (use of Evidence Resource) for Notice of Intent when R5 is ready for balloting - informative ballot
  • Prepare for Wednesday Q2 meeting to discuss Group Resource across multiple work groups

FHIRcast Track



FHIRcast is a an HL7 specification providing modern, simple application context synchronization. Following our May, 2019 STU1 ballot, priorities for the project and this connectathon are primarily three-fold:

1)      Confirm changes to the base specification following the ballot, and before HL7 publishes.

2)      Testing, validating and gaining implementation experience with our draft websockets specification .

3)      Experiment with the real-time, interoperable exchange of draft measurements.

Five developers participated in the track this weekend, including representation from Elsevier, Epic, Philips, and Nuance.


       1 paragraph: notable achievements



Overall, we focussed in on websockets and gained some solid implementation experience. From Philips, Bas’s implementation not only supported FHIRcast’s recommended security layer of SMART on FHIR (including the SMART EHR launch flow, subscription creation and notifications), but also used websockets to synchronize two applications. George from Nuance, supported our track remotely. Further, both Elsevier and Epic implemented and tested our draft websockets spec.


Implementations & achievements

Paul from Elsevier experimented with a newly written basic websockets client and successfully subscribed to the hosted, Nuance-provided Hub . Will, from Epic, added websockets support to both the reference implementation’s Hub and client and successfully integrated the RI client with Nuance’s Hub using our draft websockets spec. 


Bas’ work is licensed as opensource on the PhilipsOnFhir FHIRcast github repository .

Will’s websocket updates to the FHIRcast reference implementation currently live here .


Following our additional implementation experience & discussion, we’re removed the intent verification step from the websockets channel. This simplifies the spec and reduces implementer burden.

Now what?

1)      Websocket support is important for FHIRcast implementers! This fall, we’ll refine and incorporate our draft websocket write-up in the FHIRcast specification at: . We’ll also pursue a small, targeted STU2 ballot within HL7 to ballot this content into the base specification.


2)      What about draft measurement exchange? This more advanced and less specified use-case did not see implementer experimentation this weekend. We need more implementer experience to refine and standardize this functionality.




International Patient Summary


LOINC - InVitro Diagnostic


mCODE Cancer Interoperability


mCODE™ —short for Minimal Common Oncology Data Elements—is an initiative intended to assemble a core set of structured data elements for oncology electronic health records (EHRs). The mCODE connectathon track aimed to test and gather feedback on the feasibility of implementation mCODE, collect feedback on improvements to the guide, and seed new ideas on potential future applications based on mCODE.


        Participants (with logos if you have time and energy)

  • Mark Kramer (MITRE)
  • Halina Labikova (Varian)
  • Hugo Leroux (CSIRO)
  • Alejandro Metke (CSIRO)
  • Chris Moesel (MITRE)
  • Robinette Renner (NMDP/CIBMTR)
  • Tatyana Sandler (Flatiron Health)
  • May Terry (MITRE)


        Notable achievements

  • Cancer Care Ontario translated their lung surgery form to mCODE elements.
  • MITRE developing a FHIR “Shorthand” grammar which enables easier representation of FHIR profiles and examples.  Created a first-pass translation of  the mCODE track example clinical scenario to the shorthand representation as a prototype.
  • CIBMTR created a first-pass mapping of mCODE to their Hematopoietic Cellular Transplantation (HCT) form and using the MITRE-created CIMPL modeling tool to create a FHIR Implementation Guide.
  • CSIRO created a first-pass mapping of mCODE to one of their genomics forms and created mCODE conformant examples for upload to the mCODE HSPC Sandbox FHIR server.
  • Varian successfully imported an STU3 version of the mCODE ECOGPerformanceStatus StructureDefinition into their clinical decision support software, populate a form to capture an ECOGPerformance score and dynamically generate a FHIR Observation instance.


        Issues and questions

  • Captured in a dedicated Confluence page of mCODE Issues and Group Notes here .
  • The overall issues were 1) need to support internationalization (mCODE is based on US Core), 2) more specificity on how to deal with pre-coordinated and post-coordinated concepts for several profiles (e.g.: PrimaryCancerCondition.code and body structure - is specifying Condition.bodyStructure needed if the term is already included in Condition.code?)


        Next Steps

  • Reported issues by participants will be added to the GForge issue tracker for further investigation.



Mobile Health Data Exchange

       The Mobile Health Data Exchange track had an engaging connectathon and set of breakout  with a focus on capture of resource samples and exchange methods of heart rate, blood pressure data, steps, and calories from various mobile health devices. Participation ranged between 6-10 participants with continual interaction between related tracks include Devices and Carin Blue Button.

Participants included:

       Keith Boone (Audacious Inquiry)

       Nathan Botts (Westat)

       Tracy Okubo (ONC)

       Matt Holland (Cambia Health Solutions)

       Ravi Kondiparthr (Cambia Health Solutions)

       Ben Benazzi (AMA)

       Monique van Berkum (AMA)

       James Shalaby (AMA/Elimu)

       Eric Soto (Georgia Tech)

       Myung Choi (Georgia Tech)

       Brian Reinhold (Lamprey Networks)

       John Rhoads (Phillips)

       Martin Rosner (Phillips)

       +3 (Phillips)

  Two outbreak sessions were held:

       Saturday @ 3pm with presentations from:

        Brian Reinhold presenting on the Continua/PCHA Personal Health Device Implementation Guide

        Monique van Berkum from the American Medical Association presenting on the self-measured blood pressure using a remote monitoring device (SMBP) use case for standardization.

       Sunday @ 9am with a presentation from:

        Eric Soto of Georgia Tech presenting on the Open mHealth standardization work

Outcomes and Next Steps

We collected about 50 resources in about 6 different categories from multiple sources, and are currently working to compare differences across them.

Patient Merge


Patient Track


The Patient Track continues to be a helpful entry point for those that are new to the FHIR community.  It provides a gentle onboarding for newly created FHIR Servers and Clients, giving them the confidence and knowledge needed to move on to other use cases and tracks.


Participants :

       Lee Surprenant, IBM

       Vania Manzelli, Nuvyta SRL

       Stephen Spicer, Encompass Health

       Zafeerah Siddiqua, Blue Cross Blue Shield Association

       Ron Shapiro, Qvera


Achievements :

All participants found success in performing the CRUD scenarios outlined in the Patient Track.  In addition, the Touchstone testing environment continues to prove to be a valuable tool for helping the developers of new FHIR Servers achieve immediate success.  By working through the TestScripts and getting them to pass, other FHIR Clients were then able to easily and quickly interact with those FHIR Servers without any issues.


Cdex Payer / Provider Information Exchange Track



The primary goal of the track was to exercise the CDex workflows, which are designed to enable medical record "chart chase" requests and additional information queries from payers to providers, primarily using POSTs of the CommunicationRequest and Communication resources.


Participants included the following:


Diameter Health – Karen Zapatta

Deloitte – Russ Ott, Chris Brancato

Availity – Henry Meyne, Kyle Zumstein

Anthem – Christol Green

Blue Cross Blue Shield AL – Kevin Lambert, Clarissa Winchester, Morrey Payne

Accenture – Ozair Bajwa

Throughout the connectathon we worked with the HSPC (Logica) Sandbox to populate data and test the CDex use cases, as well as refining the capabilities of the sandbox to better support support CDex use cases. Submitted requests for documentation using the CommunicationRequest resource, and responded with Communication resources including CCDA payloads and references to the corresponding CommunicationRequest.

A key outstanding challenge is the need to figure out how patient discovery and identity will be communicated reliably in these transactions.  Generally payers work with a Subscriber ID at the family level, and require First Name, Last Name, and DOB to identify a unique patient. Should a patient discovery query occur first?

Our next steps are to continue testing with a focus on patterns for identifying patients.

Post Acute Care

The primary goal of the Post Acute Care track was to validate the FHIR Implementation Guide and Reference Implementation for the CMS Data Element Library (DEL). The DEL is a centralized resource for CMS assessment forms for post-acute care.



MITRE: Dave Hill, Sean Mahoney, Tim Shaffer, Jake O’Donnell

Regenstrief: Daniel Vreeman, Swapra Aphyankar

Lantana: Zabrina Gonzaga

Max Md: Matt Elrod

Encompass Health: Steve Spicer


The main thing learned at this connectathon were the opportunities to coordinate similar efforts to develop FHIR specifications for CMS assessment forms. Through demonstrations and discussions with participants, we were able to enhance the FHIR IG to include more comprehensive mappings on the CMS assessment forms and sections to the corresponding LOINC codes. We were also able to generate new interest in the PACIO workgroup.


The next steps for this track are the continue the discussion started at the connectathon with other stakeholders in post-acute care, solicit new members in PACIO workgroup and continue the work to increase the interoperability of transition of care health data exchange.




Public Health

        What was the track trying to achieve:

  • Electronic Case Reporting (eCR):

          Nail down Electronic Reporting Surveillance Distribution (eRSD) specification

          PlanDefinition, Subscription, etc.

          Work with Clinical Reasoning

          Meet with DaVinci about Messaging/Task

  • Vital Records
  • Bidirectional Services e-Referrals (BSER)


  • Ray Humphrys, Altarum Institute
  • Michael Yaskanin, Altarum Institute
  • John Loonsk, APHL/ The Johns Hopkins University
  • Timothy Davison, California Department of Public Health
  • Alex Goel, Cancer Care Ontario
  • Arunkumar Srinivasan, CDC
  • Srinath Remala, CDC
  • Laura Conn, CDC
  • Alaina Gregory, CDC
  • Cindy Bush, CDC
  • Shailendra Bajracharya, CDC/Katmai Government Services
  • Kate Brett, CDC/NCHS
  • Rhonda Smith, DC Vital Records
  • Reginald Syas, DPH Office of Public Health Informatics
  • Eric Trinh, Genesis Systems, Inc
  • Michael Valle, Georgia Department of Public Health
  • Chris Harrison, Georgia Dept of Public Health
  • Myung Choi, Georgia Tech Research Institute
  • Sean McIlvenna, Lantana Consulting Group
  • Sarah Gaunt, Lantana Consulting Group
  • Kellie Broxton, LexisNexis
  • Adam Holmes, MITRE
  • Christine Smith, Northrop Grumman
  • Matt Krystof, Northrop Grumman
  • Marcelo Caldas, Northrop Grumman
  • Rishi Tarar, Northrop Grumman
  • Wei Ding, The Medical University of South Carolina
  • Nar Wang, The Medical University of South Carolina
  • Peter Krautscheid, The MITRE Corporation
  • Maryam Garza, UAMS

        Notable achievements:

  • eCR: Met with Clinical Reasoning (Bryn Rhodes) to discuss the use of PlanDefinition for eRSD, figured out how to simplify and streamline the current PlanDefinition. Updated the profile and published it in the eCR IG.
  • eCR: Sean McIlvenna demonstrated the eRSD Service (subscription management service to support distribution of artifacts to EHR implementers)
  • eCR: Met with DaVinci to discuss the use of Messaging/Task - eCR uses Messaging and Task and DaVinci are trying to determine whether Messaging is the right path for them (for alerts) and to reinforce the commonalities between the Alerts paradigm and Public Health needs
  • eCR: Collaboratively working with Sean, Sarah and John to develop diagrams that help clarify the relationship between eCR, RR and eRSD. Existing diagrams need to be updated. Considering including the existing diagrams (once updated) in the eCR/RR IG.
  • eCR: Sean had discussions with James about desired changes to HAPI. Came up with a plan for what changes to make. James agreed to review the pull-requests/changes when they are done, and would accept the changes.
  • eCR: Sean reviewed plans for changes to subscriptions in HAPI with Rick and others at the Connectathon.
  • eCR: Sean began implementing changes as discussed with James. Not complete, but made progress.
  • BseR: AMS described and drew diagrams for  the new specification version and described the changes to the BseR IG
  • BseR: Matt and Wei worked on the connectivity between YMCA(NG) and MUSC (Medical University of South Carolina)
  • BseR: Matt’s FHIR Messaging service was able to receive and perform $process-message operation to consume the FHIR Message bundle.
  • BSeR: Rishi(YMCA/NG) met with Davinci to understand the scope and use of FHIR Messaging
  • BSeR: Wei/Nar from MUSC  were able to construct a BSeR Referral Request and were able to POST to YMCA endpoint.
  • BSeR: Christine confirmed that the YMCA RedCAP was able to receive the Referral and display it on the screen.
  • BseR: The team met with AMS to discuss the Task lifecycle from the new BSeR version of the IG
  • FSN: Shu worked on the plandef for FSN RSV Valuesets
  • FSN: RIshi discussed  with James on HAPI changes , for the Bulk FHIR capability. RIshi to try out the latest changes on Bulk FHIR.
  • FSN: Attended DaVinci breakouts for Notification and FHIR Messaging.
  • FSN: For Davinci alerts Shu Exercised the sender and receiver roles using both Communication and Messaging paradigms for evaluation.
  • VRDR: Able to successfully test bi-directional exchange. Example, state EDRS system was able to send FHIR death certificate message to NCHS, NCHS sent coded cause of death, and initial EDRS was able to consume coded cause of death.
  • VRDR: Successfully tested state-to-state exchange, Michigan EDRS sent FHIR death certificate message to DC EDRS and FHIR message was successfully consumed.
  • VRDR: California cancer registry received a valid FHIR death certificate message from Georgia.
  • VRDR: DC, GA, NY was able to send FHIR message to NCHS through STEVE API.  Success on response received.  MS was able to do bi-directional.
  • VRDR: Confirmed that NY was able to receive FHIR Death Certificate message with STEVE response that it was received.


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

        1 paragraph: discovered issues / questions (if there are any)

        1 paragraph: now what?




        Continue vetting the draft specification by implementation, particularly population and extraction

        Generate additional example instances for inclusion in the specification


        Lloyd McKenzie

        Paul Lynch

        Ana Kostadinovska


Noteable achievements

       One new participant was able to successfully map their questionnaire logic to SDC over the course of one day

Now what?





See also:



        Brandon Pollett (Microsoft)

        Brian Wright (Mayo)

        Gino Canessa (Microsoft)

        Josh Mandel (Microsoft)

        Martin Tran

        Michael Donnelly (Epic)

        Pascal Pfiffner (Apple)

        Rick Geimer (Lantana)

        Shilpy Sharma (HSPC)

        Steven Gangstead (T-System)




         Was able to connect to the Cerner server, create subscription, and get notified.

         Was able to connect to the argonaut test server, create a subscription (still working on notification)

         Created a demo rest-hook subscription client using Java, Spring, and HAPI to receive JSON content and convert it to it's XML representation

         Discussed requirements and use cases for the email channel


         First day, encountered network issues getting notifications out of the firewall

         Successfully Integrated with the reference server / client

         Successfully accepted a subscription from Lantana and posted notifications back


         We modified our EVolvED app to get topics from the subscription server proxy, create a subscription, receive handshakes and notifications for each subscription, and display the status & count of notifications. We also did it all with auth (we generate a JWT for each subscription so that header only has access to that one subscription).



         Our team has created a mobile client that can search for Topic, create a Subscription (at least on Gino's server) and receive the handshake Bundle on a separate server that we stand up. The subscription we create contains headers that our standup server can then use to forward the Subscription ping to the mobile client. This last part has not been fully implemented yet.


         We did a rough draft of a Subscription client with REST hook notification. The history Bundle used for the notification looked heavy, but in practice it was easy to implement since it's a valid FHIR resource.

Mayo Clinic

         Successfully Integrated with the reference client

         Successfully tested our server with Argonaut scenario 1


         Subscription for merge/unmerge: This is hard. Discussion is continuing, but many servers handle this in different ways. The Topic will likely need to be flexible if we want to be able to send alerts to apps when a merge or unmerge happens.

         Possibility of using (replaces and replaced-by)?

         Gap for servers that actually delete the merged-away patient.

         Trigger off $merge operation?

         Only works for merge. What about unmerge?

         Not all systems will use a FHIR operation.

         Trigger off provenance?

         One gap identified: Do we need to allow a criteria for an operation success (or failure)

         Need to make sure line is crisp between CDSHooks and Subscriptions. EG: this is not a UI event.

         Related discussions:

         Additional discussion around email

         Added links to the existing GForge:

         What should and shouldn't be within the specification? How would we scope this channel?

         Define basics, allow other use cases to extend beyond that basic case.

         Public Health use cases use this today, and have requirements in production today (non-PHI)

         We should also talk to CareEvolution about their use cases (they represented at previous tracks)

         Minor issue around Topic matchType. GForge logged here:

         Scalability discussions.

         Concerns around how event counts work, how to scale this up for pure FHIR servers. Distributed servers: it's hard to have a single atomic event count.

         If you support history/version the subscription, sending out 20k different alerts might cause you to have 20k versions of the subscription.


         Not a lot of feedback today/this round. Argonaut reference server added capabilities, but no one consumed (yet)

         General changes:

         Older way felt like the power was on client side (even if no one would have implemented it all), new power is that it can be defined in IGs and you can declare topics that follow that/advertise support.

         Core didn't change that much, the how to subscribe is the primary change and has been good.

         Easier to explain to stakeholders what topics you support, the concept, and how to create subscriptions.

         Thinking through future use cases, most fit in the new version of the spec.


         Some variables are can be used to evaluate which events should be delivered to a given subscription

         these variables also make sense in FHIR search

         If we add support for variables to FHIR search, we'll be able to re-use this capability in subscription

         Other use cases would require new events   to fire, like "I want to be notified when there's an appointment within 3 days from now."

         This goes beyond current Subscriptions scope

         Leave it out for now and address in future versions. May be too much to attack for now.

         Tracker to document what fields a client should and should not update:

Now What

         Continue discussions around patient merge and unmerge. This is a real issue today in production systems, we should figure out how to solve on the R5 draft and then determine how to merge back as needed to other versions? Likely dependent on the work PA is doing to define merge requirements.

         Continue getting input on the scalability issues for subscription. We need to finalize this before finalizing the standards.

         Continue discussion on Web Sockets.

         See also some chat:

         Still a lot to do to work through security

         Who can read a subscription? (there's a possible auth header)

         Who can modify a subscription?

         What does it mean when a subscription is created on behalf of a user (SMART user/* scopes)

         Need to discuss if we need a new bundle type in order to do the subscription notification use type.









The Terminology Services track was active on multiple fronts.  A particular focus for this time was Terminology Services Support for SNOMED CT.  We held a breakout on this topic early in the day on Saturday with good participation.  Topics discussed included terminology server support for SNOMED CT:


        Use case presented for using post-coordinated expressions as codes in FHIR resources

        Discussed issues and proposed a tentative plan for moving forward toward supporting this in a meaningful and useful way

       Global Patient Set (GPS) - i.e. “free set”

        Multiple issues considered

        Should this be represented as a separate code system fragment? (for non-member countries?)

        Or as value set(s)? (for member countries?)

        Property to indicate that a concept is a member of the GPS?

        Plan further consideration and resolution of the above issues

       CIMI extension

        We (e.g. Grahame) can’t “publish” an extension alone as a distinct entity - an edition is needed

        Can we use the Global Patient Set (foundation metadata concept) concept to identify the “edition” (possibly not independently published)?

        Do we need a refset?

        Will discuss further with SNOMED International to arrive at an acceptable solution


Touchstone and independent testing of multiple terminology servers was performed (see ConMan).




A breakout session was held on these topics questions/issues:

       Translation and addition of codes by a FHIR server for a resource instance

        Based on concept maps (explicit or implicit)

        This could be useful for adding codings that are needed to support particular profiles (e.g., adding LOINC “magic value” codes to Observation to conform with the Vital Signs profile, providing SNOMED CT codes for legacy Read coded data)

        Suggested exploring use of additional parameters in application registration to be able to support this

       Translating to “upcode” specific (i.e. specialty) concepts to more general concepts from a specific value set (e.g. for general practice) based on the code system hierarchy

        The $translate operation can already support this in principle

        Servers currently do not


More terminology server testing.





The goal of the connectathon was to finalize/stabilize the specification format/syntax  of the message, segment, data type, and code system mappings to enable mapping tools to ingest that specification and generate maps that can be used to immediately map a v2 message into FHIR message bundle, and/or enable the mapping tool user to tailor that map to local requirements.  The ADT^A01^ADT_A01 message was used with a core set of segments to go through top to bottom to validate this.


In the process we achieved the following:


       Refined the condition syntax that also expressed in ANTLR to support validation of condition syntax.

        Updated all conditions to conform to the agreed to syntax.

       Established a syntax to reference links across resources to enable, e.g., a PV1/PV2 yielding an Encounter to reference the correct Patient from that Encounter.

       Agreed to guidance on generating <resource>.id values to maintain unique linkages.

        This will be up to the creator of the FHIR elements, using the FHIR Bundle of type transaction that then may be used as a message, or passed on to a server to then ingest it as they would other incoming resources (including resolution of duplicates, id values, etc).  If the mapper is the same as the FHIR server, they may by-pass the actual creation of the Bundle.

       Microsoft shared their extraction tool to get the Google Spreadsheets initially in Confluence and working on getting this into GitHub and extract from there.

       Qvera and Robert Worden shared some of their tooling progress, where most are working on implementing the conditions.

       Updated the specifications to separate proposed extensions from existing attributes and extensions.

       Cleaned up the specifications with the series of warnings generated by the mapping tools.


Overall made good progress to stabilize the specification so mapping tools can start to ensure they can generate conforming FHIR messages from sample v2 messages.


Next step is continue to build out the content of the mapping specifications and establish test v2 messages with benchmark FHIR message to validate accuracy of mapping tools.