https://wiki.hl7.org/w/api.phpHL7Wiki - User contributions [en]2024-03-19T04:02:35ZUser contributionsMediaWiki 1.33.0https://wiki.hl7.org/w/index.php?title=ITS_ConCall_Minutes_20190709&diff=166311ITS ConCall Minutes 201907092019-07-09T20:00:25Z<p>Bpech: </p>
<hr />
<div>[[Category:ITS Minutes 2019]]<br />
Return to: [[ITS_WG|ITS Main Page]] ><br />
[[:Category:ITS_Minutes|ITS Meeting Minutes]] ><br />
[[:Category:ITS_Minutes_2019|2019]]<br />
<br />
[[:Category:ITS Minutes |Return to ITS Meeting Minutes]]<br />
<br />
<br />
The minutes for this call can be found over in Confluence.<br />
<br />
https://confluence.hl7.org/display/ITS/Ad-hoc+Call+-+July+9%2C+2019<br />
<br />
<br />
[[:Category:ITS_Minutes_2019|2019]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=ITS_ConCall_Minutes_20190709&diff=166310ITS ConCall Minutes 201907092019-07-09T19:54:39Z<p>Bpech: </p>
<hr />
<div>[Category:ITS Minutes 2019]]<br />
Return to: [[ITS_WG|ITS Main Page]] ><br />
[[:Category:ITS_Minutes|ITS Meeting Minutes]] ><br />
[[:Category:ITS_Minutes_2019|2019]]<br />
<br />
[[:Category:ITS Minutes |Return to ITS Meeting Minutes]]<br />
<br />
<br />
The minutes for this call can be found over in Confluence.<br />
<br />
https://confluence.hl7.org/display/ITS/Ad-hoc+Call+-+July+9%2C+2019<br />
<br />
<br />
[[:Category:ITS_Minutes_2019|2019]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=ITS_ConCall_Minutes_20190709&diff=166309ITS ConCall Minutes 201907092019-07-09T19:48:49Z<p>Bpech: </p>
<hr />
<div>[Category:ITS Minutes 2019]]<br />
Return to: [[ITS_WG|ITS Main Page]] ><br />
[[:Category:ITS_Minutes|ITS Meeting Minutes]] ><br />
[[:Category:ITS_Minutes_2019|2019]]<br />
<br />
[[:Category:ITS Minutes |Return to ITS Meeting Minutes]]<br />
<br />
<br />
The minutes for this call can be found over in Confluence.<br />
<br />
https://confluence.hl7.org/display/ITS/Ad-hoc+Call+-+July+9%2C+2019<br />
<br />
<br />
<br />
[:Category:ITS Minutes |Return to ITS Meeting Minutes]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=ITS_ConCall_Minutes_20190709&diff=166308ITS ConCall Minutes 201907092019-07-09T19:43:21Z<p>Bpech: Created page with "[Category:ITS Minutes 2019]] Return to: ITS Main Page > ITS Meeting Minutes > 2019 :Category:ITS Minutes..."</p>
<hr />
<div>[Category:ITS Minutes 2019]]<br />
Return to: [[ITS_WG|ITS Main Page]] ><br />
[[:Category:ITS_Minutes|ITS Meeting Minutes]] ><br />
[[:Category:ITS_Minutes_2019|2019]]<br />
<br />
[[:Category:ITS Minutes |Return to ITS Meeting Minutes]]<br />
<br />
<br />
The minutes for this call can be found over in Confluence.<br />
<br />
https://confluence.hl7.org/display/ITS/Ad-hoc+Call+-+July+9%2C+2019</div>Bpechhttps://wiki.hl7.org/w/index.php?title=IT_AdHoc_20190708&diff=166307IT AdHoc 201907082019-07-09T19:37:56Z<p>Bpech: </p>
<hr />
<div>[Category:ITS Minutes 2019]]<br />
Return to: [[ITS_WG|ITS Main Page]] ><br />
[[:Category:ITS_Minutes|ITS Meeting Minutes]] ><br />
[[:Category:ITS_Minutes_2019|2019]]<br />
<br />
[[:Category:ITS Minutes |Return to ITS Meeting Minutes]]<br />
<br />
<br />
<br />
<br />
The minutes for this call can be found over in Confluence.<br />
<br />
https://confluence.hl7.org/display/ITS/Ad-hoc+Call+-+July+9%2C+2019</div>Bpechhttps://wiki.hl7.org/w/index.php?title=IT_AdHoc_20190708&diff=166306IT AdHoc 201907082019-07-09T19:00:37Z<p>Bpech: Created page with "The minutes for this call can be found over in Confluence. https://confluence.hl7.org/display/ITS/Ad-hoc+Call+-+July+9%2C+2019"</p>
<hr />
<div>The minutes for this call can be found over in Confluence.<br />
<br />
https://confluence.hl7.org/display/ITS/Ad-hoc+Call+-+July+9%2C+2019</div>Bpechhttps://wiki.hl7.org/w/index.php?title=WGM_information&diff=161425WGM information2018-09-18T19:33:53Z<p>Bpech: </p>
<hr />
<div>*Links to WG agendas and documents are posted here so that attendees and interested persons can review what is being worked on at the Meeting. This also acts as a snapshot to see which WGs are meeting (or not planning to meet). Please add or update your Work Group's agenda and papers as they become available.<br />
**Previous Working Group Meeting information links have been moved to the [[:Category:WGM_agendas|Category page for WGM agendas]] for reference. <br />
*First-Timer information here: [http://www.hl7.org/events/workgroupmeetings.cfm What is a "WGM"?]<br />
*Information for Auxiliary attendees of the WGM is available here: [[HL7 Auxiliary]]<br />
*WGM Attendee [[Lost and Found]]<br />
*Mobile On-Site App: <!--[http://eventmobi.com/may2014wgm/ here]--> TBD<br />
*[http://www.hl7.org/events/working_group_meeting/2018/05/ WGM homepage]<br />
<!--*[http://www.hl7.org/documentcenter/public/brochures/wgm/Cologne-wgm_web.pdf Event Brochure]--><br />
==Travel, Transportation and other information==<br />
*See the [http://www.hl7.org/events/working_group_meeting/2018/05/] page on the 2018May WG Meeting site<br />
<!--**Early Bird registration open until December 30 2014--><br />
<!--**[http://www.hl7.org/events/wgm012015/?ref=banner Online registration] is open! Onsite registration will be open Sunday, January 18, 2015 from 8:30 am – 5:00 pm --><br />
<br />
==Agendas for 2018 September WGM, September 29 - October 5, 2018 Baltimore, Maryland, USA ==<br />
===Technical Steering Committee===<br />
<br />
===Standards Governance Board===<br />
<br />
===Steering Division agendas: ===<br />
Clinical SD - <br />
Infrastructure SD - <br/><br />
Administrative SD - <br/><br />
Organizational Support SD -<br />
<br />
===Work Groups / other (project) Groups===<br />
* Anesthesia - <br />
*[[Architecture_Board | Architecture Board (ARB)]] - [https://confluence.hl7.org/display/ARB/2018-09-29+ARB+Baltimore+WGM+Agenda ARB Baltimore WGM agenda]<br />
*Arden Syntax - <br />
*Attachments - [http://www.hl7.org/documentcenter/public/wg/ca/minutes/Baltimore%20HL7%20AWG%20Agenda.xlsx Baltimore Agenda]<br />
* BR&R - [[Wc 2018-05-14 BR&R WG Meeting | Agenda May 2018]]<br />
* Clinical Decision Support - [http://wiki.hl7.org/index.php?title=CDS_WG_Agenda_2018-09 CDS September WGM]<br />
* Clinical Genomics - [http://wiki.hl7.org/index.php?title=CG_Working_Group_Meeting_Agendas All WGM Agendas] and [http://wiki.hl7.org/index.php?title=File:HL7_WGM_September2018_-_Clinical_Genomics_Agenda.pdf Baltimore Agenda]<br />
* CIMI - <br />
* Clinical Interoperability Council - [http://www.hl7.org/Special/committees/cic/minutes.cfm All Agendas] <br />
* Clinical Quality Information - [http://wiki.hl7.org/index.php?title=Clinical_Quality_Information_WGM_Agendas All WGM Agendas] and [http://wiki.hl7.org/index.php?title=Clinical_Quality_Information_WG_September_2018,_Baltimore,_MD Baltimore Agenda]<br />
* Clinical Statement - <br />
* Community Based Collaborative Care - [http://wiki.hl7.org/index.php?title=Community-Based_Collaborative_Care All WGM Agendas, under 'Upcoming'] and [http://wiki.hl7.org/index.php?title=September_2018_CBCC_Working_Group_Meeting_-_Baltimore,_Maryland_USA Baltimore Agenda]<br />
* Conformance - [http://wiki.hl7.org/index.php?title=Conformance_Sep_2018_WGM_Agenda Baltimore Agenda]<br />
* Education - [http://wiki.hl7.org/index.php?title=WGM_Agendas_and_Minutes Education WGM Agendas] <br />
* EHR - [http://wiki.hl7.org/images/7/78/EHR_WG_Calendar_for_Sept_2018_WGM_Baltimore_20180720.xlsx 2018 Sept Baltimore Agenda]<br />
* Electronic Services and Tools - [http://confluence.hl7.org/display/EST/September+2018+-+HL7+Working+Group+Meeting+Agenda+for+EST Baltimore WGM Agenda Sept 2018 @Confluence]<br />
* Emergency Care - [http://confluence.hl7.org/display/EC/2018+October+ECWG+Draft+WGM+Agenda%2C+Baltimore%2C+MD Baltimore Agenda] <br />
* FHIR - [http://wiki.hl7.org/index.php?title=FHIR_Agenda_201809_WGM Baltimore Agendas]<br />
* Financial Management - [http://wiki.hl7.org/index.php?title=FM_Sept_2018_Baltimore_WGM_Agenda Baltimore Agenda]<br />
* Health Care Devices (DEV) - [http://www.hl7.org/Special/committees/healthcaredevices/minutes.cfm Agendas and Minutes] <br />
* [[Imaging_Integration_WG|Imaging Integration]] - [https://confluence.hl7.org/display/IMIN/2018-10+WGM Baltimore Agenda]<br />
* Implementable Technology Specifications - [http://wiki.hl7.org/index.php?title=ITS_WGM_Agenda_2018_09 Baltimore Agenda]<br />
* [[Infrastructure_and_Messaging | Infrastructure and Messaging (InM)]] - <br />
* International Council - [http://wiki.hl7.org/index.php?title=International_Council WGM Agendas] <br />
* Learning Health Systems - <br />
* Mobile Health - [http://www.hl7.org/documentcenter/public/wg/mobile/F2F%20HL7%20WGM%20MH%20WG%20Agenda%20Sept%202018.xlsx Baltimore Agenda]<br />
* Modeling and Methodology (MnM) - WGM agendas on [http://gforge.hl7.org/gf/project/mnm-project/frs/?action=FrsReleaseBrowse&frs_package_id=24 Gforge]<br />
* Orders and Observations - [https://confluence.hl7.org/display/OO/OO+WGM+Agendas OO WGM Agendas]<br />
* Patient Administration - [http://wiki.hl7.org/index.php?title=2018-10_PA_WGM_Agenda Baltimore Agenda] or Confluence pages [http://confluence.hl7.org/display/PA/2018+-+10+Agenda+for+WGM+Baltimore PA WGM Agenda Baltimore]<br />
* Patient Care - [http://wiki.hl7.org/index.php?title=Patient_Care_Work_Group_meeting_Agenda_and_Draft_Minutes WGM Agendas] <br />
* Pharmacy - [https://confluence.hl7.org/pages/viewpage.action?pageId=24379504 Pharmacy WGM Agendas] <br />
* Process Improvement -<br />
* Project Services - [http://www.hl7.org/documentcenter/public/wg/projectServices/minutes/2018_09_ProjectServicesAgenda-September2018_WGM_Baltimore_Final.xls Baltimore Agenda]<br />
* Public Health - [http://confluence.hl7.org/pages/viewpage.action?pageId=17662221 Baltimore Agenda]<br />
* Publishing - [https://confluence.hl7.org/display/PUB/Publishing+WGM+Baltimore+Sept.+30+-+Oct.+5%2C+2018 Baltimore Agenda]<br />
* Security - [http://wiki.hl7.org/index.php?title=September_2018_Security_Working_Group_Meeting_Agenda-_Baltimore_(DRAFT) Baltimore Agenda]<br />
* Service Oriented Architecture - [https://confluence.hl7.org/display/SOA/SOA+Sept+2018+Baltimore+Agenda Baltimore Agenda]<br />
* Structured Documents - [http://confluence.hl7.org/x/D4BnAQ September 2018 Working Group Detailed Agenda, Baltimore]<br />
* Templates - [http://wiki.hl7.org/index.php?title=Templates_WGM_2018_May May 2018 Agenda]<br />
* Vocabulary - [https://confluence.hl7.org/display/VOC/September+2018+-+HL7+WGM+Meeting+Agenda+for+Vocabulary Baltimore Agenda]<br />
<br />
===Board Committees===<br />
<!-- Requested Removal of Line Below --><br />
<!-- *Organizational Relations Committee - [[Organizational_Relations_Committee:_Agendas_and_Minutes]] --><br />
*Outreach Committee for Clinical Research <br />
*International Mentoring Committee<br />
*US Realm Steering Committee -<br />
<br />
===Tutorials===<br />
'''TBD'''<br />
<!-- *[http://www.hl7.org/events/wgm052015/tutorials.cfm List of tutorials and link to brochure] --><br />
<br />
==Agenda Templates==<br />
'''Deprecated - Use Confluence as soon as possible!'''<br />
*Excel Template from HL7 web site /participate/templates [http://www.hl7.org/documentcenter/public/utilities/WGM%20Agenda%20Template.xls link]<br />
*[[WGM_Agenda_Template|wiki version]] of Excel template<br />
<br />
<br />
[[Category:WGM agendas]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=WGM_information&diff=161424WGM information2018-09-18T19:32:56Z<p>Bpech: </p>
<hr />
<div>*Links to WG agendas and documents are posted here so that attendees and interested persons can review what is being worked on at the Meeting. This also acts as a snapshot to see which WGs are meeting (or not planning to meet). Please add or update your Work Group's agenda and papers as they become available.<br />
**Previous Working Group Meeting information links have been moved to the [[:Category:WGM_agendas|Category page for WGM agendas]] for reference. <br />
*First-Timer information here: [http://www.hl7.org/events/workgroupmeetings.cfm What is a "WGM"?]<br />
*Information for Auxiliary attendees of the WGM is available here: [[HL7 Auxiliary]]<br />
*WGM Attendee [[Lost and Found]]<br />
*Mobile On-Site App: <!--[http://eventmobi.com/may2014wgm/ here]--> TBD<br />
*[http://www.hl7.org/events/working_group_meeting/2018/05/ WGM homepage]<br />
<!--*[http://www.hl7.org/documentcenter/public/brochures/wgm/Cologne-wgm_web.pdf Event Brochure]--><br />
==Travel, Transportation and other information==<br />
*See the [http://www.hl7.org/events/working_group_meeting/2018/05/] page on the 2018May WG Meeting site<br />
<!--**Early Bird registration open until December 30 2014--><br />
<!--**[http://www.hl7.org/events/wgm012015/?ref=banner Online registration] is open! Onsite registration will be open Sunday, January 18, 2015 from 8:30 am – 5:00 pm --><br />
<br />
==Agendas for 2018 September WGM, September 29 - October 5, 2018 Baltimore, Maryland, USA ==<br />
===Technical Steering Committee===<br />
<br />
===Standards Governance Board===<br />
<br />
===Steering Division agendas: ===<br />
Clinical SD - <br />
Infrastructure SD - <br/><br />
Administrative SD - <br/><br />
Organizational Support SD -<br />
<br />
===Work Groups / other (project) Groups===<br />
* Anesthesia - <br />
*[[Architecture_Board | Architecture Board (ARB)]] - [https://confluence.hl7.org/display/ARB/2018-09-29+ARB+Baltimore+WGM+Agenda ARB Baltimore WGM agenda]<br />
*Arden Syntax - <br />
*Attachments - [http://www.hl7.org/documentcenter/public/wg/ca/minutes/Baltimore%20HL7%20AWG%20Agenda.xlsx Baltimore Agenda]<br />
* BR&R - [[Wc 2018-05-14 BR&R WG Meeting | Agenda May 2018]]<br />
* Clinical Decision Support - [http://wiki.hl7.org/index.php?title=CDS_WG_Agenda_2018-09 CDS September WGM]<br />
* Clinical Genomics - [http://wiki.hl7.org/index.php?title=CG_Working_Group_Meeting_Agendas All WGM Agendas] and [http://wiki.hl7.org/index.php?title=File:HL7_WGM_September2018_-_Clinical_Genomics_Agenda.pdf Baltimore Agenda]<br />
* CIMI - <br />
* Clinical Interoperability Council - [http://www.hl7.org/Special/committees/cic/minutes.cfm All Agendas] <br />
* Clinical Quality Information - [http://wiki.hl7.org/index.php?title=Clinical_Quality_Information_WGM_Agendas All WGM Agendas] and [http://wiki.hl7.org/index.php?title=Clinical_Quality_Information_WG_September_2018,_Baltimore,_MD Baltimore Agenda]<br />
* Clinical Statement - <br />
* Community Based Collaborative Care - [http://wiki.hl7.org/index.php?title=Community-Based_Collaborative_Care All WGM Agendas, under 'Upcoming'] and [http://wiki.hl7.org/index.php?title=September_2018_CBCC_Working_Group_Meeting_-_Baltimore,_Maryland_USA Baltimore Agenda]<br />
* Conformance - [http://wiki.hl7.org/index.php?title=Conformance_Sep_2018_WGM_Agenda Baltimore Agenda]<br />
* Education - [http://wiki.hl7.org/index.php?title=WGM_Agendas_and_Minutes Education WGM Agendas] <br />
* EHR - [http://wiki.hl7.org/images/7/78/EHR_WG_Calendar_for_Sept_2018_WGM_Baltimore_20180720.xlsx 2018 Sept Baltimore Agenda]<br />
* Electronic Services and Tools - [http://confluence.hl7.org/display/EST/September+2018+-+HL7+Working+Group+Meeting+Agenda+for+EST Baltimore WGM Agenda Sept 2018 @Confluence]<br />
* Emergency Care - [http://confluence.hl7.org/display/EC/2018+October+ECWG+Draft+WGM+Agenda%2C+Baltimore%2C+MD Baltimore Agenda] <br />
* FHIR - [http://wiki.hl7.org/index.php?title=FHIR_Agenda_201809_WGM Baltimore Agendas]<br />
* Financial Management - [http://wiki.hl7.org/index.php?title=FM_Sept_2018_Baltimore_WGM_Agenda Baltimore Agenda]<br />
* Health Care Devices (DEV) - [http://www.hl7.org/Special/committees/healthcaredevices/minutes.cfm Agendas and Minutes] <br />
* [[Imaging_Integration_WG|Imaging Integration]] - [https://confluence.hl7.org/display/IMIN/2018-10+WGM Baltimore Agenda]<br />
* Implementable Technology Specifications - [http://wiki.hl7.org/index.php?title=ITS_WGM_Agenda_2018_09 Baltimore Agenda]<br />
* [[Infrastructure_and_Messaging | Infrastructure and Messaging (InM)]] - <br />
* International Council - [http://wiki.hl7.org/index.php?title=International_Council WGM Agendas] <br />
* Learning Health Systems - <br />
* Mobile Health - [http://www.hl7.org/documentcenter/public/wg/mobile/F2F%20HL7%20WGM%20MH%20WG%20Agenda%20Sept%202018.xlsx Baltimore Agenda]<br />
* Modeling and Methodology (MnM) - WGM agendas on [http://gforge.hl7.org/gf/project/mnm-project/frs/?action=FrsReleaseBrowse&frs_package_id=24 Gforge]<br />
* Orders and Observations - [https://confluence.hl7.org/display/OO/OO+WGM+Agendas OO WGM Agendas]<br />
* Patient Administration - [http://wiki.hl7.org/index.php?title=2018-10_PA_WGM_Agenda Baltimore Agenda] or Confluence pages [http://confluence.hl7.org/display/PA/2018+-+10+Agenda+for+WGM+Baltimore PA WGM Agenda Baltimore]<br />
* Patient Care - [http://wiki.hl7.org/index.php?title=Patient_Care_Work_Group_meeting_Agenda_and_Draft_Minutes WGM Agendas] <br />
* Pharmacy - [https://confluence.hl7.org/pages/viewpage.action?pageId=24379504 Pharmacy WGM Agendas] <br />
* Process Improvement -<br />
* Project Services - [http://www.hl7.org/documentcenter/public/wg/projectServices/minutes/2018_09_ProjectServicesAgenda-September2018_WGM_Baltimore_Final.xls Baltimore Agenda]<br />
* Public Health - [http://confluence.hl7.org/pages/viewpage.action?pageId=17662221 Baltimore Agenda]<br />
* Publishing - [https://confluence.hl7.org/display/PUB/Publishing+WGM+Baltimore+Sept.+30+-+Oct.+5%2C+2018]<br />
* Security - [http://wiki.hl7.org/index.php?title=September_2018_Security_Working_Group_Meeting_Agenda-_Baltimore_(DRAFT) Baltimore Agenda]<br />
* Service Oriented Architecture - [https://confluence.hl7.org/display/SOA/SOA+Sept+2018+Baltimore+Agenda Baltimore Agenda]<br />
* Structured Documents - [http://confluence.hl7.org/x/D4BnAQ September 2018 Working Group Detailed Agenda, Baltimore]<br />
* Templates - [http://wiki.hl7.org/index.php?title=Templates_WGM_2018_May May 2018 Agenda]<br />
* Vocabulary - [https://confluence.hl7.org/display/VOC/September+2018+-+HL7+WGM+Meeting+Agenda+for+Vocabulary Baltimore Agenda]<br />
<br />
===Board Committees===<br />
<!-- Requested Removal of Line Below --><br />
<!-- *Organizational Relations Committee - [[Organizational_Relations_Committee:_Agendas_and_Minutes]] --><br />
*Outreach Committee for Clinical Research <br />
*International Mentoring Committee<br />
*US Realm Steering Committee -<br />
<br />
===Tutorials===<br />
'''TBD'''<br />
<!-- *[http://www.hl7.org/events/wgm052015/tutorials.cfm List of tutorials and link to brochure] --><br />
<br />
==Agenda Templates==<br />
'''Deprecated - Use Confluence as soon as possible!'''<br />
*Excel Template from HL7 web site /participate/templates [http://www.hl7.org/documentcenter/public/utilities/WGM%20Agenda%20Template.xls link]<br />
*[[WGM_Agenda_Template|wiki version]] of Excel template<br />
<br />
<br />
[[Category:WGM agendas]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=FHIR_Connectathon_19&diff=158640FHIR Connectathon 192018-06-28T19:11:01Z<p>Bpech: /* FHIR Tutorials */</p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Genomics Clinical Genomics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Research Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday Sept 29 9AM - 10PM and Sunday Sept 30 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/09/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 12 FHIR tutorials scheduled through-out the week<br />
<br />
*(Tues. AM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions (part 1)<br />
*(Tues. PM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Wed. AM) HAPI on FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Wed. PM) Designing and Architecting HL7 FHIR Solutions (part 2)<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
*(Thur. PM) HL7 FHIR Profiling<br />
<br />
*() Clinical Genomics Using HL7 FHIR<br />
*(All day - Wed. & Thurs.) FHIR Experience<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/events/working_group_meeting/2018/09/ Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
**[[FHIR Connectathon 18]] (May 2018, Cologne, Germany)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201809_FHIR_Connectathon_Track_Proposals Sept. 2018 Track Proposal Submissions] are due July 11, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=FHIR_Connectathon_19&diff=158639FHIR Connectathon 192018-06-28T19:03:54Z<p>Bpech: /* FHIR Tutorials */</p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Genomics Clinical Genomics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Research Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday Sept 29 9AM - 10PM and Sunday Sept 30 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/09/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 13 FHIR tutorials scheduled through-out the week<br />
<br />
*(Tues. AM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions (part 1)<br />
*(Tues. PM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Wed. AM) HAPI on FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Wed. PM) Designing and Architecting HL7 FHIR Solutions (part 2)<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
*(Thur. PM) HL7 FHIR Profiling<br />
<br />
*() Clinical Genomics Using HL7 FHIR<br />
*(All day - Wed. & Thurs.) FHIR Experience<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/events/working_group_meeting/2018/09/ Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
**[[FHIR Connectathon 18]] (May 2018, Cologne, Germany)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201809_FHIR_Connectathon_Track_Proposals Sept. 2018 Track Proposal Submissions] are due July 11, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=FHIR_Connectathon_19&diff=158638FHIR Connectathon 192018-06-28T19:02:22Z<p>Bpech: /* FHIR Tutorials */</p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Genomics Clinical Genomics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Research Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday Sept 29 9AM - 10PM and Sunday Sept 30 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/09/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 13 FHIR tutorials scheduled through-out the week<br />
<br />
*(Tues. AM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions (part 1)<br />
*(Tues. PM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Wed. AM) HAPI on FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Wed. PM) Designing and Architecting HL7 FHIR Solutions (part 2)<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
*(Thur. PM) HL7 FHIR Profiling<br />
<br />
*() Clinical Genomics Using HL7 FHIR<br />
*() FHIR Experience<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/events/working_group_meeting/2018/09/ Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
**[[FHIR Connectathon 18]] (May 2018, Cologne, Germany)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201809_FHIR_Connectathon_Track_Proposals Sept. 2018 Track Proposal Submissions] are due July 11, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=FHIR_Connectathon_19&diff=158597FHIR Connectathon 192018-06-27T22:09:24Z<p>Bpech: /* FHIR Tutorials */</p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Genomics Clinical Genomics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Research Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday Sept 29 9AM - 10PM and Sunday Sept 30 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/09/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 13 FHIR tutorials scheduled through-out the week<br />
<br />
*(Tues. AM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions<br />
*(Tues. PM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Wed. AM) HAPI on FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Wed. PM) Designing and Architecting HL7 FHIR Solutions<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
*(Thur. PM) HL7 FHIR Profiling<br />
<br />
*() Clinical Genomics Using HL7 FHIR<br />
*() FHIR Experience<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/events/working_group_meeting/2018/09/ Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
**[[FHIR Connectathon 18]] (May 2018, Cologne, Germany)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201809_FHIR_Connectathon_Track_Proposals Sept. 2018 Track Proposal Submissions] are due July 11, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=FHIR_Connectathon_19&diff=158590FHIR Connectathon 192018-06-27T21:25:01Z<p>Bpech: /* FHIR Tutorials */</p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Genomics Clinical Genomics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Research Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday Sept 29 9AM - 10PM and Sunday Sept 30 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/09/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 13 FHIR tutorials scheduled through-out the week<br />
*(Tues. AM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions<br />
*(Tues. PM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Wed. AM) HAPI on FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Wed. PM) Designing and Architecting HL7 FHIR Solutions<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
*(Thur. PM) HL7 FHIR Profiling<br />
<br />
*() Clinical Genomics Using HL7 FHIR<br />
*() FHIR Experience<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/events/working_group_meeting/2018/09/ Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
**[[FHIR Connectathon 18]] (May 2018, Cologne, Germany)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201809_FHIR_Connectathon_Track_Proposals Sept. 2018 Track Proposal Submissions] are due July 11, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=FHIR_Connectathon_19&diff=158585FHIR Connectathon 192018-06-27T20:37:23Z<p>Bpech: /* FHIR Tutorials */</p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Genomics Clinical Genomics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Research Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday Sept 29 9AM - 10PM and Sunday Sept 30 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/09/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 10 FHIR tutorials scheduled through-out the week<br />
*(Mon. PM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions<br />
*(Tues. AM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Tues. PM) HL7 FHIR Profiling<br />
*(Wed. AM) IHE on FHIR<br />
*(Wed. AM) Clinical Genomics Using HL7 FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/events/working_group_meeting/2018/09/ Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
**[[FHIR Connectathon 18]] (May 2018, Cologne, Germany)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201809_FHIR_Connectathon_Track_Proposals Sept. 2018 Track Proposal Submissions] are due July 11, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=FHIR_Connectathon_19&diff=158583FHIR Connectathon 192018-06-27T20:33:20Z<p>Bpech: /* Connectathon Organization */</p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Genomics Clinical Genomics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Research Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday Sept 29 9AM - 10PM and Sunday Sept 30 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/09/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 10 FHIR tutorials scheduled through-out the week<br />
*(Mon. PM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions<br />
*(Tues. AM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Tues. PM) HL7 FHIR Profiling<br />
*(Wed. AM) IHE on FHIR<br />
*(Wed. AM) Clinical Genomics Using HL7 FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
**[[FHIR Connectathon 18]] (May 2018, Cologne, Germany)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201809_FHIR_Connectathon_Track_Proposals Sept. 2018 Track Proposal Submissions] are due July 11, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=FHIR&diff=158039FHIR2018-06-07T21:18:36Z<p>Bpech: </p>
<hr />
<div>[[File:FHIR.png|right|140px|Temporary FHIR logo]]<br />
[[Category:FHIR]]<br />
Fast Healthcare Interoperability Resources (FHIR, pronounced "Fire") defines a set of "[[Resource]]s" that represent granular clinical concepts. The resources can be managed in isolation, or aggregated into complex documents. Technically, FHIR is designed for the web; the resources are based on simple XML or JSON structures, with an http-based RESTful protocol where each resource has predictable URL. Where possible, open internet standards are used for data representation. <br />
<br />
Community Participation Rules: [[FHIR Code of Conduct]], [[FHIR Intellectual Property Rules]]<br />
<br />
{|width=100% cellspacing=0 cellpadding=2 <br />
|-<br />
|bgcolor="#e30614" align=center width="40%"| FHIR Implementation<br />
|bgcolor="#ffeb6a" align=center width="30%"| FHIR Development<br />
|bgcolor="#e30614" align=center width="30%"| Organizational<br />
|-<br />
|valign=top| <br />
<br />
*The current specification: [http://www.HL7.org/fhir/ http://www.HL7.org/fhir/] (or [http://hl7.org/implement/standards/FHIR-Develop/ the development version])<br />
** [[FHIR Specification Feedback (DSTU 2)]]<br />
** [[FHIR Profiles from other Organizations]]<br />
* Contact Information<br />
** [[Getting involved with the FHIR Community]]<br />
** [[FHIR Support Page]]<br />
** Implementation help: [[http://stackoverflow.com/questions/tagged/hl7_fhir ask questions about FHIR]]<br />
** Formal Contact point for the project: [[mailto:fmgcontact@hl7.org fmgcontact@hl7.org]]<br />
**[https://chat.fhir.org/ FHIR Chat (Zulip)] [[chat.fhir.org community expectations]]<br />
**[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemBrowse&tracker_id=677 FHIR gForge Tracker] for change requests/corrections<br />
** FHIR Project Team Leads (FHIR Core Team): [[mailto:grahame@healthintersections.com.au Grahame Grieve]], [[mailto:e.kramer@furore.com Ewout Kramer]], [[mailto:lloyd@lmckenzie.com Lloyd Mckenzie]]<br />
** [[FHIR_email_list_subscription_instructions|List server]] - project email list<br />
<br />
* Help / Getting Started<br />
**[[FHIR Starter]] - tutorial for FHIR newbies<br />
**[[FHIR Teaching]] - sources of FHIR teaching, training, and tutorials<br />
**[https://fire.ly/wp-content/uploads/2017/02/cheatsheet-dstu1.pdf FHIR Cheat Sheet] (DSTU 1)<br />
**[https://fire.ly/wp-content/uploads/2017/02/CHEAT-SHEET-DSTU2_feb-2017.pdf FHIR Cheat Sheet] (DSTU 2)<br />
**[https://fire.ly/wp-content/uploads/2018/02/CHEAT_SHEET_2017_STU3.pdf FHIR Cheat Sheet] (DSTU 3)<br />
**[https://fire.ly/wp-content/uploads/2018/02/CHEAT_SHEET_R4_2018.pdf FHIR Cheat Sheet] (R4)<br />
**[https://healthlevelseven.desk.com/ Help desk FAQs & knowledge-base articles] (HL7 members only)<br />
<!--**[[FHIR FAQ]] - business and technical perspectives--><br />
**[[FHIR Tools Registry]] - a list of useful tools for FHIR implementers<br />
** [[FHIR for Clinical Users]] - an introduction to FHIR for non-technical people that will migrate to the specification in the future<br />
**[[FHIR User Group]]<br />
**[[FHIR for Consumers]]<br />
**[[FHIR for Clinical Research]]<br />
* Social Media on FHIR<br />
**FHIR blogs [http://fhirblog.com/ David Hay], [http://blog.fire.ly Ewout Kramer], [http://www.healthintersections.com.au/ Grahame Grieve], [http://motorcycleguy.blogspot.com/search/label/FHIR Keith Boone], [https://brianpos.com/ Brian Postlethwaite], [https://healthcaresecprivacy.blogspot.com/p/fhir.html John Moehrke], [http://blog.heliossoftware.com Steve Munini], [http://lightmyfhir.com/ MITRE (Mark Kramer and colleagues)]<br />
**FHIR News on Twitter [http://www.twitter.com/FHIRnews FHIR News]<br />
**FHIR Videos [https://live.blueskybroadcast.com/bsb/client/CL_DEFAULT.asp?Client=556675&PCAT=8341&CAT=8341&Review=true HIMSS FHIR Session], [http://www.hl7.tv/FHIR.html HL7.tv] and [https://vimeo.com/channels/hl7fhir Ringholm].<br />
<br />
*Testing<br />
**[[Publicly Available FHIR Servers for testing]]<br />
**[[Open Source FHIR implementations]]<br />
**[[Organizations interested in FHIR]]<br />
**[[Profile Tooling]]<br />
**[http://clinfhir.com/ ClinFHIR] - web-based generic FHIR client<br />
**[[FHIR Testing Platforms]]<br />
**[[Using the FHIR Validator]]<br />
<br />
* [[FHIR Implementations]]<br />
* [[FHIR R2/R3 Transformation page]]<br />
<br />
*Connectathons<br />
**Connectathon Process<br />
***[[FHIR Connectathon Track Process]]<br />
***[[:Category:201809_FHIR_Connectathon_Track_Proposals|Proposed connectathon tracks for Baltimore Sept. 2018]]<br />
**Upcoming Connectathons<br />
***[[FHIR Connectathon 19| Connectathon 19]] (Sept. 29 - 30, 2018 Baltimore,MD)<br />
<br />
*Previous Connectathons and other events<br />
**[[:Category:FHIR_Connectathons|Historical Connectathons]] (list)<br />
<br />
|valign=top|<br />
<br />
* How to<br />
** [[FHIR DSTU monitoring]] - how to monitor DSTU feedback<br />
** [[FHIR Ballot Prep]] - tasks for the next ballot and milestone dates<br />
** [[FHIR Build Process]] - Setting up and running the FHIR build process<br />
** [[FHIR Guide to Authoring Resources|How to create resources]] (and [[FHIR Guide to Authoring Types|How to create types]])<br />
** Materials: [http://gforge.hl7.org/gf/project/fhir/ gForge], [http://gforge.hl7.org/svn/fhir/trunk SVN Trunk]<br />
*** For read-only SVN access, use "anonymous" and your email as a password.<br />
*** For Commit privileges, send a request to lloyd@lmckenzie.com<br />
**[[:Category:FHIR_Resource_Proposal|FHIR resource and profile proposals]] - proposals for new resources & profiles<br />
** [[FHIR Profile authoring]] - Creating and maintaining FHIR profiles (see also [[Profile Tooling]])<br />
** [[FHIR Change requests]] - Process for managing and resolving<br />
** [[FHIR_gForge_Tracker]] - Guidance for using the gForge tracker, including for ballot reconciliation<br />
<br />
* Implementation Guides<br />
** [[FHIR Implementation Guides]] - General considerations for implementation guides<br />
** [[IG Publisher Documentation]] - Guidelines for setting up a new guide<br />
** [[FHIR Implementation Guide Publishing Requirements]] - Implementation Guide Publishing Requirements<br />
** [[FHIR NPM Package Spec]] - Specification for NPM packages for Implementation Guides (and see also the [[FHIR Package Cache]] documentation)<br />
** [[FHIR Implementation Guide Authoring|Old IG Publishing Method]] - Guidelines for setting up a new guide under old (deprecated, being phased out rapidly) IG infrastructure<br />
** [[FHIR: Enhancing Implementation (ONC Grant Project)]]<br />
<br />
<br />
* Guidelines<br />
** [[FHIR Trademark Policy]]<br />
** [[FHIR Maturity Model]]<br />
** [https://docs.google.com/spreadsheets/d/1COTmtlXgGWuFpoSr1ZQQK30S7ReCpVsk_NZI6xIeSHI FHIR FMM/QA Tracking Spreadsheet]<br />
** [[FHIR_Conformance_QA_Criteria | FHIR Conformance QA Criteria]]<br />
** [[FHIR Management Policies]]<br />
** [[Fundamental Principles of FHIR]]<br />
** [[FHIR Methodology Process]] - how the methodology is developed and maintained<br />
** [[FHIR Repository Process]] - Repository governance process and requirements<br />
*** [http://wiki.hl7.org/images/f/f0/Registry_Requirements_gap_assessment_v1.docx FHIR Registry Requirements and Gap Assessment]<br />
** [[FHIR Guide to Designing Resources|Methodology Guidelines]] - Content and quality guidelines<br />
** [[FHIR Design Patterns|Design Patterns]]<br />
** [[FHIR Comparison to other RESTful API specifications]]<br />
** [[SDC FHIR Document Profiles]]<br />
** [[FHIR_Bulk_Data_Export_Concepts_Paper]]<br />
<br />
*Resources<br />
** [[FHIR_email_list_subscription_instructions|List server]] - discussions<br />
** Discussion pages: [[:Category:Active FHIR Discussion|Active Discussions]], [[:Category:FHIR Discussion|All]]<br />
** [[FHIR Design Requirements Sources]]<br />
** [[FHIR Resource Types]]<br />
** [[FHIR and GraphQL]]<br />
** [[FHIR and the Direct Project]]<br />
** [[FHIR Resource Considerations]]<br />
** [[FHIR Governance| (old)]] - governance discussion with bits of methodology mixed in (to migrate to other pages)<br />
** [[FHIR Tooling Eco-system]]<br />
** [[FHIR Digital Signature Working Page]]<br />
** [[FHIR Subscription Working Page]]<br />
** [[FHIR Extensions Working Page]]<br />
<br />
* WG FHIR pages<br />
**[[Patient Administration Resource development]]<br />
**[[CDA to FHIR Samples Group]]<br />
**[[https://drive.google.com/folderview?id=0B44mVoChqHDtaEl4ZGtvclhtRGs&usp=sharing C-CDA on FHIR Mapping]]<br />
**[[https://docs.google.com/spreadsheets/d/1KctdexG3oB2QBiBQNH1Rbt2uJ6DxQFROyIFKo5q95WU/edit?usp=drive_web CDA on FHIR Mapping]]<br />
**[[Devices on FHIR]]<br />
**[[FHIR_Patient_Care_Resources]]<br />
**[[FHIR_Asynchronous_Exchange]]<br />
**[[FHIR and Heart/UMA]] joint work<br />
<br />
|valign=top|<br />
<br />
* [[FHIR Infrastructure]] Work Group<br />
** [[FHIR Workflow]] Project<br />
** [[FHIR Structured Data Capture]] (SDC) Project<br />
*Governance<br />
** [[FHIR Governance Process]]<br />
** [[FHIR Artifact Governance Process]]<br />
** [[FHIR Governance Board]] (FGB)<br />
** [[FHIR Management Group]] (FMG)<br />
** [[Modeling and Methodology]] (MnM)<br />
** [[FHIR Work Groups|Work Groups]]<br />
** [[FHIR Escalation Processes]]<br />
** [[FHIR Ballot Process]]<br />
** [[FHIR Web Server Hosting Record]]<br />
** [[FHIR Product Director Page]]<br />
** [[https://docs.google.com/spreadsheets/d/16Mn6TUVQu1nspX_tYKSGVkRVDfLg6vlQXVBmIOOfYF8/edit#gid=699167827 FMG Tracking Sheet]]<br />
<br />
*Agendas<br />
**'''[[FHIR Agenda 201805 WGM|Cologne WGM]]''' (next meeting, May 2018)<br />
**[[:Category:FHIR Meeting|Past Working Group Meetings]] (list of agendas/notes)<br />
**[http://wiki.hl7.org/index.php?title=MnM_Schedule MnM agendas]<br />
**[http://wiki.hl7.org/index.php?title=FHIR_Governance_Board#Meeting_Information FGB Agendas & Minutes]<br />
**[http://wiki.hl7.org/index.php?title=FHIR_Management_Group#Meeting_Information FMG Agendas & Minutes]<br />
<br />
<br />
<br />
|}</div>Bpechhttps://wiki.hl7.org/w/index.php?title=FHIR&diff=158038FHIR2018-06-07T21:11:47Z<p>Bpech: </p>
<hr />
<div>[[File:FHIR.png|right|140px|Temporary FHIR logo]]<br />
[[Category:FHIR]]<br />
Fast Healthcare Interoperability Resources (FHIR, pronounced "Fire") defines a set of "[[Resource]]s" that represent granular clinical concepts. The resources can be managed in isolation, or aggregated into complex documents. Technically, FHIR is designed for the web; the resources are based on simple XML or JSON structures, with an http-based RESTful protocol where each resource has predictable URL. Where possible, open internet standards are used for data representation. <br />
<br />
Community Participation Rules: [[FHIR Code of Conduct]], [[FHIR Intellectual Property Rules]]<br />
<br />
{|width=100% cellspacing=0 cellpadding=2 <br />
|-<br />
|bgcolor="#e30614" align=center width="40%"| FHIR Implementation<br />
|bgcolor="#ffeb6a" align=center width="30%"| FHIR Development<br />
|bgcolor="#e30614" align=center width="30%"| Organizational<br />
|-<br />
|valign=top| <br />
<br />
*The current specification: [http://www.HL7.org/fhir/ http://www.HL7.org/fhir/] (or [http://hl7.org/implement/standards/FHIR-Develop/ the development version])<br />
** [[FHIR Specification Feedback (DSTU 2)]]<br />
** [[FHIR Profiles from other Organizations]]<br />
* Contact Information<br />
** [[Getting involved with the FHIR Community]]<br />
** [[FHIR Support Page]]<br />
** Implementation help: [[http://stackoverflow.com/questions/tagged/hl7_fhir ask questions about FHIR]]<br />
** Formal Contact point for the project: [[mailto:fmgcontact@hl7.org fmgcontact@hl7.org]]<br />
**[https://chat.fhir.org/ FHIR Chat (Zulip)] [[chat.fhir.org community expectations]]<br />
**[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemBrowse&tracker_id=677 FHIR gForge Tracker] for change requests/corrections<br />
** FHIR Project Team Leads (FHIR Core Team): [[mailto:grahame@healthintersections.com.au Grahame Grieve]], [[mailto:e.kramer@furore.com Ewout Kramer]], [[mailto:lloyd@lmckenzie.com Lloyd Mckenzie]]<br />
** [[FHIR_email_list_subscription_instructions|List server]] - project email list<br />
<br />
* Help / Getting Started<br />
**[[FHIR Starter]] - tutorial for FHIR newbies<br />
**[[FHIR Teaching]] - sources of FHIR teaching, training, and tutorials<br />
**[https://fire.ly/wp-content/uploads/2017/02/cheatsheet-dstu1.pdf FHIR Cheat Sheet] (DSTU 1)<br />
**[https://fire.ly/wp-content/uploads/2017/02/CHEAT-SHEET-DSTU2_feb-2017.pdf FHIR Cheat Sheet] (DSTU 2)<br />
**[https://fire.ly/wp-content/uploads/2018/02/CHEAT_SHEET_2017_STU3.pdf FHIR Cheat Sheet] (DSTU 3)<br />
**[https://fire.ly/wp-content/uploads/2018/02/CHEAT_SHEET_R4_2018.pdf FHIR Cheat Sheet] (R4)<br />
**[https://healthlevelseven.desk.com/ Help desk FAQs & knowledge-base articles] (HL7 members only)<br />
<!--**[[FHIR FAQ]] - business and technical perspectives--><br />
**[[FHIR Tools Registry]] - a list of useful tools for FHIR implementers<br />
** [[FHIR for Clinical Users]] - an introduction to FHIR for non-technical people that will migrate to the specification in the future<br />
**[[FHIR User Group]]<br />
**[[FHIR for Consumers]]<br />
**[[FHIR for Clinical Research]]<br />
* Social Media on FHIR<br />
**FHIR blogs [http://fhirblog.com/ David Hay], [http://blog.fire.ly Ewout Kramer], [http://www.healthintersections.com.au/ Grahame Grieve], [http://motorcycleguy.blogspot.com/search/label/FHIR Keith Boone], [https://brianpos.com/ Brian Postlethwaite], [https://healthcaresecprivacy.blogspot.com/p/fhir.html John Moehrke], [http://blog.heliossoftware.com Steve Munini], [http://lightmyfhir.com/ MITRE (Mark Kramer and colleagues)]<br />
**FHIR News on Twitter [http://www.twitter.com/FHIRnews FHIR News]<br />
**FHIR Videos [https://live.blueskybroadcast.com/bsb/client/CL_DEFAULT.asp?Client=556675&PCAT=8341&CAT=8341&Review=true HIMSS FHIR Session], [http://www.hl7.tv/FHIR.html HL7.tv] and [https://vimeo.com/channels/hl7fhir Ringholm].<br />
<br />
*Testing<br />
**[[Publicly Available FHIR Servers for testing]]<br />
**[[Open Source FHIR implementations]]<br />
**[[Organizations interested in FHIR]]<br />
**[[Profile Tooling]]<br />
**[http://clinfhir.com/ ClinFHIR] - web-based generic FHIR client<br />
**[[FHIR Testing Platforms]]<br />
**[[Using the FHIR Validator]]<br />
<br />
* [[FHIR Implementations]]<br />
* [[FHIR R2/R3 Transformation page]]<br />
<br />
*Connectathons<br />
**Connectathon Process<br />
***[[FHIR Connectathon Track Process]]<br />
***[[:Category:201805_FHIR_Connectathon_Track_Proposals|Proposed connectathon tracks for Cologne, Germany 2018]]<br />
**Upcoming Connectathons<br />
***[[FHIR Connectathon 19| Connectathon 19]] (Sept. 29 - 30, 2018 Baltimore,MD)<br />
<br />
*Previous Connectathons and other events<br />
**[[:Category:FHIR_Connectathons|Historical Connectathons]] (list)<br />
<br />
|valign=top|<br />
<br />
* How to<br />
** [[FHIR DSTU monitoring]] - how to monitor DSTU feedback<br />
** [[FHIR Ballot Prep]] - tasks for the next ballot and milestone dates<br />
** [[FHIR Build Process]] - Setting up and running the FHIR build process<br />
** [[FHIR Guide to Authoring Resources|How to create resources]] (and [[FHIR Guide to Authoring Types|How to create types]])<br />
** Materials: [http://gforge.hl7.org/gf/project/fhir/ gForge], [http://gforge.hl7.org/svn/fhir/trunk SVN Trunk]<br />
*** For read-only SVN access, use "anonymous" and your email as a password.<br />
*** For Commit privileges, send a request to lloyd@lmckenzie.com<br />
**[[:Category:FHIR_Resource_Proposal|FHIR resource and profile proposals]] - proposals for new resources & profiles<br />
** [[FHIR Profile authoring]] - Creating and maintaining FHIR profiles (see also [[Profile Tooling]])<br />
** [[FHIR Change requests]] - Process for managing and resolving<br />
** [[FHIR_gForge_Tracker]] - Guidance for using the gForge tracker, including for ballot reconciliation<br />
<br />
* Implementation Guides<br />
** [[FHIR Implementation Guides]] - General considerations for implementation guides<br />
** [[IG Publisher Documentation]] - Guidelines for setting up a new guide<br />
** [[FHIR Implementation Guide Publishing Requirements]] - Implementation Guide Publishing Requirements<br />
** [[FHIR NPM Package Spec]] - Specification for NPM packages for Implementation Guides (and see also the [[FHIR Package Cache]] documentation)<br />
** [[FHIR Implementation Guide Authoring|Old IG Publishing Method]] - Guidelines for setting up a new guide under old (deprecated, being phased out rapidly) IG infrastructure<br />
** [[FHIR: Enhancing Implementation (ONC Grant Project)]]<br />
<br />
<br />
* Guidelines<br />
** [[FHIR Trademark Policy]]<br />
** [[FHIR Maturity Model]]<br />
** [https://docs.google.com/spreadsheets/d/1COTmtlXgGWuFpoSr1ZQQK30S7ReCpVsk_NZI6xIeSHI FHIR FMM/QA Tracking Spreadsheet]<br />
** [[FHIR_Conformance_QA_Criteria | FHIR Conformance QA Criteria]]<br />
** [[FHIR Management Policies]]<br />
** [[Fundamental Principles of FHIR]]<br />
** [[FHIR Methodology Process]] - how the methodology is developed and maintained<br />
** [[FHIR Repository Process]] - Repository governance process and requirements<br />
*** [http://wiki.hl7.org/images/f/f0/Registry_Requirements_gap_assessment_v1.docx FHIR Registry Requirements and Gap Assessment]<br />
** [[FHIR Guide to Designing Resources|Methodology Guidelines]] - Content and quality guidelines<br />
** [[FHIR Design Patterns|Design Patterns]]<br />
** [[FHIR Comparison to other RESTful API specifications]]<br />
** [[SDC FHIR Document Profiles]]<br />
** [[FHIR_Bulk_Data_Export_Concepts_Paper]]<br />
<br />
*Resources<br />
** [[FHIR_email_list_subscription_instructions|List server]] - discussions<br />
** Discussion pages: [[:Category:Active FHIR Discussion|Active Discussions]], [[:Category:FHIR Discussion|All]]<br />
** [[FHIR Design Requirements Sources]]<br />
** [[FHIR Resource Types]]<br />
** [[FHIR and GraphQL]]<br />
** [[FHIR and the Direct Project]]<br />
** [[FHIR Resource Considerations]]<br />
** [[FHIR Governance| (old)]] - governance discussion with bits of methodology mixed in (to migrate to other pages)<br />
** [[FHIR Tooling Eco-system]]<br />
** [[FHIR Digital Signature Working Page]]<br />
** [[FHIR Subscription Working Page]]<br />
** [[FHIR Extensions Working Page]]<br />
<br />
* WG FHIR pages<br />
**[[Patient Administration Resource development]]<br />
**[[CDA to FHIR Samples Group]]<br />
**[[https://drive.google.com/folderview?id=0B44mVoChqHDtaEl4ZGtvclhtRGs&usp=sharing C-CDA on FHIR Mapping]]<br />
**[[https://docs.google.com/spreadsheets/d/1KctdexG3oB2QBiBQNH1Rbt2uJ6DxQFROyIFKo5q95WU/edit?usp=drive_web CDA on FHIR Mapping]]<br />
**[[Devices on FHIR]]<br />
**[[FHIR_Patient_Care_Resources]]<br />
**[[FHIR_Asynchronous_Exchange]]<br />
**[[FHIR and Heart/UMA]] joint work<br />
<br />
|valign=top|<br />
<br />
* [[FHIR Infrastructure]] Work Group<br />
** [[FHIR Workflow]] Project<br />
** [[FHIR Structured Data Capture]] (SDC) Project<br />
*Governance<br />
** [[FHIR Governance Process]]<br />
** [[FHIR Artifact Governance Process]]<br />
** [[FHIR Governance Board]] (FGB)<br />
** [[FHIR Management Group]] (FMG)<br />
** [[Modeling and Methodology]] (MnM)<br />
** [[FHIR Work Groups|Work Groups]]<br />
** [[FHIR Escalation Processes]]<br />
** [[FHIR Ballot Process]]<br />
** [[FHIR Web Server Hosting Record]]<br />
** [[FHIR Product Director Page]]<br />
** [[https://docs.google.com/spreadsheets/d/16Mn6TUVQu1nspX_tYKSGVkRVDfLg6vlQXVBmIOOfYF8/edit#gid=699167827 FMG Tracking Sheet]]<br />
<br />
*Agendas<br />
**'''[[FHIR Agenda 201805 WGM|Cologne WGM]]''' (next meeting, May 2018)<br />
**[[:Category:FHIR Meeting|Past Working Group Meetings]] (list of agendas/notes)<br />
**[http://wiki.hl7.org/index.php?title=MnM_Schedule MnM agendas]<br />
**[http://wiki.hl7.org/index.php?title=FHIR_Governance_Board#Meeting_Information FGB Agendas & Minutes]<br />
**[http://wiki.hl7.org/index.php?title=FHIR_Management_Group#Meeting_Information FMG Agendas & Minutes]<br />
<br />
<br />
<br />
|}</div>Bpechhttps://wiki.hl7.org/w/index.php?title=FHIR_Connectathon_19&diff=158037FHIR Connectathon 192018-06-07T21:06:42Z<p>Bpech: Created page with "Category:FHIR Connectathons == Introduction == This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host ho..."</p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Research_Track Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday May 12 9AM - 10PM and Sunday May 13 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/09/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 10 FHIR tutorials scheduled through-out the week<br />
*(Mon. PM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions<br />
*(Tues. AM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Tues. PM) HL7 FHIR Profiling<br />
*(Wed. AM) IHE on FHIR<br />
*(Wed. AM) Clinical Genomics Using HL7 FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
**[[FHIR Connectathon 18]] (May 2018, Cologne, Germany)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201809_FHIR_Connectathon_Track_Proposals Sept. 2018 Track Proposal Submissions] are due July 11, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Connectathon_19&diff=158036Connectathon 192018-06-07T21:03:46Z<p>Bpech: /* Other References */</p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Research_Track Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday May 12 9AM - 10PM and Sunday May 13 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/09/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 10 FHIR tutorials scheduled through-out the week<br />
*(Mon. PM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions<br />
*(Tues. AM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Tues. PM) HL7 FHIR Profiling<br />
*(Wed. AM) IHE on FHIR<br />
*(Wed. AM) Clinical Genomics Using HL7 FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
**[[FHIR Connectathon 18]] (May 2018, Cologne, Germany)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201809_FHIR_Connectathon_Track_Proposals Sept. 2018 Track Proposal Submissions] are due July 11, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Connectathon_19&diff=158033Connectathon 192018-06-07T20:57:10Z<p>Bpech: </p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Research_Track Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday May 12 9AM - 10PM and Sunday May 13 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/09/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 10 FHIR tutorials scheduled through-out the week<br />
*(Mon. PM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions<br />
*(Tues. AM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Tues. PM) HL7 FHIR Profiling<br />
*(Wed. AM) IHE on FHIR<br />
*(Wed. AM) Clinical Genomics Using HL7 FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201809_FHIR_Connectathon_Track_Proposals Sept. 2018 Track Proposal Submissions] are due July 11, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Connectathon_19&diff=158032Connectathon 192018-06-07T20:56:05Z<p>Bpech: </p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Research_Track Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday May 12 9AM - 10PM and Sunday May 13 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/09/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 10 FHIR tutorials scheduled through-out the week<br />
*(Mon. PM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions<br />
*(Tues. AM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Tues. PM) HL7 FHIR Profiling<br />
*(Wed. AM) IHE on FHIR<br />
*(Wed. AM) Clinical Genomics Using HL7 FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201809_FHIR_Connectathon_Track_Proposals Sept. 2018 Track Proposal Submissions] were due July 11, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Connectathon_19&diff=158031Connectathon 192018-06-07T20:54:08Z<p>Bpech: </p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Research_Track Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday May 12 9AM - 10PM and Sunday May 13 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/09/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 10 FHIR tutorials scheduled through-out the week<br />
*(Mon. PM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions<br />
*(Tues. AM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Tues. PM) HL7 FHIR Profiling<br />
*(Wed. AM) IHE on FHIR<br />
*(Wed. AM) Clinical Genomics Using HL7 FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201805_FHIR_Connectathon_Track_Proposals May 2018 Track Proposal Submissions] were due March 31st, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Connectathon_19&diff=158030Connectathon 192018-06-07T20:52:31Z<p>Bpech: </p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29 - 30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Research_Track Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=20180_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday May 12 9AM - 10PM and Sunday May 13 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/05/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 10 FHIR tutorials scheduled through-out the week<br />
*(Mon. PM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions<br />
*(Tues. AM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Tues. PM) HL7 FHIR Profiling<br />
*(Wed. AM) IHE on FHIR<br />
*(Wed. AM) Clinical Genomics Using HL7 FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201805_FHIR_Connectathon_Track_Proposals May 2018 Track Proposal Submissions] were due March 31st, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Connectathon_19&diff=158029Connectathon 192018-06-07T20:49:27Z<p>Bpech: Created page with "Category:FHIR Connectathons == Introduction == This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29-30 2018 at the host hote..."</p>
<hr />
<div>[[Category:FHIR Connectathons]]<br />
== Introduction ==<br />
<br />
This page describes the Nineteenth FHIR Connectathon that will be held on Saturday/Sunday Sept. 29-30 2018 at the host hotel, Hyatt Regency Baltimore Inner Harbor, Baltimore, MD prior to the [http://www.hl7.org/events/working_group_meeting/2018/09/ Sept. HL7 Working Group Meeting].<br />
<br />
<br />
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916<br />
<br />
== Important notes==<br />
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!<br />
<br />
* Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template. <br />
<br />
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.<br />
<br />
== Tracks ==<br />
<br />
The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.<br />
<br />
*[http://wiki.hl7.org/index.php?title=201805_Attachments Attachments]<br />
*[http://wiki.hl7.org/index.php?title=201805_Bulk_Data Bulk Data]<br />
*[http://wiki.hl7.org/index.php?title=201805_Care_Plan Care Planning and Management]<br />
*[http://wiki.hl7.org/index.php?title=201805_Catalog Catalog]<br />
*[http://wiki.hl7.org/index.php?title=201805_Clinical_Notes_Track Clinical Notes]<br />
*[http://wiki.hl7.org/index.php?title=201805_Clinical_Research_Track Clinical Research]<br />
*[http://wiki.hl7.org/index.php?title=201805_Clinical_Reasoning Clinical Reasoning]<br />
*[http://wiki.hl7.org/index.php?title=201805_CDS_Hooks CDS Hooks]<br />
*[http://wiki.hl7.org/index.php?title=201805_FHIR_Documents Documents]<br />
*[http://wiki.hl7.org/index.php?title=201805_FHIRcast FHIRcast]<br />
*[http://wiki.hl7.org/index.php?title=201805_Financial_Track Financial Track]<br />
*[http://wiki.hl7.org/index.php?title=201805_GDPR GDPR-General Data Protection Regulation]<br />
*[http://wiki.hl7.org/index.php?title=201805_IHE-on-FHIR IHE on FHIR with focus on MHD]<br />
*[http://wiki.hl7.org/index.php?title=201805_International_Patient_Summary International Patient Summary]<br />
*[http://wiki.hl7.org/index.php?title=201805_MedicationPlan-Track Medication Plan]<br />
*[http://wiki.hl7.org/index.php?title=201805_Patient_Track Patient Track]<br />
*[http://wiki.hl7.org/index.php?title=201805_FHIR_Storage_and_Analytics Storage and Analytics]<br />
*[http://wiki.hl7.org/index.php?title=201805_Terminology_Services_Track Terminology Services]<br />
*[http://wiki.hl7.org/index.php?title=201805_Questionnaire_Track Questionnaire Track]<br />
*[http://wiki.hl7.org/index.php?title=201805_Versioned_API Versioned API]<br />
<br />
== Connectathon Organization ==<br />
<br />
The connectathon will be held over 2 days - Saturday May 12 9AM - 10PM and Sunday May 13 9AM - 5PM, prior to the HL7 Working Group Meeting.<br />
<br />
Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available ([http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing FHIR Test Servers]''' ), but some participants may bring other servers along depending on the actors they are fulfilling.<br />
Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.<br />
<br />
Each stream has a coordinator. The nominated coordinator's [http://wiki.hl7.org/index.php?title=Connectathon_Track_Lead_Responsibilities responsibilities]:<br />
* In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other<br />
* During the connectathon act as a test mediator / progress tracker<br />
* track emergent issues that should be fed back to the committees<br />
<br />
<br />
== Connectathon Planning Team ==<br />
<br />
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd<br />
*[mailto:david.hay25@gmail.com David Hay], Orion Health<br />
*[mailto:sandra.vance@aegis.net Sandy Vance], HL7 Connectathon Administrator, AEGIS.net<br />
<br />
== Enrollment ==<br />
<br />
If you or your company are interested in participating in the connectathon, please do the following.<br />
*Read the '''[http://hl7-fhir.github.io/index.html Connectathon version of the FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.<br />
*Read the '''scenario descriptions''' below. <br />
*[http://www.hl7.org/events/working_group_meeting/2018/05/ Register to attend the WGM], and make sure to select the Connectathon option when you do<br />
*Complete the HL7 FHIR Pre-Connectathon Survey (Link available SOON!) for each member of your team to indicate their primary track.<br />
<br />
Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.<br />
<br />
For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]<br />
<br />
<br />
== Test servers ==<br />
<br />
<br />
These are the STU3 servers we are aware of:<br />
* Health Intersections: http://test.fhir.org/r3<br />
* HAPI / University Health Network: http://fhirtest.uhn.ca/baseDstu3<br />
* Vonk: http://vonk.furore.com<br />
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1<br />
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir<br />
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/ <br />
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)<br />
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dtsserverws/fhir and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action<br />
**Through a collaboration with the American Medical Association, the Current Procedural Terminology (CPT®) is now available for use in FHIR development efforts through the Apelon DTS on FHIR® service. Authentication is required. Please send an email to support@apelon.com for a user/pass. Please note that use of CPT® for production or commercial purposes through this service is prohibited.<br />
* HSPC: http://sandbox.hspconsortium.org<br />
* SMART (app launcher with r2 and r3 servers) https://launch.smarthealthit.org<br />
* Ontoserver (Terminology Service): https://ontoserver.csiro.au/stu3-latest<br />
* Tukan FHI Server http://fhir.tukan.online/<br />
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz<br />
<br />
== FHIR Tutorials ==<br />
*There are 10 FHIR tutorials scheduled through-out the week<br />
*(Mon. PM) Introduction to HL7 FHIR<br />
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions<br />
*(Tues. AM) Introduction to HL7 FHIR for Software Developers<br />
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers<br />
*(Tues. PM) HL7 FHIR Profiling<br />
*(Wed. AM) IHE on FHIR<br />
*(Wed. AM) Clinical Genomics Using HL7 FHIR<br />
*(Wed. AM) Clinical Documents on HL7 FHIR<br />
*(Wed. PM) Understanding and Using Terminology in HL7 FHIR<br />
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows<br />
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks<br />
<br />
Detailed descriptions are available in the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure]<br />
<br />
== FHIR Proficiency Exam ==<br />
<br />
*The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.<br />
<br />
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review <br />
<br />
*The exam will be held on Thursday in the afternoon.<br />
<br />
== Work Group Meetings ==<br />
HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the [[FHIR Governance Board]] and [[FHIR Management Group]] discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.<br />
<br />
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_89EAF10A-1C23-BA17-0CA222EF90CA509F/brochures/wgm/Cologne-wgm_web.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place. <br />
<br />
Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.<br />
<br />
== Outcomes (for coordinators) ==<br />
<br />
A complete downloadable word document of the [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# Outcomes for FHIR Connectathon 18] can be found on [https://docs.google.com/document/d/1hrQt7pp4l7Mkk-jIOHTLI7cxkybnffo7k1NKDWa67RA/edit# google docs]. <br />
<br />
Guidelines for report out:<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
*1 list of participants (with logos if you have time and energy)<br />
*1 paragraph: notable achievements<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
*1 paragraph: now what?<br />
<br />
=== Attachments===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.<br />
*1 list of participants<br />
Anthem Inc., HCSC<br />
*1 paragraph: notable achievements<br />
<br />
- Built new patients and payer and provider information to build attachment requests<br />
- Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.<br />
- Then acted as Provider and to build Communication to send the requested attachment.<br />
- Sent attachment once as jpeg link to Xray and then again as encoded with base 64.<br />
- Also acted as provider sending and unsolicited attachment to payor<br />
<br />
Worked with Financial Management – Paul Knapp<br />
- Built a claim from Provider<br />
- Sent a Pre-Authorization request to Provider<br />
<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements<br />
<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.<br />
<br />
*1 paragraph: now what?<br />
<br />
===Bulk Data===<br />
Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.<br />
<br />
Participants: Google, Epic, Cerner, Boston Children's Hospital<br />
<br />
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.<br />
<br />
Discovered issues:<br />
Throttling while polling<br />
we should have consistent error codes (e.g. 429 status code for "too many requests")<br />
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds<br />
Should servers prevent client new exports while a previous request is running?<br />
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])<br />
We need to test the API with security (backend services) in place.<br />
Is it okay for a server to return multiple logically distinct resources with the same ID?<br />
What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan)<br />
There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?<br />
<br />
Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.<br />
<br />
===Care Planning and Management===<br />
<br />
Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.<br />
<br />
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration<br />
<br />
Results:<br />
Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project.<br />
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.<br />
The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.<br />
<br />
Discovered issues:<br />
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks. <br />
<br />
Now What?<br />
Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.<br />
Catalog<br />
<br />
Summary:<br />
This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [http://hl7.org/fhir/2018May/catalog.html] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [http://hl7.org/fhir/2018May/entrydefinition.html]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.<br />
<br />
Participants: <br />
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)<br />
<br />
Results:<br />
The two clients were able to interact with the server.<br />
Example:<br />
<br />
The full scenario described on the catalog track page [http://wiki.hl7.org/index.php?title=201805_Catalog#Scenarios] was executed, which enabled to refine both the server and the clients.<br />
<br />
Discovered issues:<br />
The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.<br />
<br />
Now what?<br />
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.<br />
Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore.<br />
CDS Hooks<br />
Goals<br />
Gain implementer feedback on the balloted 1.0 specification.<br />
Participants<br />
EHRs<br />
Cerner<br />
Epic<br />
CDS Services<br />
Arpage AG / HL7 Switzerland<br />
Clinical Cloud Solutions<br />
HarmonIQ<br />
HLN Consulting<br />
IMO<br />
Interopion<br />
Lantana Consulting Group<br />
McKesson<br />
<br />
Notable Achievements<br />
<br />
HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.<br />
<br />
We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon.<br />
What’s Next?<br />
The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.<br />
<br />
===Clinical Notes===<br />
Summary<br />
Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. <br />
Participants<br />
Cerner, Epic, Argonaut<br />
<br />
Results<br />
Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes.<br />
Discovered issues<br />
Mime types and LOINC codes<br />
Each FHIR server supports a different subset of the ValueSets at these elements<br />
MIME type for DocumentReference.content.attachment.contentType.<br />
LOINC code for DocumentReference.type.<br />
Clients need to know what a server supports for create and read<br />
Discovering this by trial and error is time consuming and unlikely to be comprehensive.<br />
Communicating this out of band would pose implementation burden. <br />
We considered several options for a server to communicate what they support on read and write:<br />
CapabilityStatement.rest.resource.documentation - free text markdown<br />
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set<br />
CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource.<br />
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type.<br />
We also discussed a vendors just posting to their website :)<br />
All these options are hard for clients add burden and challenge for clients without <br />
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’<br />
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.<br />
<br />
===Clinical Research===<br />
<br />
What was the track trying to achieve<br />
We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. <br />
There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM. <br />
<br />
1 list of participants (with logos if you have time and energy)<br />
Geoff Low, Medidata<br />
<br />
Bob Milius, CIBMTR<br />
<br />
Discovered issues / questions (if there are any)<br />
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:<br />
The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study.<br />
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.<br />
<br />
Now what?<br />
Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.<br />
<br />
===Clinical Reasoning===<br />
<br />
*1 paragraph summary: what was the track trying to achieve<br />
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track<br />
*1 list of participants (with logos if you have time and energy)<br />
Zynx Health<br />
Motive Medical Intelligence<br />
Apelon<br />
Philips<br />
Accenture<br />
*1 paragraph: notable achievements<br />
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence<br />
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements<br />
*1 paragraph: discovered issues / questions (if there are any)<br />
Found and fixed several issues with our implementation of CDS Hooks<br />
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint<br />
*1 paragraph: now what?<br />
We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.<br />
<br />
===Direct / Certificates===<br />
<br />
Goals<br />
The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.<br />
<br />
Participants<br />
<br />
Notable achievements <br />
At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.<br />
<br />
Track participation introduced the following questions:<br />
1. How will FHIR endpoints advertise what authentication method(s) are accepted? <br />
<br />
2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?<br />
<br />
3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?<br />
<br />
<br />
What’s Next<br />
Formalize client registration profiles<br />
<br />
Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579<br />
<br />
===Documents===<br />
Goals<br />
Test/update mappings/transforms from CDA to FHIR<br />
Generate a fully bundled document from a Composition resource using the Generate Document operation<br />
Participants<br />
Sarah Gaunt (Lantana Consulting Group)<br />
Corey Spears (Infor)<br />
Gay Dolin (IMO)<br />
Amnon Shabo (Philips)<br />
Ron Shapiro (Qvera)<br />
Lisa Nelson (MaxMD)<br />
�<br />
Notable Achievements[edit]<br />
Scenario/Goal<br />
Participants<br />
Asserter<br />
Result<br />
Issues/Challenges/Notes<br />
Create and persist Document (bundle) from a Composition resource using $document operation<br />
Client: Postman<br />
Server: http://test.fhir.org/r4<br />
Gay Dolin,<br />
Sarah Gaunt.<br />
Amnon Shabo<br />
Pass<br />
<br />
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)<br />
Client: Cloverleaf Integration Engine<br />
Server: HAPI<br />
Corey Spears,<br />
Gay Dolin<br />
Pass<br />
<br />
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin<br />
Pass<br />
Refined transformations based on testing:<br />
Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target.<br />
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.<br />
Discovered and resolved an issue around transformation of allergy status. <br />
Explored medication timing transforms<br />
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)<br />
Different servers return quite different validation results.<br />
How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation.<br />
Create clinically robust examples to test transformations<br />
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine<br />
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4<br />
Corey Spears, <br />
Ron Shapiro,<br />
Gay Dolin,<br />
Amnon Shabo<br />
Pass<br />
Identified the need for more clinically robust examples<br />
Create and test imaging report document<br />
Client: Postman<br />
Server: http://test.fhir.org/r3<br />
Amnon Shabo<br />
Pass<br />
Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR.<br />
Review prototype FHIR R4 Mapping Language files<br />
n/a<br />
Lisa Nelson, <br />
Sarah Gaunt<br />
n/a<br />
Have noted issues with the mappings<br />
More explanation is needed on how the mappings are used<br />
Discovered issues<br />
See notes in table<br />
Next Steps<br />
Continue update of CDA to FHIR transforms <br />
Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Options:<br />
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource<br />
Composition.relatesTo - maybe add DocumentReference as a choice<br />
Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1<br />
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples<br />
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them<br />
Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data<br />
Negation - how to deal with negation in FHIR<br />
<br />
===FHIRcast===<br />
FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.<br />
<br />
Participants<br />
Brett Esler - Oridashi<br />
Isaac Vetter - Epic<br />
Oliver Krauss - University of Applied Sciences Upper Austria<br />
Martin Bellehumeur - Siemens Healthcare<br />
Ashish Singh - Siemens Healthcare<br />
Bas van den Heuvel - Philips<br />
Richard Ettema - PenRad<br />
<br />
Notable achievements<br />
Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client.<br />
Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.<br />
<br />
Also, see the video Brett made of FHIRcast in operation.<br />
<br />
Discovered issues/questions<br />
The track identified a number of outstanding issues, both with the sandbox and the specification itself.<br />
Specification:<br />
Issue #29: How can a subscribed app validate that it's subscription is active?<br />
Issue #28: How can a subscribed app determine session context immediately upon subscribing?<br />
Issue #27: Does the callback url need to be verified as belonging to the subscriber?<br />
Issue #26: How are new events defined? Can we create a swagger definition for events?<br />
Sandbox:<br />
Issue #5: Notification context from sandbox doesn't conform to spec.<br />
Issues #8: Url verification parameters from sand box doesn't conform to spec.<br />
<br />
What's next?<br />
The future is bright! Next steps include:<br />
Resolving the above issues and reviewing and incorporating PRs #24 and #25.<br />
Continuing to build the implementer community and respond to feedback.<br />
Ballot specification into HL7.<br />
<br />
===GDPR-General Data Protection Regulation===<br />
<br />
Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR. <br />
<br />
Participants:<br />
Firely <br />
ByLight <br />
HL7 Austria <br />
CGM Clinical<br />
VA/BZI<br />
Infor<br />
Accenture<br />
<br />
Accomplishments<br />
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps<br />
Most interesting gaps<br />
Should there be a standardized operation for submitting an erasure request?<br />
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.<br />
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data<br />
<br />
IHE on FHIR with focus on MHD<br />
<br />
Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.<br />
<br />
Participants<br />
HL7 Switzerland<br />
HL7 Argentina <br />
IHE Intnl <br />
IHE Services <br />
Firely <br />
ByLight <br />
Ahdis <br />
SAIHST <br />
<br />
Accomplishments:<br />
The group primarily tested the FHIR conformance resources from MHD<br />
6 bugs found and fixed <br />
Developed StructureDefinitions for response messages for each transaction<br />
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition<br />
Developed PDQm return response StructureDefinition<br />
IHE validator tool will validate all MHD, PDQm, and PIXm transactions<br />
<br />
===MedikationsplanPlus (German Medication Plan IG)===<br />
<br />
===Summary===<br />
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples<br />
===Participants=== <br />
* Molit Institut, <br />
* HL7 Deutschland e.V., <br />
* Lang Health IT Consulting, <br />
* Gefyra GmbH<br />
We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.<br />
<br />
===Achievements=== <br />
Testserver is running with >300 example resources available (fhir.hl7.de)<br />
===Discovered issues===<br />
* Issues with the core spec: <br />
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)<br />
** GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator<br />
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)<br />
<br />
* Issues with HAPI Server: <br />
** core extensions missing, can’t be uploaded (solved!)<br />
** Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.<br />
** non-core constraints hardcoded into Java validator (resolved locally)<br />
<br />
* Issues with HAPI FHIRPath engine: <br />
** resolve() is not implemented<br />
<br />
* Issues with .NET-Validator: <br />
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)<br />
<br />
* Issues with our profiles (all resolved)<br />
** Errors in ValueSet Bindings<br />
** Insufficient mustSupport-Flags<br />
** Slicings that don’t work<br />
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).<br />
<br />
* Issues with our examples (all resolved)<br />
** Missing mandatory elements<br />
** Invalid units (wrong case)<br />
** Invalid Dates (with Timezone)<br />
** Empty values<br />
** Invalid Extensions<br />
<br />
* General issues with the “Medikationsplan plus” implementation guide:<br />
** Clarification about context and usage of the profiles needs to be added in the implementation guide<br />
** Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.<br />
<br />
MedicationPlan issue-tracker:<br />
<br />
https://github.com/hl7germany/medikationsplanplusplus/issues<br />
<br />
===Now what===<br />
After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.<br />
<br />
===Storage and Analytics===<br />
<br />
Objectives:<br />
The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.<br />
<br />
Participants:<br />
<br />
Notable achievements:<br />
<br />
Hands-on guidelines with different implementation strategies created<br />
Created a README for individual database technologies<br />
Transferred queries between different query languages<br />
Discussion about the used datasets: create it before the connectathon in different sizes<br />
Discussion: Comparable queries are needed, based on CQL<br />
More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters<br />
<br />
Open questions:<br />
<br />
Find common README format for individual database technologies<br />
More meaningful queries are needed<br />
Get more participation, more databases, more other technologies<br />
Unify data with Bulk data track?<br />
Use Vonk Loader for other databases?<br />
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?<br />
<br />
<br />
Links:<br />
Link to github account where detailed description and result of the track can be found.<br />
<br />
===Terminology Services===<br />
<br />
Questionnaire Track<br />
Objectives<br />
Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.)<br />
Track Participants<br />
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska<br />
Additional discussion Participants<br />
Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter<br />
Achievements<br />
Identified 3 approaches to pre-population<br />
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)<br />
Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction)<br />
Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question<br />
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)<br />
Using definitions plus a profile containing fixed values<br />
Using StructureMap<br />
Using ActivityDefinition<br />
Issues<br />
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings<br />
Next steps<br />
Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification<br />
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon<br />
<br />
===Versioned API===<br />
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.<br />
Participants:<br />
Kevin Olbrich<br />
Christiaan Knaap<br />
Toby Hu<br />
Brian Postlethwaite<br />
Achievements:<br />
Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but <br />
Clarifications about responsibilities of servers and clients<br />
Servers:<br />
Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made.<br />
Should conform to the REST API behavior specified by FHIR for the appropriate version<br />
Should return the version in the ‘Content-Type’ of responses.<br />
If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update.<br />
If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet.<br />
Maybe report the “available versions” in the CapabilityStatement.format element<br />
Clients:<br />
Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated.<br />
The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported.<br />
Discovered Issues:<br />
We need a server that implements the proposed mechanism so we can test against it<br />
A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client)<br />
Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter)<br />
Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED.<br />
What’s next:<br />
Get a reference server implementation so we can perform tests against it<br />
<br />
== Other References ==<br />
<br />
* Other FHIR Connectathons: <br />
** 1st [[FHIR Connectathon]] (8 Sept. 2012 - Baltimore MD, USA)<br />
** [[FHIR Connectathon 2]] (12/13 Jan. 2013 - Phoenix AZ, USA)<br />
** [[FHIR Connectathon 3]] (4/5 May 2013 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 4]] (21/22 Sept. 2013 - Cambridge MA, USA)<br />
** FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)<br />
** [[FHIR Connectathon 5]] (18/19 Jan. 2014 - San Antonio TX, USA)<br />
** [[FHIR Connectathon 6]] (3/4 May. 2014 - Phoenix, Arizona, USA)<br />
** [[FHIR Connectathon 7]] (September. 2014 - Chicago, IL, USA)<br />
** [[FHIR Connectathon 8]] (January 2015 - San Antonio, TX, USA)<br />
** [[FHIR Connectathon 9]] (May 2015 - Paris, France)<br />
** [[FHIR Connectathon 10]] (Oct 2015 - Atlanta GA, USA)<br />
** [[FHIR Connectathon 11]] (Jan 2016 - Orlando, FL, USA)<br />
** [[FHIR Connectathon 12]] (May 2016 - Montreal, Canada)<br />
** [[FHIR Connectathon 13]] (September 2016 - Baltimore, MD, USA)<br />
** [[FHIR Connectathon 14]] (January 2017, San Antonio, USA)<br />
**[[FHIR Connectathon 15]] (May 2017 - Madrid, Spain)<br />
** FHIR Vendor's Mini Connectathon (4./5. July 2017, Berlin, Germany)<br />
**[[FHIR Connectathon 16]] (September 2017 - San Diego,CA, USA)<br />
**[[FHIR Connectathon 17]] (January 2018, New Orelans, USA)<br />
[[Category:FHIR Connectathons]]<br />
<br />
<br />
<br />
<br />
[http://wiki.hl7.org/index.php?title=Category:201805_FHIR_Connectathon_Track_Proposals May 2018 Track Proposal Submissions] were due March 31st, 2018. <br />
Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.<br />
<br />
[[FHIR_Connectathon_Track_Process]].<br />
<br />
[[FHIR|Return to the FHIR Main Page]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=201805_GDPR&diff=155460201805 GDPR2018-04-04T21:01:39Z<p>Bpech: </p>
<hr />
<div><br />
[[Category:201805_FHIR_Connectathon_Track_Proposals|May 2018 Proposals]]<br />
__NOTOC__<br />
=Track Name=<br />
GDPR - General Data Protection Regulation<br />
<br />
==Submitting WG/Project/Implementer Group==<br />
Security WG<br />
<br />
Track Orientation Presentation -- TBD<br />
<br />
==Justification==<br />
<br />
The justification for this track is to explore how the FHIR specification and Implementation Guides enable and support compliance with GDPR. This is not an overall examination of GDPR. <br />
<br />
This is a collaborative effort, please sign up to help <br />
<br />
===Relevant background===<br />
<br />
Prior Connectathon track [[201709 Consumer Centered Data Exchange]] and [[201801 Consumer Centered Data Exchange]]<br />
<br />
*[https://gforge.hl7.org/gf/project/security/docman/Security%20White%20Papers/Is%20Privacy%20Obsolete%20Study%20Group%20Library/HIMSS%20GDPR%20Webinar%20-%20final%203-20-2018.pdf HIMSS presentation on GDPR]<br />
* blog by Rene http://www.ringholm.com/column/GDPR_impact_on%20healthcare_data_interoperability.htm<br />
<br />
==Proposed Track Leads==<br />
*John Moehrke -Security WG co-chair - JohnMoehrke@gmail.com -- skype JohnMoehrke<br />
*Alex Mense - Security WG co-chair<br />
*Rene Spronk<br />
<br />
==Expected participants==<br />
*John Moehrke (HL7 Security co-chair) SME on FHIR Consent<br />
*http://test.fhir.org/r3<br />
<br />
==Actors==<br />
* Agent-Systems -- any system participating in the creation, use, or disclosure of identifiable data<br />
* etc...<br />
<br />
==FHIR Capabilities==<br />
<br />
Expect to produce a cross-reference between the existing FHIR Security & Privacy capabilities and how they aid with GDPR compliance.<br />
* Provenance resource<br />
* AuditEvent resource<br />
* Consent resource<br />
* Identity<br />
** Patient resource <br />
** RelatedPerson<br />
** Practitioner, PractitionerRole<br />
** Group<br />
** Organization<br />
** Location<br />
** etc.<br />
* Security-label mechanism in all FHIR Resource definitions (.meta.security)<br />
** Confidentiality classification<br />
** Sensitivity classification<br />
** Compartment classification<br />
** Integrity classification<br />
** Handling caveat<br />
* Security-label vocabulary (aka HCS)<br />
* Signature datatype<br />
* De-Identification<br />
* Authorization mechanisms<br />
** SMART-on-FHIR<br />
** Sync for Science<br />
** IHE-IUA<br />
** HEART<br />
** etc...<br />
* User/system Authentication<br />
** Open-ID-Connect profile of OAuth<br />
*** by way of SMART-on-FHIR<br />
* Communications security<br />
** HTTPS<br />
<br />
==Testing Scenarios==<br />
<br />
* Privacy Consents -- follow [[201801 Consumer Centered Data Exchange]]<br />
** or enhancements as needed<br />
* TBD</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Publishing_WGM_Agenda_201805&diff=153438Publishing WGM Agenda 2018052018-02-13T21:04:52Z<p>Bpech: </p>
<hr />
<div>=== Proposed Pub WG Agenda for the May 2018 WGM in Cologne, Germany ===<br />
<br />
Return to: [[Publishing_Committee|Pub Main Page]]<br />
<br />
back to [[WGM_information]]<br />
<br />
<br />
<table border=1 width="100%"><br />
<tr bgcolor=#bbbbbb><br />
<td>Day</td><br />
<td>Date</td><br />
<td colspan=2>Quarter</td><br />
<td>Room</td><br />
<td>Event</td><br />
<td>Host</td><br />
<td>joining</td><br />
<td>Chair</td><br />
<td>Scribe</td><br />
<td>Notes</td><br />
</tr><br />
<br />
<tr><br />
<td rowspan=4>Sunday</td><br />
<td rowspan=4>May 13</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Monday</td><br />
<td rowspan=4>May 14</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>Placeholder for V2 Management Group</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Tuesday</td><br />
<td rowspan=4>May 15</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Wednesday</td><br />
<td rowspan=4>May 16</td><br />
<td rowspan=2>AM</td><br />
<td bgcolor=#8e8aff>Q1</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>V2 Publishing: V2 planning, V2.9 ballot reconciliation, Review DMP, Review Projects</td><br />
<td bgcolor=#8e8aff>Pub</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>Beat</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td bgcolor=#8e8aff>Q3</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>Pubs and Vocab will '''not''' be meeting at this WGM</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Thursday</td><br />
<td rowspan=4>May 17</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Friday</td><br />
<td rowspan=4>May 18</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<br />
</table></div>Bpechhttps://wiki.hl7.org/w/index.php?title=Publishing_Committee&diff=153423Publishing Committee2018-02-13T19:41:55Z<p>Bpech: /* WGM Agendas and Minutes */</p>
<hr />
<div>== Publishing Work Group Mission and Related Planning Documents==<br />
NOTE: As of September 2017, the distinction between v2 and v3 Publishing no longer holds. The Work Group is now the Publishing Work Group. We retain the v2 Sub Grouping for old documents as a matter of history.<br />
*[http://wiki.hl7.org/index.php?title=Image:PublishingMissionAndCharter.doc Mission and Charter Statement]<br />
<br />
==Pages managed by the Publishing Work Group==<br />
*[[Normative Edition]], [[Development Edition]]<br />
<br />
==Upcoming Meetings==<br />
<br />
Publishing meets every other Tuesday at 3 PM EST with adjustments for holidays.<br />
<br />
Check the HL7 Conference call schedule for upcoming meetings: [http://www.hl7.org/concalls/Default.aspx Conference Center]<br />
<br />
Dial-in Number (United States): (515) 604-9581<br />
<br />
Access Code: 243646<br />
<br />
International Dial-in Numbers: https://www.freeconferencecall.com/wall/editors6#international<br />
<br />
Online Meeting Link: https://join.freeconferencecall.com/editors6<br />
<br />
Online Meeting ID: editors6<br />
<br />
<br />
<br />
FAQ’s, tips and other helpful information regarding FreeConferenceCall.com is available at www.HL7.org > Resources > Tools and Resources > FreeConferenceCall.com Tip Sheet.<br />
<br />
<br />
Meeting notes can be found in the HL7 document center: [http://www.hl7.org/Special/committees/publishing/index.cfm Meeting Notes]<br />
<br />
==WGM Agendas and Minutes==<br />
*[[Publishing WGM Agenda 201805|Cologne Germany, May 2018]]<br />
*[[Publishing WGM Agenda 201802|New Orleans LA, Jan-Feb 2018]]<br />
*[[Publishing WGM Agenda 201709|San Diego CA, September 2017]]<br />
*[[Publishing WGM Agenda 201705|Madrid Spain, May 2017]]<br />
*[[Publishing WGM Agenda 201701|San Antonio TX, Jan 2017]]<br />
<br />
==HL7 V2.x Publishing Sub Group==<br />
The V2.x Publishing Work Group is responsible for the publishing of HL7 Version 2.x<br />
*[[V2.X_Chapter_Editors|Version 2.x Chapter Editors]]<br />
<br />
<br />
*[[May 2017 WGM V2 Publishing agenda | V2 Publishing May 2017 agenda Madrid, Spain]]<br />
*[[Jan. 2017 WGM V2 Publishing agenda | V2 Publishing Jan. 2017 agenda San Antonio, TX]]<br />
*[[Sept. 2016 WGM V2 Publishing agenda | V2 Publishing Sept. 2016 agenda Baltimore, MD]]<br />
*[[May 2016 WGM V2 Publishing agenda | V2 Publishing May 2016 agenda Montreal, Quebec]]<br />
*[[Jan. 2016 WGM V2 Publishing agenda | V2 Publishing Jan. 2016 agenda Orlando, FL]]<br />
*[[Oct. 2015 WGM V2 Publishing agenda | V2 Publishing Oct. 2015 agenda Atlanta, GA]] <br />
*[[May 2015 WGM V2 Publishing agenda | V2 Publishing May 2015 agenda Paris, France]]<br />
*[[Jan. 2015 WGM V2 Publishing agenda | V2 Publishing Jan. 2015 agenda San Antonio, TX]]<br />
*[[Sept. 2014 WGM V2 publishing agenda|V2 Publishing Sept. 2014 Agenda Chicago, IL ]]<br />
<br />
<br />
* [[V2_Examples_Requirements |V2.x Examples Requirements]]<br />
<br />
* [[V2.9 Chapter Status]]<br />
<br />
<br />
*[http://gforge.hl7.org/gf/project/v2-ballot-pkg/ V2 Publishing Packages in SVN on G-Forge] (Select SVN and click 'Trunk')<br />
<br />
==V2.x Publishing Refactor project==<br />
*[[v2.x_refactor_requirements]]<br />
<br />
==V2.x Publishing "How To ..." Documents==<br />
HL7 V2.x:<br />
* HL7 V2.x Style Guide (Vxx)<br />
*[http://www.hl7.org/documentcenter/public/wg/publishing/V2.7%20Style%20Guide%20-%2044.doc latest]<br />
<br />
==HL7 V3 Publishing Sub Group==<br />
The V3 Publishing is responsible for publishing all HL7 non-V2.x Standards (V3 Messaging, CDA, etc.)<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_PublishingSWOT.doc V3 Publishing Strengths, Weaknesses, Opportunities & Threats (SWOT) Analysis - 9/2008]<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_Publishing_2008_Strategy_Plan.zip V3 Publishing 3-yr Strategic Plan - 9/2008]<br />
<br />
===Minutes, Conference Calls and WGM===<br />
*[[Recent Publishing ConCall Minutes|Minutes of Recent V3 Pub Calls]]<br />
*[[V3_Publishing_WGM_Agenda_2016_09|Agenda for September 2016 WGM in Baltimore]]<br />
*[[V3 Publishing WGM Agenda 2016 05|Agenda for May 2016 WGM in Montreal ]]'''<br />
*[[V3 Publishing WGM Agenda 2015 10|Agenda for October 2015 WGM in Atlanta ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 09|Agenda for September 2014 WGM in Chicago ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 05|Agenda for May 2014 WGM in Phoenix ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 09|Agenda for September 2013 WGM in Cambridge ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 05|Agenda for May 2013 WGM in Atlanta ]]'''<br />
<br />
===Issues and Current Work===<br />
*[[:category:V3 Publishing Issues|V3 Publishing Issues Category]]<br />
**[[:category:Referred Publishing Items|Reconciliation Issues "Referred" to V3 Publishing]]<br />
**[[Publishing Facilitators Guide Updates]]<br />
*[[Normative_Edition_2018_Review_List_by_WG|Normative Edition 2018 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2017_Review_List_by_WG|Normative Edition 2017 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2016_Review_List_by_WG|Normative Edition 2016 Content Review List Sorted By WG]]<br />
*[[V3 Publishing ANT Refactor]]<br />
*[[V3 Generator Acceptance Testing]]<br />
*[[V3 Publishing FAQ|V3 Publishing Frequently Asked Questions]]<br />
*[[V3_Patch_Policy|V3 Patching Policy for the V3 Ballot Web Site]]<br />
*[http://www.hl7.org/special/committees/publishing/schedules.cfm Annual Publishing Calendar from HL7 web site]<br />
<br />
===V3 Publishing "How To ..." Documents===<br />
HL7 V3:<br />
*[[V3 Publishing Process Overview]]<br />
*[[Publishing and Linking Thumbnail Graphics| How to Edit, Hyperlink and Publish Thumbnail Graphics with Desktop Publishing]]<br />
*[[CMET Documentation Guidelines| How to create documentation for CMETs]]<br />
*[[V3_Publishing_Process_Steps|V3 Publishing Process Steps Overview]]<br />
*[[V3_PubProcess_-_Prepare_Freehand_MIF|How to Edit Free-Hand MIF files]]<br />
*[[CMET Publication Task Workflow for Facilitators]]<br />
*[[Directory Structure in Subversion|Directory Structure for Version Control of V3 Publishing in Subversion]]<br />
*[[V3_PubProcess_Content_Submission|V3 Domain Content Preparation for Ballot Submission]]<br />
*[[Reconciliation_HowTo|How To Reconcile a Ballot, a General Overview]]<br />
*[[Withdraw_Negative|How to Withdraw Your Negative Vote on a Ballot]]<br />
*[[V3_Publishing_Section_and_Domain_Codes|Explanation of Section and Domain Codes in Ballot artifacts]]<br />
*[[:category:HowTo|All HowTos]]<br />
<br />
===V3 Publishing Older Items...===<br />
*[[:Category:V3 Publishing Tasks|'''VERY OLD''' V3 Publishing Task List as a "'''Category'''" of articles]]<br />
*[[Normative Edition 2011 Review List|Content Review List for Normative Edition 2011]]<br />
*[[Normative Edition 2010 Content List|Content Review List for Normative Edition 2010]]<br />
<br />
[[Category:Work_Group]]<br />
[[Category:Technical and Support Services Steering Division]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Publishing_WGM_Agenda_201805&diff=153422Publishing WGM Agenda 2018052018-02-13T19:39:40Z<p>Bpech: </p>
<hr />
<div>=== Proposed Pub WG Agenda for the May 2018 WGM in Cologne, Germany ===<br />
<br />
Return to: [[Publishing_Committee|Pub Main Page]]<br />
<br />
back to [[WGM_information]]<br />
<br />
<br />
<table border=1 width="100%"><br />
<tr bgcolor=#bbbbbb><br />
<td>Day</td><br />
<td>Date</td><br />
<td colspan=2>Quarter</td><br />
<td>Room</td><br />
<td>Event</td><br />
<td>Host</td><br />
<td>joining</td><br />
<td>Chair</td><br />
<td>Scribe</td><br />
<td>Notes</td><br />
</tr><br />
<br />
<tr><br />
<td rowspan=4>Sunday</td><br />
<td rowspan=4>Jan 28</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Monday</td><br />
<td rowspan=4>Jan 29</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>Placeholder for V2 Management Group</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Tuesday</td><br />
<td rowspan=4>Jan 30</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Wednesday</td><br />
<td rowspan=4>Jan 31</td><br />
<td rowspan=2>AM</td><br />
<td bgcolor=#8e8aff>Q1</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>V2 Publishing: V2 planning, V2.9 ballot reconciliation, Review DMP, Review Projects</td><br />
<td bgcolor=#8e8aff>Pub</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>Beat</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td bgcolor=#8e8aff>Q3</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>Pubs and Vocab will '''not''' be meeting at this WGM</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Thursday</td><br />
<td rowspan=4>Feb 1</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Friday</td><br />
<td rowspan=4>Feb 2</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<br />
</table></div>Bpechhttps://wiki.hl7.org/w/index.php?title=Publishing_WGM_Agenda_201805&diff=153421Publishing WGM Agenda 2018052018-02-13T19:36:29Z<p>Bpech: Created page with "=== Proposed Pub WG Agenda for the Jan-Feb 2018 WGM in New Orleans, LA === Return to: Pub Main Page back to WGM_information <table border=1 w..."</p>
<hr />
<div>=== Proposed Pub WG Agenda for the Jan-Feb 2018 WGM in New Orleans, LA ===<br />
<br />
Return to: [[Publishing_Committee|Pub Main Page]]<br />
<br />
back to [[WGM_information]]<br />
<br />
<br />
<table border=1 width="100%"><br />
<tr bgcolor=#bbbbbb><br />
<td>Day</td><br />
<td>Date</td><br />
<td colspan=2>Quarter</td><br />
<td>Room</td><br />
<td>Event</td><br />
<td>Host</td><br />
<td>joining</td><br />
<td>Chair</td><br />
<td>Scribe</td><br />
<td>Notes</td><br />
</tr><br />
<br />
<tr><br />
<td rowspan=4>Sunday</td><br />
<td rowspan=4>Jan 28</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Monday</td><br />
<td rowspan=4>Jan 29</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>Publishing joint with PLA and others - Topic - V2 Management Group</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td></td><br />
<td>Publishing will not meet during this quarter.</td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Tuesday</td><br />
<td rowspan=4>Jan 30</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Wednesday</td><br />
<td rowspan=4>Jan 31</td><br />
<td rowspan=2>AM</td><br />
<td bgcolor=#8e8aff>Q1</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>V2 Publishing: V2 planning, V2.9 ballot reconciliation, Review DMP, Review Projects</td><br />
<td bgcolor=#8e8aff>Pub</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>Brian</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td bgcolor=#8e8aff>Q3</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>V2 pubs joint with Vocab: vocabulary in HL7 V2</td><br />
<td bgcolor=#8e8aff>Pub</td><br />
<td bgcolor=#8e8aff>Vocabulary</td><br />
<td bgcolor=#8e8aff>Brian</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Thursday</td><br />
<td rowspan=4>Feb 1</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Friday</td><br />
<td rowspan=4>Feb 2</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<br />
</table></div>Bpechhttps://wiki.hl7.org/w/index.php?title=ESWG_Regularly_Scheduled_Calls_Agendas&diff=152998ESWG Regularly Scheduled Calls Agendas2018-02-01T17:49:19Z<p>Bpech: </p>
<hr />
<div>==Logistics==<br />
Return to [[Electronic Services and Tools]] main page<br />
<br />
The Electronic Services work group meets bi-weekly on Tuesdays at 10:00 AM Eastern Time. The bi-weekly schedule will resume Feb. 13, 2018.<br />
*Conference Call Time: <br />
:10:00 - 11:00 AM (US Eastern Time, GMT -5)<br />
:Please consult http://www.timeanddate.com/worldclock for your local times<br />
*Use Free Conference Call service <br />
:Phone Number: 641-715-0700<br />
:Access Code: 116908<br />
:International Dial-In Numbers: https://www.freeconferencecall.com/wall/esc1#international<br />
*Web meeting coordinates:<br />
:Online Meeting Link: https://join.freeconferencecall.com/esc1<br />
:Online Meeting ID: esc1 <br />
<br />
==Meeting Minutes and Agenda (most recent first)==<br />
Approved meeting minutes can be found on the Work Group page on the main HL7 web site: http://www.hl7.org/Special/committees/esTools/minutes.cfm<br />
<br />
* [[ESTWG_ConCall-20180116]] Agenda (Michael chair)<br />
* [[ESTWG_ConCall-20180102]] Agenda (Brian chair)<br />
* [[ESTWG_ConCall-20171212]] Agenda (David chair)<br />
* [[ESTWG_ConCall-20171128]] Agenda<br />
* [[ESTWG_ConCall-20171114]] Agenda <br />
* [[ESTWG_ConCall-20171031]] Agenda <br />
* [[ESTWG_ConCall-20171017]] Agenda <br />
* [[ESTWG_ConCall-20171003]] Agenda<br />
<br />
* [[ESTWG_ConCall-20170822]] Agenda<br />
* [[ESTWG_ConCall-20170808]] Agenda<br />
* [[ESTWG_ConCall-20170725]] Agenda<br />
* [[ESTWG_ConCall-20170711]] Agenda<br />
* [[ESTWG_ConCall-20170627]] Agenda<br />
* [[ESTWG_ConCall-20170613]] Agenda <br />
* [[ESTWG_ConCall-20170530]] Agenda<br />
<br />
* [[ESTWG_ConCall-20170425]] Agenda<br />
* [[ESTWG_ConCall-20170411]] Agenda<br />
* [[ESTWG_ConCall-20170328]] Agenda <br />
* [[ESTWG_ConCall-20170314]] Agenda <br />
* [[ESTWG_ConCall-20170228]] Agenda <br />
* [[ESTWG_ConCall-20170214]] Agenda <br />
* [[ESTWG_ConCall-20170131]] Agenda <br />
* [[ESTWG_ConCall-20170110]] Agenda <br />
* [[ESTWG_ConCall-20161213]] Agenda <br />
* [[ESTWG_ConCall-20161129]] Agenda <br />
* [[ESTWG_ConCall-20161115]] Agenda <br />
* [[ESTWG_ConCall-20161101]] Agenda <br />
* [[ESTWG_ConCall-20161018]] Agenda <br />
* [[ESTWG_ConCall-20161003|ESTWG_ConCall-20161004]] Agenda (Andy chair)<br />
* [[ESTWG_ConCall-20160906]] Agenda<br />
* [[ESTWG_ConCall-20160823]] Agenda<br />
* [[ESTWG_ConCall-20160809]] Agenda<br />
* [[ESTWG_ConCall-20160726]] Agenda<br />
* [[ESTWG_ConCall-20160712]] Agenda<br />
* [[ESTWG_ConCall-20160628]] Agenda<br />
* [[ESTWG_ConCall-20160614]] Agenda<br />
* [[ESTWG_ConCall-20160531]] Agenda<br />
* [[ESTWG_ConCall-20160426]] Agenda<br />
* [[ESTWG_ConCall-20160412]] Agenda<br />
* [[ESTWG_ConCall-20160329]] Agenda<br />
* [[ESTWG_ConCall-20160315]] Agenda<br />
* [[ESTWG_ConCall-20160301]] Agenda<br />
* [[ESTWG_ConCall-20160216]] Agenda (David Burgess chair)<br />
* [[ESTWG_ConCall-20160119]] Agenda <br />
* [[ESTWG_ConCall-20150924]] Agenda <br />
* [[ESTWG_ConCall-20150917]] Agenda - Liaison<br />
* [[ESTWG_ConCall-20150910]] Agenda <br />
* [[ESTWG_ConCall-20150827]] Agenda <br />
* [[ESTWG_ConCall-20150820]] Agenda - Liaison<br />
* [[ESTWG_ConCall-20150813]] Agenda <br />
* [[ESTWG_ConCall-20150730]] Agenda <br />
* [[ESTWG_ConCall-20150723]] Agenda - Liaison<br />
* [[ESTWG_ConCall-20150716]] Agenda <br />
* [[ESTWG_ConCall-20150702]] Agenda <br />
* [[ESTWG_ConCall-20150625]] Agenda - Liaison<br />
* [[ESTWG_ConCall-20150618]] Agenda <br />
* [[ESTWG_ConCall-20150604]] Agenda <br />
* [[ESTWG_ConCall-20150430]] Agenda (Nat chairing)<br />
* [[ESTWG_ConCall-20150423]] Agenda - Liaison (Michael ?? chairing)<br />
* [[ESTWG_ConCall-20150416]] Agenda (Andy chairing)<br />
* [[ESTWG_ConCall-20150402]] Agenda (Nat?? chairing)<br />
* [[ESTWG_ConCall-20150326]] Agenda - Liaison (Michael ?? chairing)<br />
* [[ESTWG_ConCall-20150319]] Agenda (Andy chairing)<br />
* [[ESTWG_ConCall-20150126]] Agenda - Liaison (Dennis ?? chairing)<br />
* [[ESTWG_ConCall-20150219]] Agenda (Lorraine chairing)<br />
* [[ESTWG_ConCall-20150108]] Agenda (Andy chairing)<br />
* [[ESTWG_ConCall-20141218]] Agenda (Lorraine chairing)<br />
* [[ESTWG_ConCall-20141211]] Agenda - Liaison Meeting (Dennis chairing)<br />
* [[ESTWG_ConCall-20141204]] Agenda (Andy chairing)<br />
* [[ESTWG_ConCall-20141120]] Agenda (Nat chairing)<br />
* [[ESTWG_ConCall-20141106]] Agenda (Lorraine chairing)<br />
* [[ESTWG_ConCall-20141030]] Agenda<br />
* [[ESTWG_ConCall-20141023]] Agenda (Nat chairing)<br />
* [[ESTWG_ConCall-20141009]] Agenda<br />
* [[ESTWG_ConCall-20140904]] Agenda<br />
* [[ESTWG_ConCall-20140821]] Agenda<br />
* [[ESTWG_ConCall-20140807]] Agenda<br />
* [[ESWG_ConCall-20140724]] Agenda<br />
* [[ESWG_ConCall-20140106]] Agenda<br />
* [[ESWG_ConCall-20131014]] Agenda<br />
* [[ESWG_ConCall-20130826]] Agenda<br />
* [[ESWG_ConCall-20130812]] Agenda<br />
* [[ESWG_ConCall-20130729]] Agenda<br />
* [[ESWG_ConCall-20130715]] Agenda<br />
* [[ESWG_ConCall-20130617]] Agenda<br />
* [[ESWG_ConCall-20130107]] Agenda<br />
* [[ESWG_ConCall-20121210]] Agenda<br />
* [[ESWG_ConCall-20121126]] Agenda<br />
* [[ESWG_ConCall-20121112]] Agenda<br />
* [[ESWG_ConCall-20121029]] Agenda<br />
* [[ESWG_ConCall-20121015]] Agenda<br />
* [[ESWG_ConCall-20121001]] Agenda<br />
* [[ESWG_ConCall-20120730]] Agenda<br />
* [[ESWG_ConCall-20120716]] Agenda<br />
* [[ESWG_ConCall-20120702]] Agenda<br />
* [[ESWG_ConCall-20120618]] Agenda<br />
* [[ESWG_ConCall-20120430]] Agenda<br />
* [[ESWG_ConCall-20120416]] Agenda<br />
* [[ESWG_ConCall-20120402]] Agenda<br />
* [[ESWG_ConCall-20120319]] Agenda<br />
* [[ESWG_ConCall-20120305]] Agenda<br />
* [[ESWG_ConCall-20120220]] Agenda<br />
* [[ESWG_ConCall-20120110]] Agenda<br />
* [[ESWG_ConCall-20111213]] Agenda<br />
* [[ESWG_ConCall-20111115]] Agenda<br />
* [[ESWG_ConCall-20111011]] Agenda<br />
* [[ESWG_ConCall-20110906]] Agenda<br />
* [[ESWG_ConCall-20110823]] Agenda<br />
* [[ESWG_ConCall-20110809]] Agenda <br />
* [[ESWG_ConCall-20110726]] Agenda <br />
* [[ESWG_ConCall-20110712]] Agenda<br />
* [[ESWG_ConCall-20110628]] Agenda<br />
* [[ESWG_ConCall-20110614]] Agenda<br />
* [[ESWG_ConCall-AgendaTemplate]] Template of ConfCall Structure</div>Bpechhttps://wiki.hl7.org/w/index.php?title=ESWG_WGM_Agendas&diff=152997ESWG WGM Agendas2018-02-01T17:45:57Z<p>Bpech: </p>
<hr />
<div>*[[EST WGM Agenda 2018 May| May 2018]]<br />
*[[EST WGM Agenda 2018 Jan|Jan 2018]]<br />
*[[EST WGM Agenda 2017 Sep|Sept 2017]]<br />
*[[EST WGM Agenda 2017 May|May 2017]]<br />
*[[EST WGM Agenda 2017 Jan|Jan 2017]]<br />
*[[EST WGM Agenda 2016 Sep|Sep 2016]]<br />
*[[EST WGM Agenda 2016 May|May 2016]] - [[EST WGM Minutes 2016 May|Minutes]]<br />
*[[EST WGM Agenda 2016 Jan|Jan 2016]]<br />
*[[EST WGM Agenda 2015 Oct|Oct 2015]]<br />
*[[EST WGM Agenda may 2015|May 2015]]<br />
*[[EST WGM Agenda January 2015|January 2015]]<br />
*[[EST WGM Agenda September 2014|September 2014]]<br />
*[[ES WGM Agenda May 2014|May 2014]]<br />
*[[ES WGM Agenda January 2014|January 2014]]<br />
*[[ES WGM Agenda September 2013|September 2013]]<br />
*[[ES WGM Agenda January 2013|January 2013]]<br />
*[[ES WGM Agenda September 2012|September 2012]]<br />
*[[ES WGM Agenda May 2012|May 2012]]<br />
*[[ES WGM Agenda January 2012|January 2012]]<br />
*[[ES WGM Agenda September 2011|September 2011]]<br />
*[[ES WGM Agenda May 2011|May 2011]]<br />
*[[ESWG January 2010 WGM Agenda|January 2010]]<br />
*[[ESWG May 2010 WGM Agenda|May 2010]]<br />
<br />
Return to [[Electronic Services and Tools]] main page</div>Bpechhttps://wiki.hl7.org/w/index.php?title=EST_WGM_Agenda_2018_May&diff=152996EST WGM Agenda 2018 May2018-02-01T17:43:22Z<p>Bpech: </p>
<hr />
<div>=== Proposed EST WG Agenda for the May 2018 WGM in Colgne, Germany ===<br />
<br />
Return to: [[Electronic_Services_and_Tools|EST Main Page]] &raquo; [[ESWG_WGM_Agendas|Agendas]]<br />
<br />
back to [[WGM_information]]<br />
<br />
<br />
<table border=1 width="100%"><br />
<tr bgcolor=#bbbbbb><br />
<td>Day</td><br />
<td>Date</td><br />
<td colspan=2>Quarter</td><br />
<td>Room</td><br />
<td>Event</td><br />
<td>Host</td><br />
<td>joining</td><br />
<td>Chair</td><br />
<td>Scribe</td><br />
<td>Notes</td><br />
</tr><br />
<br />
<tr><br />
<td rowspan=4>Sunday</td><br />
<td rowspan=4>May 13</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Monday</td><br />
<td rowspan=4>May 14</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Tuesday</td><br />
<td rowspan=4>May 15</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>Project Updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>TBD</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Wednesday</td><br />
<td rowspan=4>May 16</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Thursday</td><br />
<td rowspan=4>May 17</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>WG Business, M&amp;C, SWOT, Strategy, next meeting planning, project updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>TBD</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Friday</td><br />
<td rowspan=4>May 18</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<br />
</table></div>Bpechhttps://wiki.hl7.org/w/index.php?title=EST_WGM_Agenda_2018_May&diff=152995EST WGM Agenda 2018 May2018-02-01T17:42:24Z<p>Bpech: </p>
<hr />
<div>=== Proposed EST WG Agenda for the May 2018 WGM in Colgne, Germany ===<br />
<br />
Return to: [[Electronic_Services_and_Tools|EST Main Page]] &raquo; [[ESWG_WGM_Agendas|Agendas]]<br />
<br />
back to [[WGM_information]]<br />
<br />
<br />
<table border=1 width="100%"><br />
<tr bgcolor=#bbbbbb><br />
<td>Day</td><br />
<td>Date</td><br />
<td colspan=2>Quarter</td><br />
<td>Room</td><br />
<td>Event</td><br />
<td>Host</td><br />
<td>joining</td><br />
<td>Chair</td><br />
<td>Scribe</td><br />
<td>Notes</td><br />
</tr><br />
<br />
<tr><br />
<td rowspan=4>Sunday</td><br />
<td rowspan=4>May 13</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Monday</td><br />
<td rowspan=4>May 14</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Tuesday</td><br />
<td rowspan=4>May 15</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>Project Updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>TBD</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Wednesday</td><br />
<td rowspan=4>May 16</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Thursday</td><br />
<td rowspan=4>May 17</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>WG Business, M&amp;C, SWOT, Strategy, next meeting planning, project updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>TBD</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Friday</td><br />
<td rowspan=4>May 18</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<br />
</table></div>Bpechhttps://wiki.hl7.org/w/index.php?title=EST_WGM_Agenda_2018_May&diff=152994EST WGM Agenda 2018 May2018-02-01T17:39:43Z<p>Bpech: </p>
<hr />
<div>=== Proposed EST WG Agenda for the May 2018 WGM in Colgne, Germany ===<br />
<br />
Return to: [[Electronic_Services_and_Tools|EST Main Page]] &raquo; [[ESWG_WGM_Agendas|Agendas]]<br />
<br />
back to [[WGM_information]]<br />
<br />
<br />
<table border=1 width="100%"><br />
<tr bgcolor=#bbbbbb><br />
<td>Day</td><br />
<td>Date</td><br />
<td colspan=2>Quarter</td><br />
<td>Room</td><br />
<td>Event</td><br />
<td>Host</td><br />
<td>joining</td><br />
<td>Chair</td><br />
<td>Scribe</td><br />
<td>Notes</td><br />
</tr><br />
<br />
<tr><br />
<td rowspan=4>Sunday</td><br />
<td rowspan=4>May 13</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Monday</td><br />
<td rowspan=4>May 14</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Tuesday</td><br />
<td rowspan=4>May 15</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>Project Updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>TBD</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Wednesday</td><br />
<td rowspan=4>May 16</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Thursday</td><br />
<td rowspan=4>May 17</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>WG Business, M&amp;C, SWOT, Strategy, next meeting planning, project updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>TBD</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Friday</td><br />
<td rowspan=4>May 18</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<br />
</table></div>Bpechhttps://wiki.hl7.org/w/index.php?title=EST_WGM_Agenda_2018_May&diff=152993EST WGM Agenda 2018 May2018-02-01T17:38:24Z<p>Bpech: </p>
<hr />
<div>=== Proposed EST WG Agenda for the May 2018 WGM in Colgne, Germany ===<br />
<br />
Return to: [[Electronic_Services_and_Tools|EST Main Page]] &raquo; [[ESWG_WGM_Agendas|Agendas]]<br />
<br />
back to [[WGM_information]]<br />
<br />
<br />
<table border=1 width="100%"><br />
<tr bgcolor=#bbbbbb><br />
<td>Day</td><br />
<td>Date</td><br />
<td colspan=2>Quarter</td><br />
<td>Room</td><br />
<td>Event</td><br />
<td>Host</td><br />
<td>joining</td><br />
<td>Chair</td><br />
<td>Scribe</td><br />
<td>Notes</td><br />
</tr><br />
<br />
<tr><br />
<td rowspan=4>Sunday</td><br />
<td rowspan=4>May 13</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Monday</td><br />
<td rowspan=4>May 14</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Tuesday</td><br />
<td rowspan=4>May 15</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>Project Updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>TBD</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Wednesday</td><br />
<td rowspan=4>May 16</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Thursday</td><br />
<td rowspan=4>May 17</td><br />
<td rowspan=2>AM</td><br />
<td bgcolor=#ffe48a>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>WG Business, M&amp;C, SWOT, Strategy, next meeting planning, project updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>TBD</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Friday</td><br />
<td rowspan=4>May 18</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<br />
</table></div>Bpechhttps://wiki.hl7.org/w/index.php?title=EST_WGM_Agenda_2018_May&diff=152992EST WGM Agenda 2018 May2018-02-01T17:36:07Z<p>Bpech: </p>
<hr />
<div>=== Proposed EST WG Agenda for the May 2018 WGM in Colgne, Germany ===<br />
<br />
Return to: [[Electronic_Services_and_Tools|EST Main Page]] &raquo; [[ESWG_WGM_Agendas|Agendas]]<br />
<br />
back to [[WGM_information]]<br />
<br />
<br />
<table border=1 width="100%"><br />
<tr bgcolor=#bbbbbb><br />
<td>Day</td><br />
<td>Date</td><br />
<td colspan=2>Quarter</td><br />
<td>Room</td><br />
<td>Event</td><br />
<td>Host</td><br />
<td>joining</td><br />
<td>Chair</td><br />
<td>Scribe</td><br />
<td>Notes</td><br />
</tr><br />
<br />
<tr><br />
<td rowspan=4>Sunday</td><br />
<td rowspan=4>May 13</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Monday</td><br />
<td rowspan=4>May 14</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Tuesday</td><br />
<td rowspan=4>May 15</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>Project Updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>TBD</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Wednesday</td><br />
<td rowspan=4>May 16</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Thursday</td><br />
<td rowspan=4>May 17</td><br />
<td rowspan=2>AM</td><br />
<td bgcolor=#ffe48a>Q1</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>WG Business, M&amp;C, SWOT, Strategy, next meeting planning, project updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>Brian</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Friday</td><br />
<td rowspan=4>May 18</td><br />
<td rowspan=2>AM</td><br />
<td bgcolor=#ff8afb>Q1</td><br />
<td bgcolor=#ff8afb></td><br />
<td bgcolor=#ff8afb></td><br />
<td bgcolor=#ff8afb>Templates</td><br />
<td bgcolor=#ff8afb>EST</td><br />
<td bgcolor=#ff8afb></td><br />
<td bgcolor=#ff8afb></td><br />
<td bgcolor=#ff8afb></td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<br />
</table></div>Bpechhttps://wiki.hl7.org/w/index.php?title=EST_WGM_Agenda_2018_May&diff=152991EST WGM Agenda 2018 May2018-02-01T17:34:51Z<p>Bpech: </p>
<hr />
<div>=== Proposed EST WG Agenda for the May 2018 WGM in Colgne, Germany ===<br />
<br />
Return to: [[Electronic_Services_and_Tools|EST Main Page]] &raquo; [[ESWG_WGM_Agendas|Agendas]]<br />
<br />
back to [[WGM_information]]<br />
<br />
<br />
<table border=1 width="100%"><br />
<tr bgcolor=#bbbbbb><br />
<td>Day</td><br />
<td>Date</td><br />
<td colspan=2>Quarter</td><br />
<td>Room</td><br />
<td>Event</td><br />
<td>Host</td><br />
<td>joining</td><br />
<td>Chair</td><br />
<td>Scribe</td><br />
<td>Notes</td><br />
</tr><br />
<br />
<tr><br />
<td rowspan=4>Sunday</td><br />
<td rowspan=4>May 13</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Monday</td><br />
<td rowspan=4>May 14</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Tuesday</td><br />
<td rowspan=4>May 15</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>Project Updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>TBD</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Wednesday</td><br />
<td rowspan=4>May 16</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Thursday</td><br />
<td rowspan=4>May 17</td><br />
<td rowspan=2>AM</td><br />
<td bgcolor=#ffe48a>Q1</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>WG Business, M&amp;C, SWOT, Strategy, next meeting planning, project updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>Brian</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Friday</td><br />
<td rowspan=4>May 18</td><br />
<td rowspan=2>AM</td><br />
<td bgcolor=#ff8afb>Q1</td><br />
<td bgcolor=#ff8afb></td><br />
<td bgcolor=#ff8afb></td><br />
<td bgcolor=#ff8afb>Templates</td><br />
<td bgcolor=#ff8afb>EST</td><br />
<td bgcolor=#ff8afb></td><br />
<td bgcolor=#ff8afb></td><br />
<td bgcolor=#ff8afb></td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<br />
</table></div>Bpechhttps://wiki.hl7.org/w/index.php?title=EST_WGM_Agenda_2018_May&diff=152988EST WGM Agenda 2018 May2018-02-01T17:30:02Z<p>Bpech: Created page with "=== Proposed EST WG Agenda for the May 2018 WGM in Colgne, Germany === Return to: EST Main Page &raquo; Agendas back ..."</p>
<hr />
<div>=== Proposed EST WG Agenda for the May 2018 WGM in Colgne, Germany ===<br />
<br />
Return to: [[Electronic_Services_and_Tools|EST Main Page]] &raquo; [[ESWG_WGM_Agendas|Agendas]]<br />
<br />
back to [[WGM_information]]<br />
<br />
<br />
<table border=1 width="100%"><br />
<tr bgcolor=#bbbbbb><br />
<td>Day</td><br />
<td>Date</td><br />
<td colspan=2>Quarter</td><br />
<td>Room</td><br />
<td>Event</td><br />
<td>Host</td><br />
<td>joining</td><br />
<td>Chair</td><br />
<td>Scribe</td><br />
<td>Notes</td><br />
</tr><br />
<br />
<tr><br />
<td rowspan=4>Sunday</td><br />
<td rowspan=4>May 13</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Monday</td><br />
<td rowspan=4>May 14</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Tuesday</td><br />
<td rowspan=4>May 15</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td bgcolor=#ffe48a>Q2</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>Project Updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>David</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Wednesday</td><br />
<td rowspan=4>May 16</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Thursday</td><br />
<td rowspan=4>May 17</td><br />
<td rowspan=2>AM</td><br />
<td bgcolor=#ffe48a>Q1</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>WG Business, M&amp;C, SWOT, Strategy, next meeting planning, project updates</td><br />
<td bgcolor=#ffe48a>EST</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a>Brian</td><br />
<td bgcolor=#ffe48a></td><br />
<td bgcolor=#ffe48a></td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Friday</td><br />
<td rowspan=4>May 18</td><br />
<td rowspan=2>AM</td><br />
<td bgcolor=#ff8afb>Q1</td><br />
<td bgcolor=#ff8afb></td><br />
<td bgcolor=#ff8afb></td><br />
<td bgcolor=#ff8afb>Templates</td><br />
<td bgcolor=#ff8afb>EST</td><br />
<td bgcolor=#ff8afb></td><br />
<td bgcolor=#ff8afb></td><br />
<td bgcolor=#ff8afb></td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<br />
</table></div>Bpechhttps://wiki.hl7.org/w/index.php?title=WGM_information&diff=152173WGM information2018-01-27T20:57:49Z<p>Bpech: </p>
<hr />
<div>*Links to WG agendas and documents are posted here so that attendees and interested persons can review what is being worked on at the Meeting. This also acts as a snapshot to see which WGs are meeting (or not planning to meet). Please add or update your Work Group's agenda and papers as they become available.<br />
**Previous Working Group Meeting information links have been moved to the [[:Category:WGM_agendas|Category page for WGM agendas]] for reference. <br />
*First-Timer information here: [http://www.hl7.org/events/workgroupmeetings.cfm What is a "WGM"?]<br />
*Information for Auxiliary attendees of the WGM is available here: [[HL7 Auxiliary]]<br />
*WGM Attendee [[Lost and Found]]<br />
*Mobile On-Site App: <!--[http://eventmobi.com/may2014wgm/ here]--> TBD<br />
*[http://www.hl7.org/events/working_group_meeting/2018/01// WGM homepage]<br />
<!--*[http://www.hl7.org/documentcenter/public_temp_6036EA22-1C23-BA17-0C030676962AD1E9/brochures/wgm/HL7_WGM_20171218.pdf Event Brochure]--><br />
==Travel, Transportation and other information==<br />
*See the [http://www.hl7.org/events/working_group_meeting/2018/01/index_7.cfm WGMPage] page on the 2018Jan WG Meeting site<br />
<!--**Early Bird registration open until December 30 2014--><br />
<!--**[http://www.hl7.org/events/wgm012015/?ref=banner Online registration] is open! Onsite registration will be open Sunday, January 18, 2015 from 8:30 am – 5:00 pm --><br />
<br />
==Agendas for 2018Jan WGM, January 27 - February 2, 2018 New Orleans, LA ==<br />
===Technical Steering Committee===<br />
*[http://hl7tsc.org/wiki/index.php?title=2018-01-27_TSC_WGM_Agenda TSC WGM Agenda], Saturday Meeting<br />
*[http://hl7tsc.org/wiki/index.php?title=2018-01-28_TSC_WGM_Agenda 2018-01-28 TSC WGM Agenda], Sunday Evening Meeting<br />
*[http://hl7tsc.org/wiki/index.php?title=2018-01-30_TSC_WGM_Agenda 2018-01-30 TSC WGM Agenda], Tuesday Luncheon Meeting<br />
<br />
===Standards Governance Board===<br />
*[http://wiki.hl7.org/index.php?title=2018-01-28_SGB_WGM_Agenda 2018-01-28_SGB_WGM_Agenda, Sunday SGB Meeting]<br />
*[http://wiki.hl7.org/index.php?title=2018-02-02_SGB_WGM_Agenda 2018-02-02_SGB_WGM_Agenda, Friday SGB Meeting]<br />
<br />
===Steering Division agendas: ===<br />
DESD - <br />
FTSD - <br/><br />
SSD-SD - <br/><br />
T3SD -<br />
<br />
===Work Groups / other (project) Groups===<br />
*[[AID|Application Implementation and Design]] (The AID HL7 "User Group") - <br />
* Anesthesia - not meeting in January<br />
*[[Architecture_Board | Architecture Board (ARB)]] - [[2018_arb_neworleans_agenda | 2018 New Orleans Agenda]] - Confluence:[http://confluence.hl7.org:8090/display/ARB/New+Orleans+2018+WGM+Agenda New Orleans 2018 WGM Agenda]<br />
* [http://wiki.hl7.org/index.php?title=File:2018-01-29_Arden_Syntax_WG_Agenda_New_Orleans.pdf Arden Syntax]<br />
* Attachments - [http://www.hl7.org/documentcenter/public/wg/ca/minutes/Attachments_WG_Agenda_San_Diego_Jan2017.xlsx 2018JAN]<br />
* BR&R - [http://www.hl7.org/documentcenter/public/wg/rcrim/minutes/BRR%20%20WG%20%20Agenda%20new%20orleans%202018%20%20v5.docx 2018 JAN]<br />
* Clinical Decision Support - [http://wiki.hl7.org/index.php?title=CDS_WG_Agenda_2018-01 2018JAN]<br />
* Clinical Genomics - [http://wiki.hl7.org/index.php?title=CG_Working_Group_Meeting_Agendas All WGM Agendas] and [http://wiki.hl7.org/index.php?title=File:HL7_WGM_January2018_-_Clinical_Genomics_Agenda.pdf New Orleans Agenda]<br />
* CIMI - [[Clinical_Information_Modeling_Initiative_WG_January_2018 | 2018JAN New Orleans]]<br />
* Clinical Interoperability Council - [http://www.hl7.org/Special/committees/cic/minutes.cfm All Agendas] and <br />
* Clinical Quality Information - [http://wiki.hl7.org/index.php?title=Clinical_Quality_Information_WGM_Agendas All WGM Agendas] and [http://wiki.hl7.org/index.php?title=Clinical_Quality_Information_WG_January_2018,_New_Orleans,_Louisiana 2018JAN]<br />
* Clinical Statement - [http://wiki.hl7.org/index.php?title=CS_Jan_2017_WGM New Orleans Agenda]<br />
* Community Based Collaborative Care - [http://wiki.hl7.org/index.php?title=Community-Based_Collaborative_Care All WGM Agendas, under 'Upcoming'] and [http://wiki.hl7.org/index.php?title=January_2018_CBCP_Working_Group_Meeting_-_New_Orleans,_Louisiana,_USA 2018JAN]<br />
* Conformance - [http://wiki.hl7.org/index.php?title=Conformance_Jan_2018_WGM_Agenda WGM Agenda]<br />
* Education - [http://wiki.hl7.org/index.php?title=WGM_Agendas_and_Minutes Education WGM Agendas] and [http://wiki.hl7.org/index.php?title=January_2018_WGM_Education_Agenda 2018JAN]<br />
* EHR - [http://www.hl7.org/documentcenter/public/wg/ehr/directcare/EHR_WG_Calendar_for_Jan_2018_WGM_New%20Orleans%20(2018-01-26).xls 2018JAN]<br />
* Electronic Services and Tools - [http://wiki.hl7.org/index.php?title=EST_WGM_Agenda_2018_Jan 2018JAN]<br />
* Emergency Care - [http://wiki.hl7.org/index.php?title=EC:_Agendas_and_Minutes All ECWG WGM Agendas] and [http://wiki.hl7.org/index.php?title=January_2018_New_Orleans_Emergency_Care_Work_Group_Meeting_Agenda_and_Minutes 2018JAN]<br />
* FHIR - [http://wiki.hl7.org/index.php?title=FHIR_Agenda_201801_WGM New Orleans Agenda]<br />
* Financial Management - [http://wiki.hl7.org/index.php?title=FM_WGM_Agenda_and_Meeting_Minutes Agendas] and [http://wiki.hl7.org/index.php?title=FM_Jan_2018_New_Orleans_WGM_Agenda 2018JAN]<br />
* Health Care Devices (DEV) - [http://www.hl7.org/Special/committees/healthcaredevices/minutes.cfm Agendas and Minutes] and [http://www.hl7.org/documentcenter/public/wg/healthcaredevices/minutes/X73%20HL7%202018-01%20New%20Orleans%20Agenda%20Draft%200.5.pdf 2018JAN]<br />
* [[Healthcare Standards Integration (HSI)]] -<br />
* [[Imaging_Integration_WG|Imaging Integration]] - [http://wiki.hl7.org/index.php?title=II_WGM_Agenda_January_2018#Agenda 2018JAN]<br />
* Implementable Technology Specifications - [http://wiki.hl7.org/index.php?title=ITS_WGM_Agenda_2018_01 2018JAN]<br />
* [[Infrastructure_and_Messaging | Infrastructure and Messaging (InM)]] - [http://confluence.hl7.org:8090/display/INM/2018+InM+January+WGM+Agenda | InM New Orleans WGM agenda]]<br />
* International Council - [http://wiki.hl7.org/index.php?title=International_Council WGM Agendas] <br />
* Learning Health Systems - [http://wiki.hl7.org/index.php?title=LHS_Jan_2018_New_Orleans_Agenda 2018JAN]<br />
* Mobile Health - [http://www.hl7.org/documentcenter/public/wg/mobile/F2F%20HL7%20WGM%20MH%20WG%20Agenda%20January%202018.xlsx 2018JAN]<br />
* Modeling and Methodology (MnM) - WGM agendas on [http://gforge.hl7.org/gf/project/mnm-project/frs/?action=FrsReleaseBrowse&frs_package_id=24 Gforge], see [https://gforge.hl7.org/gf/download/frsrelease/1258/16100/MnMJan18WGMAgenda20180109.xlsx 2018 JAN]<br />
* Orders and Observations - [http://wiki.hl7.org/index.php?title=OO_WGM_Agendas OO WGM Agendas] and [http://wiki.hl7.org/index.php?title=OO_WGM_Agenda_January_2018 2018JAN]<br />
* Patient Administration - [http://wiki.hl7.org/index.php?title=2018-01_PA_WGM_Agenda New Orleans January 2018 Agenda] <br />
* Patient Care - [http://wiki.hl7.org/index.php?title=Patient_Care_Work_Group_meeting_Agenda_and_Draft_Minutes WGM Agendas] and [http://wiki.hl7.org/index.php?title=2017_PCWG_WGM_Agenda_and_Minutes 2017_PCWG_WGM_Agenda_and_Minutes], and [http://wiki.hl7.org/index.php?title=January_2018_WGM_New_Orleans;_Jan_27_to_Feb_8 2018JAN]<br />
* Pharmacy - [http://wiki.hl7.org/index.php?title=Pharmacy_Working_Group_Meeting_Agendas_and_Minutes WGM Agendas] and [http://wiki.hl7.org/index.php?title=January_2018_Pharmacy_WGM_Agenda 2018JAN]<br />
* Process Improvement -<br />
* Project Services -<br />
* Public Health - [http://52.42.5.44:8090/pages/viewpage.action?pageId=4489491&src=contextnavpagetreemode 2018JAN]<br />
* Publishing - [http://wiki.hl7.org/index.php?title=Publishing_WGM_Agenda_201802 2018JAN]<br />
* Security - [http://wiki.hl7.org/index.php?title=HL7_WGM_January_2018_-_New_Orleans_US_AGENDA 2018JAN]<br />
* Service Oriented Architecture - [[HL7 WGM Jan 2018, New Orleans]]<br />
* Structured Documents - [[SDWG_Jan_2018_New_Orleans_Agenda]]<br />
* Templates [[Templates_WGM_2018_January]] Agenda <br />
* Vocabulary - [http://confluence.hl7.org:8090/display/HL7/New+Orleans+-+January+2018 2018JAN]<br />
<br />
===Board Committees===<br />
<!-- Requested Removal of Line Below --><br />
<!-- *Organizational Relations Committee - [[Organizational_Relations_Committee:_Agendas_and_Minutes]] --><br />
*Outreach Committee for Clinical Research <br />
*International Mentoring Committee<br />
*US Realm Steering Committee -<br />
<br />
===Tutorials===<br />
'''TBD'''<br />
<!-- *[http://www.hl7.org/events/wgm052015/tutorials.cfm List of tutorials and link to brochure] --><br />
<br />
==Agenda Templates==<br />
*Excel Template from HL7 web site /participate/templates [http://www.hl7.org/documentcenter/public/utilities/WGM%20Agenda%20Template.xls link]<br />
*[[WGM_Agenda_Template|wiki version]] of Excel template<br />
<br />
<br />
[[Category:WGM agendas]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=File:PublishingMissionAndCharter.doc&diff=152056File:PublishingMissionAndCharter.doc2018-01-26T16:56:23Z<p>Bpech: Bpech uploaded a new version of &quot;File:PublishingMissionAndCharter.doc&quot;</p>
<hr />
<div>MissionAndCharter for Publishing Committee - 20080910</div>Bpechhttps://wiki.hl7.org/w/index.php?title=V2.X_Chapter_Editors&diff=152055V2.X Chapter Editors2018-01-26T16:41:22Z<p>Bpech: </p>
<hr />
<div>[[Publishing_Committee#HL7 V2 Publishing Work Group|Back to the Publishing Main Page]]<br />
<br />
'''V2.x Chapter Editors'''<br />
<br />
''As of Version 2.9''<br />
<br />
CH02 Control: Anthony Julian (ajulian (at) mayo.edu)<br />
<br />
CH02A DataTypes: Sandra Stuart (Sandra.stuart (at) kp.org)<br />
<br />
CH02B Conformance: Rob Snelick (robert.snelick (at) nist.com)<br />
<br />
CH02C CodeTables: Vocabulary Work Group - generated out of the publishing database<br />
<br />
CH03 Patient Admin: Alex Deleon (Alexander.J.Deleon (at) kp.org)<br />
<br />
CH04 Orders:– Hans Buitendijk (hans.buitendijk (at) Cerner.com) <br />
<br />
CH04A Order Entry: Pharmacy/Treatment Vaccination – Hans Buitendijk (hans.buitendijk (at) Cerner.com) <br />
<br />
CH05 Queries: Pete Gilbert, Anthony Julian (peter.gilbert (at) mhplan.com, ajulian (at) mayo.edu)<br />
<br />
CH06 Financial Mngmt: Beat Heggli (Beat.Heggli (at) netcetera.com)<br />
<br />
CH07 Observations: Hans Buitendijk (hans.buitendijk (at) Cerner.com)<br />
<br />
CH08 MasterFiles: Scott Robertson (Scott.M.Robertson (at) kp.org)<br />
<br />
CH09 MedRecords: Pete Gilbert (peter.gilbert (at) mhplan.com)<br />
<br />
CH10 Scheduling: TBD.<br />
<br />
CH11 PatientReferral: Amit Popat (amit (at) epic.com)<br />
<br />
CH12 PatientCare: Amit Popat (amit (at) epic.com)<br />
<br />
CH13 ClinicalLabAuto: Riki Merrick (rikimerrick (at) gmail.com)<br />
<br />
CH14 AppMngmt: Anthony Julian (ajulian (at) mayo.edu)<br />
<br />
CH15 PersonnelMgmt: Frank Oemig (hl7 (at) oemig.de)<br />
<br />
CH16 eClaims: Beat Heggli (Beat.Heggli (at) netcetera.com)<br />
<br />
CH17 MaterialsMgmt: Riki Merrick (rikimerrick (at) gmail.com)</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Publishing_WGM_Agenda_201802&diff=152054Publishing WGM Agenda 2018022018-01-26T16:39:46Z<p>Bpech: </p>
<hr />
<div>=== Proposed Pub WG Agenda for the Jan-Feb 2018 WGM in New Orleans, LA ===<br />
<br />
Return to: [[Publishing_Committee|Pub Main Page]]<br />
<br />
back to [[WGM_information]]<br />
<br />
<br />
<table border=1 width="100%"><br />
<tr bgcolor=#bbbbbb><br />
<td>Day</td><br />
<td>Date</td><br />
<td colspan=2>Quarter</td><br />
<td>Room</td><br />
<td>Event</td><br />
<td>Host</td><br />
<td>joining</td><br />
<td>Chair</td><br />
<td>Scribe</td><br />
<td>Notes</td><br />
</tr><br />
<br />
<tr><br />
<td rowspan=4>Sunday</td><br />
<td rowspan=4>Jan 28</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Monday</td><br />
<td rowspan=4>Jan 29</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>Publishing joint with PLA and others - Topic - V2 Management Group</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td></td><br />
<td>Publishing will not meet during this quarter.</td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Tuesday</td><br />
<td rowspan=4>Jan 30</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Wednesday</td><br />
<td rowspan=4>Jan 31</td><br />
<td rowspan=2>AM</td><br />
<td bgcolor=#8e8aff>Q1</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>V2 Publishing: V2 planning, V2.9 ballot reconciliation, Review DMP, Review Projects</td><br />
<td bgcolor=#8e8aff>Pub</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>Brian</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td bgcolor=#8e8aff>Q3</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>V2 pubs joint with Vocab: vocabulary in HL7 V2</td><br />
<td bgcolor=#8e8aff>Pub</td><br />
<td bgcolor=#8e8aff>Vocabulary</td><br />
<td bgcolor=#8e8aff>Brian</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Thursday</td><br />
<td rowspan=4>Feb 1</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Friday</td><br />
<td rowspan=4>Feb 2</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<br />
</table></div>Bpechhttps://wiki.hl7.org/w/index.php?title=Publishing_WGM_Agenda_201802&diff=151235Publishing WGM Agenda 2018022018-01-16T21:25:50Z<p>Bpech: /* Proposed Pub WG Agenda for the Jan-Feb 2018 WGM in New Orleans, LA */</p>
<hr />
<div>=== Proposed Pub WG Agenda for the Jan-Feb 2018 WGM in New Orleans, LA ===<br />
<br />
Return to: [[Publishing_Committee|Pub Main Page]]<br />
<br />
back to [[WGM_information]]<br />
<br />
<br />
<table border=1 width="100%"><br />
<tr bgcolor=#bbbbbb><br />
<td>Day</td><br />
<td>Date</td><br />
<td colspan=2>Quarter</td><br />
<td>Room</td><br />
<td>Event</td><br />
<td>Host</td><br />
<td>joining</td><br />
<td>Chair</td><br />
<td>Scribe</td><br />
<td>Notes</td><br />
</tr><br />
<br />
<tr><br />
<td rowspan=4>Sunday</td><br />
<td rowspan=4>Jan 28</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Monday</td><br />
<td rowspan=4>Jan 29</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>Publishing joint with PLA and others - Topic - V2 Management Group</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td></td><br />
<td>Publishing will not meet during this quarter.</td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Tuesday</td><br />
<td rowspan=4>Jan 30</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Wednesday</td><br />
<td rowspan=4>Jan 31</td><br />
<td rowspan=2>AM</td><br />
<td bgcolor=#8e8aff>Q1</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>V2 Publishing: V2 planning, V2.9 ballot reconciliation, Review DMP</td><br />
<td bgcolor=#8e8aff>Pub</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>Brian</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td bgcolor=#8e8aff>Q3</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>V2 pubs joint with Vocab: vocabulary in HL7 V2</td><br />
<td bgcolor=#8e8aff>Pub</td><br />
<td bgcolor=#8e8aff>Vocabulary</td><br />
<td bgcolor=#8e8aff>Brian</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Thursday</td><br />
<td rowspan=4>Feb 1</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Friday</td><br />
<td rowspan=4>Feb 2</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<br />
</table></div>Bpechhttps://wiki.hl7.org/w/index.php?title=Publishing_WGM_Agenda_201802&diff=150336Publishing WGM Agenda 2018022017-12-20T20:11:00Z<p>Bpech: </p>
<hr />
<div>=== Proposed Pub WG Agenda for the Jan-Feb 2018 WGM in New Orleans, LA ===<br />
<br />
Return to: [[Publishing_Committee|Pub Main Page]]<br />
<br />
back to [[WGM_information]]<br />
<br />
<br />
<table border=1 width="100%"><br />
<tr bgcolor=#bbbbbb><br />
<td>Day</td><br />
<td>Date</td><br />
<td colspan=2>Quarter</td><br />
<td>Room</td><br />
<td>Event</td><br />
<td>Host</td><br />
<td>joining</td><br />
<td>Chair</td><br />
<td>Scribe</td><br />
<td>Notes</td><br />
</tr><br />
<br />
<tr><br />
<td rowspan=4>Sunday</td><br />
<td rowspan=4>Jan 28</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Monday</td><br />
<td rowspan=4>Jan 29</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>Publishing joint with PLA and others - Topic - V2 Management Group</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td></td><br />
<td>Publishing will not meet during this quarter.</td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td rowspan=4>Tuesday</td><br />
<td rowspan=4>Jan 30</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Wednesday</td><br />
<td rowspan=4>Jan 31</td><br />
<td rowspan=2>AM</td><br />
<td bgcolor=#8e8aff>Q1</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>V2 Publishing: V2 planning, V2.9 ballot reconciliation</td><br />
<td bgcolor=#8e8aff>Pub</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>Brian</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td bgcolor=#8e8aff>Q3</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff>V2 pubs joint with Vocab: vocabulary in HL7 V2</td><br />
<td bgcolor=#8e8aff>Pub</td><br />
<td bgcolor=#8e8aff>Vocabulary</td><br />
<td bgcolor=#8e8aff>Brian</td><br />
<td bgcolor=#8e8aff></td><br />
<td bgcolor=#8e8aff></td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Thursday</td><br />
<td rowspan=4>Feb 1</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=4>Friday</td><br />
<td rowspan=4>Feb 2</td><br />
<td rowspan=2>AM</td><br />
<td>Q1</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q2</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td rowspan=2>PM</td><br />
<td>Q3</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td>Q4</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<br />
</table></div>Bpechhttps://wiki.hl7.org/w/index.php?title=Publishing_Committee&diff=148965Publishing Committee2017-11-11T10:37:11Z<p>Bpech: /* Upcoming Meetings */</p>
<hr />
<div>== Publishing Work Group Mission and Related Planning Documents==<br />
NOTE: As of September 2017, the distinction between v2 and v3 Publishing no longer holds. The Work Group is now the Publishing Work Group. We retain the v2 Sub Grouping for old documents as a matter of history.<br />
*[http://wiki.hl7.org/index.php?title=Image:PublishingMissionAndCharter.doc Mission and Charter Statement]<br />
<br />
==Pages managed by the Publishing Work Group==<br />
*[[Normative Edition]], [[Development Edition]]<br />
<br />
==Upcoming Meetings==<br />
<br />
Publishing meets every other Tuesday at 3 PM EST with adjustments for holidays.<br />
<br />
Check the HL7 Conference call schedule for upcoming meetings: [http://www.hl7.org/concalls/Default.aspx Conference Center]<br />
<br />
Dial-in Number (United States): (515) 604-9581<br />
<br />
Access Code: 243646<br />
<br />
International Dial-in Numbers: https://www.freeconferencecall.com/wall/editors6#international<br />
<br />
Online Meeting Link: https://join.freeconferencecall.com/editors6<br />
<br />
Online Meeting ID: editors6<br />
<br />
<br />
<br />
FAQ’s, tips and other helpful information regarding FreeConferenceCall.com is available at www.HL7.org > Resources > Tools and Resources > FreeConferenceCall.com Tip Sheet.<br />
<br />
<br />
Meeting notes can be found in the HL7 document center: [http://www.hl7.org/Special/committees/publishing/index.cfm Meeting Notes]<br />
<br />
==WGM Agendas and Minutes==<br />
*[[Publishing WGM Agenda 201802|New Orleans LA, Jan-Feb 2018]]<br />
*[[Publishing WGM Agenda 201709|San Diego CA, September 2017]]<br />
*[[Publishing WGM Agenda 201705|Madrid Spain, May 2017]]<br />
*[[Publishing WGM Agenda 201701|San Antonio TX, Jan 2017]]<br />
<br />
==HL7 V2.x Publishing Sub Group==<br />
The V2.x Publishing Work Group is responsible for the publishing of HL7 Version 2.x<br />
*[[V2.X_Chapter_Editors|Version 2.x Chapter Editors]]<br />
<br />
<br />
*[[May 2017 WGM V2 Publishing agenda | V2 Publishing May 2017 agenda Madrid, Spain]]<br />
*[[Jan. 2017 WGM V2 Publishing agenda | V2 Publishing Jan. 2017 agenda San Antonio, TX]]<br />
*[[Sept. 2016 WGM V2 Publishing agenda | V2 Publishing Sept. 2016 agenda Baltimore, MD]]<br />
*[[May 2016 WGM V2 Publishing agenda | V2 Publishing May 2016 agenda Montreal, Quebec]]<br />
*[[Jan. 2016 WGM V2 Publishing agenda | V2 Publishing Jan. 2016 agenda Orlando, FL]]<br />
*[[Oct. 2015 WGM V2 Publishing agenda | V2 Publishing Oct. 2015 agenda Atlanta, GA]] <br />
*[[May 2015 WGM V2 Publishing agenda | V2 Publishing May 2015 agenda Paris, France]]<br />
*[[Jan. 2015 WGM V2 Publishing agenda | V2 Publishing Jan. 2015 agenda San Antonio, TX]]<br />
*[[Sept. 2014 WGM V2 publishing agenda|V2 Publishing Sept. 2014 Agenda Chicago, IL ]]<br />
<br />
<br />
* [[V2_Examples_Requirements |V2.x Examples Requirements]]<br />
<br />
* [[V2.9 Chapter Status]]<br />
<br />
<br />
*[http://gforge.hl7.org/gf/project/v2-ballot-pkg/ V2 Publishing Packages in SVN on G-Forge] (Select SVN and click 'Trunk')<br />
<br />
==V2.x Publishing Refactor project==<br />
*[[v2.x_refactor_requirements]]<br />
<br />
==V2.x Publishing "How To ..." Documents==<br />
HL7 V2.x:<br />
* HL7 V2.x Style Guide (Vxx)<br />
*[http://www.hl7.org/documentcenter/public/wg/publishing/V2.7%20Style%20Guide%20-%2044.doc latest]<br />
<br />
==HL7 V3 Publishing Sub Group==<br />
The V3 Publishing is responsible for publishing all HL7 non-V2.x Standards (V3 Messaging, CDA, etc.)<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_PublishingSWOT.doc V3 Publishing Strengths, Weaknesses, Opportunities & Threats (SWOT) Analysis - 9/2008]<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_Publishing_2008_Strategy_Plan.zip V3 Publishing 3-yr Strategic Plan - 9/2008]<br />
<br />
===Minutes, Conference Calls and WGM===<br />
*[[Recent Publishing ConCall Minutes|Minutes of Recent V3 Pub Calls]]<br />
*[[V3_Publishing_WGM_Agenda_2016_09|Agenda for September 2016 WGM in Baltimore]]<br />
*[[V3 Publishing WGM Agenda 2016 05|Agenda for May 2016 WGM in Montreal ]]'''<br />
*[[V3 Publishing WGM Agenda 2015 10|Agenda for October 2015 WGM in Atlanta ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 09|Agenda for September 2014 WGM in Chicago ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 05|Agenda for May 2014 WGM in Phoenix ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 09|Agenda for September 2013 WGM in Cambridge ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 05|Agenda for May 2013 WGM in Atlanta ]]'''<br />
<br />
===Issues and Current Work===<br />
*[[:category:V3 Publishing Issues|V3 Publishing Issues Category]]<br />
**[[:category:Referred Publishing Items|Reconciliation Issues "Referred" to V3 Publishing]]<br />
**[[Publishing Facilitators Guide Updates]]<br />
*[[Normative_Edition_2018_Review_List_by_WG|Normative Edition 2018 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2017_Review_List_by_WG|Normative Edition 2017 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2016_Review_List_by_WG|Normative Edition 2016 Content Review List Sorted By WG]]<br />
*[[V3 Publishing ANT Refactor]]<br />
*[[V3 Generator Acceptance Testing]]<br />
*[[V3 Publishing FAQ|V3 Publishing Frequently Asked Questions]]<br />
*[[V3_Patch_Policy|V3 Patching Policy for the V3 Ballot Web Site]]<br />
*[http://www.hl7.org/special/committees/publishing/schedules.cfm Annual Publishing Calendar from HL7 web site]<br />
<br />
===V3 Publishing "How To ..." Documents===<br />
HL7 V3:<br />
*[[V3 Publishing Process Overview]]<br />
*[[Publishing and Linking Thumbnail Graphics| How to Edit, Hyperlink and Publish Thumbnail Graphics with Desktop Publishing]]<br />
*[[CMET Documentation Guidelines| How to create documentation for CMETs]]<br />
*[[V3_Publishing_Process_Steps|V3 Publishing Process Steps Overview]]<br />
*[[V3_PubProcess_-_Prepare_Freehand_MIF|How to Edit Free-Hand MIF files]]<br />
*[[CMET Publication Task Workflow for Facilitators]]<br />
*[[Directory Structure in Subversion|Directory Structure for Version Control of V3 Publishing in Subversion]]<br />
*[[V3_PubProcess_Content_Submission|V3 Domain Content Preparation for Ballot Submission]]<br />
*[[Reconciliation_HowTo|How To Reconcile a Ballot, a General Overview]]<br />
*[[Withdraw_Negative|How to Withdraw Your Negative Vote on a Ballot]]<br />
*[[V3_Publishing_Section_and_Domain_Codes|Explanation of Section and Domain Codes in Ballot artifacts]]<br />
*[[:category:HowTo|All HowTos]]<br />
<br />
===V3 Publishing Older Items...===<br />
*[[:Category:V3 Publishing Tasks|'''VERY OLD''' V3 Publishing Task List as a "'''Category'''" of articles]]<br />
*[[Normative Edition 2011 Review List|Content Review List for Normative Edition 2011]]<br />
*[[Normative Edition 2010 Content List|Content Review List for Normative Edition 2010]]<br />
<br />
[[Category:Work_Group]]<br />
[[Category:Technical and Support Services Steering Division]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Publishing_Committee&diff=148964Publishing Committee2017-11-11T10:34:24Z<p>Bpech: /* Upcoming Meetings */</p>
<hr />
<div>== Publishing Work Group Mission and Related Planning Documents==<br />
NOTE: As of September 2017, the distinction between v2 and v3 Publishing no longer holds. The Work Group is now the Publishing Work Group. We retain the v2 Sub Grouping for old documents as a matter of history.<br />
*[http://wiki.hl7.org/index.php?title=Image:PublishingMissionAndCharter.doc Mission and Charter Statement]<br />
<br />
==Pages managed by the Publishing Work Group==<br />
*[[Normative Edition]], [[Development Edition]]<br />
<br />
==Upcoming Meetings==<br />
<br />
Publishing meets every other Tuesday at 3 PM EST with adjustments for holidays.<br />
<br />
Check the HL7 Conference call schedule for upcoming meetings. [http://www.hl7.org/concalls/Default.aspx Conference Center]<br />
<br />
Dial-in Number (United States): (515) 604-9581<br />
<br />
Access Code: 243646<br />
<br />
International Dial-in Numbers: https://www.freeconferencecall.com/wall/editors6#international<br />
<br />
Online Meeting Link: https://join.freeconferencecall.com/editors6<br />
<br />
Online Meeting ID: editors6<br />
<br />
<br />
<br />
FAQ’s, tips and other helpful information regarding FreeConferenceCall.com is available at www.HL7.org > Resources > Tools and Resources > FreeConferenceCall.com Tip Sheet.<br />
<br />
<br />
Meeting notes can be found in the HL7 document center: [http://www.hl7.org/Special/committees/publishing/index.cfm Meeting Notes]<br />
<br />
==WGM Agendas and Minutes==<br />
*[[Publishing WGM Agenda 201802|New Orleans LA, Jan-Feb 2018]]<br />
*[[Publishing WGM Agenda 201709|San Diego CA, September 2017]]<br />
*[[Publishing WGM Agenda 201705|Madrid Spain, May 2017]]<br />
*[[Publishing WGM Agenda 201701|San Antonio TX, Jan 2017]]<br />
<br />
==HL7 V2.x Publishing Sub Group==<br />
The V2.x Publishing Work Group is responsible for the publishing of HL7 Version 2.x<br />
*[[V2.X_Chapter_Editors|Version 2.x Chapter Editors]]<br />
<br />
<br />
*[[May 2017 WGM V2 Publishing agenda | V2 Publishing May 2017 agenda Madrid, Spain]]<br />
*[[Jan. 2017 WGM V2 Publishing agenda | V2 Publishing Jan. 2017 agenda San Antonio, TX]]<br />
*[[Sept. 2016 WGM V2 Publishing agenda | V2 Publishing Sept. 2016 agenda Baltimore, MD]]<br />
*[[May 2016 WGM V2 Publishing agenda | V2 Publishing May 2016 agenda Montreal, Quebec]]<br />
*[[Jan. 2016 WGM V2 Publishing agenda | V2 Publishing Jan. 2016 agenda Orlando, FL]]<br />
*[[Oct. 2015 WGM V2 Publishing agenda | V2 Publishing Oct. 2015 agenda Atlanta, GA]] <br />
*[[May 2015 WGM V2 Publishing agenda | V2 Publishing May 2015 agenda Paris, France]]<br />
*[[Jan. 2015 WGM V2 Publishing agenda | V2 Publishing Jan. 2015 agenda San Antonio, TX]]<br />
*[[Sept. 2014 WGM V2 publishing agenda|V2 Publishing Sept. 2014 Agenda Chicago, IL ]]<br />
<br />
<br />
* [[V2_Examples_Requirements |V2.x Examples Requirements]]<br />
<br />
* [[V2.9 Chapter Status]]<br />
<br />
<br />
*[http://gforge.hl7.org/gf/project/v2-ballot-pkg/ V2 Publishing Packages in SVN on G-Forge] (Select SVN and click 'Trunk')<br />
<br />
==V2.x Publishing Refactor project==<br />
*[[v2.x_refactor_requirements]]<br />
<br />
==V2.x Publishing "How To ..." Documents==<br />
HL7 V2.x:<br />
* HL7 V2.x Style Guide (Vxx)<br />
*[http://www.hl7.org/documentcenter/public/wg/publishing/V2.7%20Style%20Guide%20-%2044.doc latest]<br />
<br />
==HL7 V3 Publishing Sub Group==<br />
The V3 Publishing is responsible for publishing all HL7 non-V2.x Standards (V3 Messaging, CDA, etc.)<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_PublishingSWOT.doc V3 Publishing Strengths, Weaknesses, Opportunities & Threats (SWOT) Analysis - 9/2008]<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_Publishing_2008_Strategy_Plan.zip V3 Publishing 3-yr Strategic Plan - 9/2008]<br />
<br />
===Minutes, Conference Calls and WGM===<br />
*[[Recent Publishing ConCall Minutes|Minutes of Recent V3 Pub Calls]]<br />
*[[V3_Publishing_WGM_Agenda_2016_09|Agenda for September 2016 WGM in Baltimore]]<br />
*[[V3 Publishing WGM Agenda 2016 05|Agenda for May 2016 WGM in Montreal ]]'''<br />
*[[V3 Publishing WGM Agenda 2015 10|Agenda for October 2015 WGM in Atlanta ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 09|Agenda for September 2014 WGM in Chicago ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 05|Agenda for May 2014 WGM in Phoenix ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 09|Agenda for September 2013 WGM in Cambridge ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 05|Agenda for May 2013 WGM in Atlanta ]]'''<br />
<br />
===Issues and Current Work===<br />
*[[:category:V3 Publishing Issues|V3 Publishing Issues Category]]<br />
**[[:category:Referred Publishing Items|Reconciliation Issues "Referred" to V3 Publishing]]<br />
**[[Publishing Facilitators Guide Updates]]<br />
*[[Normative_Edition_2018_Review_List_by_WG|Normative Edition 2018 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2017_Review_List_by_WG|Normative Edition 2017 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2016_Review_List_by_WG|Normative Edition 2016 Content Review List Sorted By WG]]<br />
*[[V3 Publishing ANT Refactor]]<br />
*[[V3 Generator Acceptance Testing]]<br />
*[[V3 Publishing FAQ|V3 Publishing Frequently Asked Questions]]<br />
*[[V3_Patch_Policy|V3 Patching Policy for the V3 Ballot Web Site]]<br />
*[http://www.hl7.org/special/committees/publishing/schedules.cfm Annual Publishing Calendar from HL7 web site]<br />
<br />
===V3 Publishing "How To ..." Documents===<br />
HL7 V3:<br />
*[[V3 Publishing Process Overview]]<br />
*[[Publishing and Linking Thumbnail Graphics| How to Edit, Hyperlink and Publish Thumbnail Graphics with Desktop Publishing]]<br />
*[[CMET Documentation Guidelines| How to create documentation for CMETs]]<br />
*[[V3_Publishing_Process_Steps|V3 Publishing Process Steps Overview]]<br />
*[[V3_PubProcess_-_Prepare_Freehand_MIF|How to Edit Free-Hand MIF files]]<br />
*[[CMET Publication Task Workflow for Facilitators]]<br />
*[[Directory Structure in Subversion|Directory Structure for Version Control of V3 Publishing in Subversion]]<br />
*[[V3_PubProcess_Content_Submission|V3 Domain Content Preparation for Ballot Submission]]<br />
*[[Reconciliation_HowTo|How To Reconcile a Ballot, a General Overview]]<br />
*[[Withdraw_Negative|How to Withdraw Your Negative Vote on a Ballot]]<br />
*[[V3_Publishing_Section_and_Domain_Codes|Explanation of Section and Domain Codes in Ballot artifacts]]<br />
*[[:category:HowTo|All HowTos]]<br />
<br />
===V3 Publishing Older Items...===<br />
*[[:Category:V3 Publishing Tasks|'''VERY OLD''' V3 Publishing Task List as a "'''Category'''" of articles]]<br />
*[[Normative Edition 2011 Review List|Content Review List for Normative Edition 2011]]<br />
*[[Normative Edition 2010 Content List|Content Review List for Normative Edition 2010]]<br />
<br />
[[Category:Work_Group]]<br />
[[Category:Technical and Support Services Steering Division]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Publishing_Committee&diff=148963Publishing Committee2017-11-11T10:33:14Z<p>Bpech: /* Upcoming Meetings */</p>
<hr />
<div>== Publishing Work Group Mission and Related Planning Documents==<br />
NOTE: As of September 2017, the distinction between v2 and v3 Publishing no longer holds. The Work Group is now the Publishing Work Group. We retain the v2 Sub Grouping for old documents as a matter of history.<br />
*[http://wiki.hl7.org/index.php?title=Image:PublishingMissionAndCharter.doc Mission and Charter Statement]<br />
<br />
==Pages managed by the Publishing Work Group==<br />
*[[Normative Edition]], [[Development Edition]]<br />
<br />
==Upcoming Meetings==<br />
<br />
Publishing meets every other Tuesday at 3 PM EST with adjustments for holidays.<br />
<br />
Check the HL7 Conference call schedule for upcoming meetings. (http://www.hl7.org/concalls/Default.aspx)<br />
<br />
Dial-in Number (United States): (515) 604-9581<br />
<br />
Access Code: 243646<br />
<br />
International Dial-in Numbers: https://www.freeconferencecall.com/wall/editors6#international<br />
<br />
Online Meeting Link: https://join.freeconferencecall.com/editors6<br />
<br />
Online Meeting ID: editors6<br />
<br />
<br />
<br />
FAQ’s, tips and other helpful information regarding FreeConferenceCall.com is available at www.HL7.org > Resources > Tools and Resources > FreeConferenceCall.com Tip Sheet.<br />
<br />
<br />
Meeting notes can be found in the HL7 document center: [http://www.hl7.org/Special/committees/publishing/index.cfm Meeting Notes]<br />
<br />
==WGM Agendas and Minutes==<br />
*[[Publishing WGM Agenda 201802|New Orleans LA, Jan-Feb 2018]]<br />
*[[Publishing WGM Agenda 201709|San Diego CA, September 2017]]<br />
*[[Publishing WGM Agenda 201705|Madrid Spain, May 2017]]<br />
*[[Publishing WGM Agenda 201701|San Antonio TX, Jan 2017]]<br />
<br />
==HL7 V2.x Publishing Sub Group==<br />
The V2.x Publishing Work Group is responsible for the publishing of HL7 Version 2.x<br />
*[[V2.X_Chapter_Editors|Version 2.x Chapter Editors]]<br />
<br />
<br />
*[[May 2017 WGM V2 Publishing agenda | V2 Publishing May 2017 agenda Madrid, Spain]]<br />
*[[Jan. 2017 WGM V2 Publishing agenda | V2 Publishing Jan. 2017 agenda San Antonio, TX]]<br />
*[[Sept. 2016 WGM V2 Publishing agenda | V2 Publishing Sept. 2016 agenda Baltimore, MD]]<br />
*[[May 2016 WGM V2 Publishing agenda | V2 Publishing May 2016 agenda Montreal, Quebec]]<br />
*[[Jan. 2016 WGM V2 Publishing agenda | V2 Publishing Jan. 2016 agenda Orlando, FL]]<br />
*[[Oct. 2015 WGM V2 Publishing agenda | V2 Publishing Oct. 2015 agenda Atlanta, GA]] <br />
*[[May 2015 WGM V2 Publishing agenda | V2 Publishing May 2015 agenda Paris, France]]<br />
*[[Jan. 2015 WGM V2 Publishing agenda | V2 Publishing Jan. 2015 agenda San Antonio, TX]]<br />
*[[Sept. 2014 WGM V2 publishing agenda|V2 Publishing Sept. 2014 Agenda Chicago, IL ]]<br />
<br />
<br />
* [[V2_Examples_Requirements |V2.x Examples Requirements]]<br />
<br />
* [[V2.9 Chapter Status]]<br />
<br />
<br />
*[http://gforge.hl7.org/gf/project/v2-ballot-pkg/ V2 Publishing Packages in SVN on G-Forge] (Select SVN and click 'Trunk')<br />
<br />
==V2.x Publishing Refactor project==<br />
*[[v2.x_refactor_requirements]]<br />
<br />
==V2.x Publishing "How To ..." Documents==<br />
HL7 V2.x:<br />
* HL7 V2.x Style Guide (Vxx)<br />
*[http://www.hl7.org/documentcenter/public/wg/publishing/V2.7%20Style%20Guide%20-%2044.doc latest]<br />
<br />
==HL7 V3 Publishing Sub Group==<br />
The V3 Publishing is responsible for publishing all HL7 non-V2.x Standards (V3 Messaging, CDA, etc.)<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_PublishingSWOT.doc V3 Publishing Strengths, Weaknesses, Opportunities & Threats (SWOT) Analysis - 9/2008]<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_Publishing_2008_Strategy_Plan.zip V3 Publishing 3-yr Strategic Plan - 9/2008]<br />
<br />
===Minutes, Conference Calls and WGM===<br />
*[[Recent Publishing ConCall Minutes|Minutes of Recent V3 Pub Calls]]<br />
*[[V3_Publishing_WGM_Agenda_2016_09|Agenda for September 2016 WGM in Baltimore]]<br />
*[[V3 Publishing WGM Agenda 2016 05|Agenda for May 2016 WGM in Montreal ]]'''<br />
*[[V3 Publishing WGM Agenda 2015 10|Agenda for October 2015 WGM in Atlanta ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 09|Agenda for September 2014 WGM in Chicago ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 05|Agenda for May 2014 WGM in Phoenix ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 09|Agenda for September 2013 WGM in Cambridge ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 05|Agenda for May 2013 WGM in Atlanta ]]'''<br />
<br />
===Issues and Current Work===<br />
*[[:category:V3 Publishing Issues|V3 Publishing Issues Category]]<br />
**[[:category:Referred Publishing Items|Reconciliation Issues "Referred" to V3 Publishing]]<br />
**[[Publishing Facilitators Guide Updates]]<br />
*[[Normative_Edition_2018_Review_List_by_WG|Normative Edition 2018 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2017_Review_List_by_WG|Normative Edition 2017 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2016_Review_List_by_WG|Normative Edition 2016 Content Review List Sorted By WG]]<br />
*[[V3 Publishing ANT Refactor]]<br />
*[[V3 Generator Acceptance Testing]]<br />
*[[V3 Publishing FAQ|V3 Publishing Frequently Asked Questions]]<br />
*[[V3_Patch_Policy|V3 Patching Policy for the V3 Ballot Web Site]]<br />
*[http://www.hl7.org/special/committees/publishing/schedules.cfm Annual Publishing Calendar from HL7 web site]<br />
<br />
===V3 Publishing "How To ..." Documents===<br />
HL7 V3:<br />
*[[V3 Publishing Process Overview]]<br />
*[[Publishing and Linking Thumbnail Graphics| How to Edit, Hyperlink and Publish Thumbnail Graphics with Desktop Publishing]]<br />
*[[CMET Documentation Guidelines| How to create documentation for CMETs]]<br />
*[[V3_Publishing_Process_Steps|V3 Publishing Process Steps Overview]]<br />
*[[V3_PubProcess_-_Prepare_Freehand_MIF|How to Edit Free-Hand MIF files]]<br />
*[[CMET Publication Task Workflow for Facilitators]]<br />
*[[Directory Structure in Subversion|Directory Structure for Version Control of V3 Publishing in Subversion]]<br />
*[[V3_PubProcess_Content_Submission|V3 Domain Content Preparation for Ballot Submission]]<br />
*[[Reconciliation_HowTo|How To Reconcile a Ballot, a General Overview]]<br />
*[[Withdraw_Negative|How to Withdraw Your Negative Vote on a Ballot]]<br />
*[[V3_Publishing_Section_and_Domain_Codes|Explanation of Section and Domain Codes in Ballot artifacts]]<br />
*[[:category:HowTo|All HowTos]]<br />
<br />
===V3 Publishing Older Items...===<br />
*[[:Category:V3 Publishing Tasks|'''VERY OLD''' V3 Publishing Task List as a "'''Category'''" of articles]]<br />
*[[Normative Edition 2011 Review List|Content Review List for Normative Edition 2011]]<br />
*[[Normative Edition 2010 Content List|Content Review List for Normative Edition 2010]]<br />
<br />
[[Category:Work_Group]]<br />
[[Category:Technical and Support Services Steering Division]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Publishing_Committee&diff=148962Publishing Committee2017-11-11T10:32:01Z<p>Bpech: /* Upcoming Meetings */</p>
<hr />
<div>== Publishing Work Group Mission and Related Planning Documents==<br />
NOTE: As of September 2017, the distinction between v2 and v3 Publishing no longer holds. The Work Group is now the Publishing Work Group. We retain the v2 Sub Grouping for old documents as a matter of history.<br />
*[http://wiki.hl7.org/index.php?title=Image:PublishingMissionAndCharter.doc Mission and Charter Statement]<br />
<br />
==Pages managed by the Publishing Work Group==<br />
*[[Normative Edition]], [[Development Edition]]<br />
<br />
==Upcoming Meetings==<br />
<br />
Publishing meets every other Tuesday at 3 PM EST with adjustments for holidays.<br />
<br />
Check the HL7 Conference call schedule for upcoming meetings. (http://www.hl7.org/concalls/Default.aspx)<br />
<br />
Dial-in Number (United States): (515) 604-9581<br />
<br />
Access Code: 243646<br />
<br />
International Dial-in Numbers: https://www.freeconferencecall.com/wall/editors6#international<br />
<br />
Online Meeting Link: https://join.freeconferencecall.com/editors6<br />
<br />
Online Meeting ID: editors6<br />
<br />
<br />
<br />
FAQ’s, tips and other helpful information regarding FreeConferenceCall.com is available at www.HL7.org > Resources > Tools and Resources > FreeConferenceCall.com Tip Sheet.<br />
<br />
<br />
Meeting notes can be found in the HL7 document center: [ http://www.hl7.org/Special/committees/publishing/index.cfm Meeting Notes]<br />
<br />
==WGM Agendas and Minutes==<br />
*[[Publishing WGM Agenda 201802|New Orleans LA, Jan-Feb 2018]]<br />
*[[Publishing WGM Agenda 201709|San Diego CA, September 2017]]<br />
*[[Publishing WGM Agenda 201705|Madrid Spain, May 2017]]<br />
*[[Publishing WGM Agenda 201701|San Antonio TX, Jan 2017]]<br />
<br />
==HL7 V2.x Publishing Sub Group==<br />
The V2.x Publishing Work Group is responsible for the publishing of HL7 Version 2.x<br />
*[[V2.X_Chapter_Editors|Version 2.x Chapter Editors]]<br />
<br />
<br />
*[[May 2017 WGM V2 Publishing agenda | V2 Publishing May 2017 agenda Madrid, Spain]]<br />
*[[Jan. 2017 WGM V2 Publishing agenda | V2 Publishing Jan. 2017 agenda San Antonio, TX]]<br />
*[[Sept. 2016 WGM V2 Publishing agenda | V2 Publishing Sept. 2016 agenda Baltimore, MD]]<br />
*[[May 2016 WGM V2 Publishing agenda | V2 Publishing May 2016 agenda Montreal, Quebec]]<br />
*[[Jan. 2016 WGM V2 Publishing agenda | V2 Publishing Jan. 2016 agenda Orlando, FL]]<br />
*[[Oct. 2015 WGM V2 Publishing agenda | V2 Publishing Oct. 2015 agenda Atlanta, GA]] <br />
*[[May 2015 WGM V2 Publishing agenda | V2 Publishing May 2015 agenda Paris, France]]<br />
*[[Jan. 2015 WGM V2 Publishing agenda | V2 Publishing Jan. 2015 agenda San Antonio, TX]]<br />
*[[Sept. 2014 WGM V2 publishing agenda|V2 Publishing Sept. 2014 Agenda Chicago, IL ]]<br />
<br />
<br />
* [[V2_Examples_Requirements |V2.x Examples Requirements]]<br />
<br />
* [[V2.9 Chapter Status]]<br />
<br />
<br />
*[http://gforge.hl7.org/gf/project/v2-ballot-pkg/ V2 Publishing Packages in SVN on G-Forge] (Select SVN and click 'Trunk')<br />
<br />
==V2.x Publishing Refactor project==<br />
*[[v2.x_refactor_requirements]]<br />
<br />
==V2.x Publishing "How To ..." Documents==<br />
HL7 V2.x:<br />
* HL7 V2.x Style Guide (Vxx)<br />
*[http://www.hl7.org/documentcenter/public/wg/publishing/V2.7%20Style%20Guide%20-%2044.doc latest]<br />
<br />
==HL7 V3 Publishing Sub Group==<br />
The V3 Publishing is responsible for publishing all HL7 non-V2.x Standards (V3 Messaging, CDA, etc.)<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_PublishingSWOT.doc V3 Publishing Strengths, Weaknesses, Opportunities & Threats (SWOT) Analysis - 9/2008]<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_Publishing_2008_Strategy_Plan.zip V3 Publishing 3-yr Strategic Plan - 9/2008]<br />
<br />
===Minutes, Conference Calls and WGM===<br />
*[[Recent Publishing ConCall Minutes|Minutes of Recent V3 Pub Calls]]<br />
*[[V3_Publishing_WGM_Agenda_2016_09|Agenda for September 2016 WGM in Baltimore]]<br />
*[[V3 Publishing WGM Agenda 2016 05|Agenda for May 2016 WGM in Montreal ]]'''<br />
*[[V3 Publishing WGM Agenda 2015 10|Agenda for October 2015 WGM in Atlanta ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 09|Agenda for September 2014 WGM in Chicago ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 05|Agenda for May 2014 WGM in Phoenix ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 09|Agenda for September 2013 WGM in Cambridge ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 05|Agenda for May 2013 WGM in Atlanta ]]'''<br />
<br />
===Issues and Current Work===<br />
*[[:category:V3 Publishing Issues|V3 Publishing Issues Category]]<br />
**[[:category:Referred Publishing Items|Reconciliation Issues "Referred" to V3 Publishing]]<br />
**[[Publishing Facilitators Guide Updates]]<br />
*[[Normative_Edition_2018_Review_List_by_WG|Normative Edition 2018 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2017_Review_List_by_WG|Normative Edition 2017 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2016_Review_List_by_WG|Normative Edition 2016 Content Review List Sorted By WG]]<br />
*[[V3 Publishing ANT Refactor]]<br />
*[[V3 Generator Acceptance Testing]]<br />
*[[V3 Publishing FAQ|V3 Publishing Frequently Asked Questions]]<br />
*[[V3_Patch_Policy|V3 Patching Policy for the V3 Ballot Web Site]]<br />
*[http://www.hl7.org/special/committees/publishing/schedules.cfm Annual Publishing Calendar from HL7 web site]<br />
<br />
===V3 Publishing "How To ..." Documents===<br />
HL7 V3:<br />
*[[V3 Publishing Process Overview]]<br />
*[[Publishing and Linking Thumbnail Graphics| How to Edit, Hyperlink and Publish Thumbnail Graphics with Desktop Publishing]]<br />
*[[CMET Documentation Guidelines| How to create documentation for CMETs]]<br />
*[[V3_Publishing_Process_Steps|V3 Publishing Process Steps Overview]]<br />
*[[V3_PubProcess_-_Prepare_Freehand_MIF|How to Edit Free-Hand MIF files]]<br />
*[[CMET Publication Task Workflow for Facilitators]]<br />
*[[Directory Structure in Subversion|Directory Structure for Version Control of V3 Publishing in Subversion]]<br />
*[[V3_PubProcess_Content_Submission|V3 Domain Content Preparation for Ballot Submission]]<br />
*[[Reconciliation_HowTo|How To Reconcile a Ballot, a General Overview]]<br />
*[[Withdraw_Negative|How to Withdraw Your Negative Vote on a Ballot]]<br />
*[[V3_Publishing_Section_and_Domain_Codes|Explanation of Section and Domain Codes in Ballot artifacts]]<br />
*[[:category:HowTo|All HowTos]]<br />
<br />
===V3 Publishing Older Items...===<br />
*[[:Category:V3 Publishing Tasks|'''VERY OLD''' V3 Publishing Task List as a "'''Category'''" of articles]]<br />
*[[Normative Edition 2011 Review List|Content Review List for Normative Edition 2011]]<br />
*[[Normative Edition 2010 Content List|Content Review List for Normative Edition 2010]]<br />
<br />
[[Category:Work_Group]]<br />
[[Category:Technical and Support Services Steering Division]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Publishing_Committee&diff=148961Publishing Committee2017-11-11T10:23:49Z<p>Bpech: /* Upcoming Meetings */</p>
<hr />
<div>== Publishing Work Group Mission and Related Planning Documents==<br />
NOTE: As of September 2017, the distinction between v2 and v3 Publishing no longer holds. The Work Group is now the Publishing Work Group. We retain the v2 Sub Grouping for old documents as a matter of history.<br />
*[http://wiki.hl7.org/index.php?title=Image:PublishingMissionAndCharter.doc Mission and Charter Statement]<br />
<br />
==Pages managed by the Publishing Work Group==<br />
*[[Normative Edition]], [[Development Edition]]<br />
<br />
==Upcoming Meetings==<br />
<br />
Publishing meets every other Tuesday at 3 PM EST with adjustments for holidays.<br />
<br />
Check the HL7 Conference call schedule for upcoming meetings. (http://www.hl7.org/concalls/Default.aspx)<br />
<br />
Dial-in Number (United States): (515) 604-9581<br />
<br />
Access Code: 243646<br />
<br />
International Dial-in Numbers: https://www.freeconferencecall.com/wall/editors6#international<br />
<br />
Online Meeting Link: https://join.freeconferencecall.com/editors6<br />
<br />
Online Meeting ID: editors6<br />
<br />
<br />
<br />
FAQ’s, tips and other helpful information regarding FreeConferenceCall.com is available at www.HL7.org > Resources > Tools and Resources > FreeConferenceCall.com Tip Sheet.<br />
<br />
<br />
<br />
<br />
<br />
*[[Pub Agenda telecon|2017-08-28]]<br />
*[[Pub Agenda telecon|2017-07-31]]<br />
*[[Pub Agenda telecon|2017-06-26]]<br />
<br />
===Past Meeting Minutes===<br />
*[[Publishing_Call_Minutes_20170109|Publishing Call 2017-01-09]]<br />
*[[Publishing_Call_Minutes_20170213|Publishing Call 2017-02-13]]<br />
*[[Publishing_Call_Minutes_20170313|Publishing Call 2017-03-13]]<br />
*[[Publishing_Call_Minutes_20170327|Publishing Call 2017-03-27]]<br />
<br />
==WGM Agendas and Minutes==<br />
*[[Publishing WGM Agenda 201802|New Orleans LA, Jan-Feb 2018]]<br />
*[[Publishing WGM Agenda 201709|San Diego CA, September 2017]]<br />
*[[Publishing WGM Agenda 201705|Madrid Spain, May 2017]]<br />
*[[Publishing WGM Agenda 201701|San Antonio TX, Jan 2017]]<br />
<br />
==HL7 V2.x Publishing Sub Group==<br />
The V2.x Publishing Work Group is responsible for the publishing of HL7 Version 2.x<br />
*[[V2.X_Chapter_Editors|Version 2.x Chapter Editors]]<br />
<br />
<br />
*[[May 2017 WGM V2 Publishing agenda | V2 Publishing May 2017 agenda Madrid, Spain]]<br />
*[[Jan. 2017 WGM V2 Publishing agenda | V2 Publishing Jan. 2017 agenda San Antonio, TX]]<br />
*[[Sept. 2016 WGM V2 Publishing agenda | V2 Publishing Sept. 2016 agenda Baltimore, MD]]<br />
*[[May 2016 WGM V2 Publishing agenda | V2 Publishing May 2016 agenda Montreal, Quebec]]<br />
*[[Jan. 2016 WGM V2 Publishing agenda | V2 Publishing Jan. 2016 agenda Orlando, FL]]<br />
*[[Oct. 2015 WGM V2 Publishing agenda | V2 Publishing Oct. 2015 agenda Atlanta, GA]] <br />
*[[May 2015 WGM V2 Publishing agenda | V2 Publishing May 2015 agenda Paris, France]]<br />
*[[Jan. 2015 WGM V2 Publishing agenda | V2 Publishing Jan. 2015 agenda San Antonio, TX]]<br />
*[[Sept. 2014 WGM V2 publishing agenda|V2 Publishing Sept. 2014 Agenda Chicago, IL ]]<br />
<br />
<br />
* [[V2_Examples_Requirements |V2.x Examples Requirements]]<br />
<br />
* [[V2.9 Chapter Status]]<br />
<br />
<br />
*[http://gforge.hl7.org/gf/project/v2-ballot-pkg/ V2 Publishing Packages in SVN on G-Forge] (Select SVN and click 'Trunk')<br />
<br />
==V2.x Publishing Refactor project==<br />
*[[v2.x_refactor_requirements]]<br />
<br />
==V2.x Publishing "How To ..." Documents==<br />
HL7 V2.x:<br />
* HL7 V2.x Style Guide (Vxx)<br />
*[http://www.hl7.org/documentcenter/public/wg/publishing/V2.7%20Style%20Guide%20-%2044.doc latest]<br />
<br />
==HL7 V3 Publishing Sub Group==<br />
The V3 Publishing is responsible for publishing all HL7 non-V2.x Standards (V3 Messaging, CDA, etc.)<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_PublishingSWOT.doc V3 Publishing Strengths, Weaknesses, Opportunities & Threats (SWOT) Analysis - 9/2008]<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_Publishing_2008_Strategy_Plan.zip V3 Publishing 3-yr Strategic Plan - 9/2008]<br />
<br />
===Minutes, Conference Calls and WGM===<br />
*[[Recent Publishing ConCall Minutes|Minutes of Recent V3 Pub Calls]]<br />
*[[V3_Publishing_WGM_Agenda_2016_09|Agenda for September 2016 WGM in Baltimore]]<br />
*[[V3 Publishing WGM Agenda 2016 05|Agenda for May 2016 WGM in Montreal ]]'''<br />
*[[V3 Publishing WGM Agenda 2015 10|Agenda for October 2015 WGM in Atlanta ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 09|Agenda for September 2014 WGM in Chicago ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 05|Agenda for May 2014 WGM in Phoenix ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 09|Agenda for September 2013 WGM in Cambridge ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 05|Agenda for May 2013 WGM in Atlanta ]]'''<br />
<br />
===Issues and Current Work===<br />
*[[:category:V3 Publishing Issues|V3 Publishing Issues Category]]<br />
**[[:category:Referred Publishing Items|Reconciliation Issues "Referred" to V3 Publishing]]<br />
**[[Publishing Facilitators Guide Updates]]<br />
*[[Normative_Edition_2018_Review_List_by_WG|Normative Edition 2018 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2017_Review_List_by_WG|Normative Edition 2017 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2016_Review_List_by_WG|Normative Edition 2016 Content Review List Sorted By WG]]<br />
*[[V3 Publishing ANT Refactor]]<br />
*[[V3 Generator Acceptance Testing]]<br />
*[[V3 Publishing FAQ|V3 Publishing Frequently Asked Questions]]<br />
*[[V3_Patch_Policy|V3 Patching Policy for the V3 Ballot Web Site]]<br />
*[http://www.hl7.org/special/committees/publishing/schedules.cfm Annual Publishing Calendar from HL7 web site]<br />
<br />
===V3 Publishing "How To ..." Documents===<br />
HL7 V3:<br />
*[[V3 Publishing Process Overview]]<br />
*[[Publishing and Linking Thumbnail Graphics| How to Edit, Hyperlink and Publish Thumbnail Graphics with Desktop Publishing]]<br />
*[[CMET Documentation Guidelines| How to create documentation for CMETs]]<br />
*[[V3_Publishing_Process_Steps|V3 Publishing Process Steps Overview]]<br />
*[[V3_PubProcess_-_Prepare_Freehand_MIF|How to Edit Free-Hand MIF files]]<br />
*[[CMET Publication Task Workflow for Facilitators]]<br />
*[[Directory Structure in Subversion|Directory Structure for Version Control of V3 Publishing in Subversion]]<br />
*[[V3_PubProcess_Content_Submission|V3 Domain Content Preparation for Ballot Submission]]<br />
*[[Reconciliation_HowTo|How To Reconcile a Ballot, a General Overview]]<br />
*[[Withdraw_Negative|How to Withdraw Your Negative Vote on a Ballot]]<br />
*[[V3_Publishing_Section_and_Domain_Codes|Explanation of Section and Domain Codes in Ballot artifacts]]<br />
*[[:category:HowTo|All HowTos]]<br />
<br />
===V3 Publishing Older Items...===<br />
*[[:Category:V3 Publishing Tasks|'''VERY OLD''' V3 Publishing Task List as a "'''Category'''" of articles]]<br />
*[[Normative Edition 2011 Review List|Content Review List for Normative Edition 2011]]<br />
*[[Normative Edition 2010 Content List|Content Review List for Normative Edition 2010]]<br />
<br />
[[Category:Work_Group]]<br />
[[Category:Technical and Support Services Steering Division]]</div>Bpechhttps://wiki.hl7.org/w/index.php?title=Publishing_Committee&diff=148960Publishing Committee2017-11-11T10:19:42Z<p>Bpech: /* Upcoming Meetings */</p>
<hr />
<div>== Publishing Work Group Mission and Related Planning Documents==<br />
NOTE: As of September 2017, the distinction between v2 and v3 Publishing no longer holds. The Work Group is now the Publishing Work Group. We retain the v2 Sub Grouping for old documents as a matter of history.<br />
*[http://wiki.hl7.org/index.php?title=Image:PublishingMissionAndCharter.doc Mission and Charter Statement]<br />
<br />
==Pages managed by the Publishing Work Group==<br />
*[[Normative Edition]], [[Development Edition]]<br />
<br />
==Upcoming Meetings==<br />
<br />
Publishing meets every other Tuesday at 3 PM EST with adjustments for holidays.<br />
Check the HL7 Conference call schedule for upcoming meetings. <br />
<br />
Dial-in Number (United States): (515) 604-9581<br />
<br />
Access Code: 243646<br />
<br />
International Dial-in Numbers: https://www.freeconferencecall.com/wall/editors6#international<br />
<br />
Online Meeting Link: https://join.freeconferencecall.com/editors6<br />
<br />
Online Meeting ID: editors6<br />
<br />
<br />
<br />
FAQ’s, tips and other helpful information regarding FreeConferenceCall.com is available at www.HL7.org > Resources > Tools and Resources > FreeConferenceCall.com Tip Sheet.<br />
<br />
<br />
<br />
<br />
<br />
*[[Pub Agenda telecon|2017-08-28]]<br />
*[[Pub Agenda telecon|2017-07-31]]<br />
*[[Pub Agenda telecon|2017-06-26]]<br />
<br />
===Past Meeting Minutes===<br />
*[[Publishing_Call_Minutes_20170109|Publishing Call 2017-01-09]]<br />
*[[Publishing_Call_Minutes_20170213|Publishing Call 2017-02-13]]<br />
*[[Publishing_Call_Minutes_20170313|Publishing Call 2017-03-13]]<br />
*[[Publishing_Call_Minutes_20170327|Publishing Call 2017-03-27]]<br />
<br />
==WGM Agendas and Minutes==<br />
*[[Publishing WGM Agenda 201802|New Orleans LA, Jan-Feb 2018]]<br />
*[[Publishing WGM Agenda 201709|San Diego CA, September 2017]]<br />
*[[Publishing WGM Agenda 201705|Madrid Spain, May 2017]]<br />
*[[Publishing WGM Agenda 201701|San Antonio TX, Jan 2017]]<br />
<br />
==HL7 V2.x Publishing Sub Group==<br />
The V2.x Publishing Work Group is responsible for the publishing of HL7 Version 2.x<br />
*[[V2.X_Chapter_Editors|Version 2.x Chapter Editors]]<br />
<br />
<br />
*[[May 2017 WGM V2 Publishing agenda | V2 Publishing May 2017 agenda Madrid, Spain]]<br />
*[[Jan. 2017 WGM V2 Publishing agenda | V2 Publishing Jan. 2017 agenda San Antonio, TX]]<br />
*[[Sept. 2016 WGM V2 Publishing agenda | V2 Publishing Sept. 2016 agenda Baltimore, MD]]<br />
*[[May 2016 WGM V2 Publishing agenda | V2 Publishing May 2016 agenda Montreal, Quebec]]<br />
*[[Jan. 2016 WGM V2 Publishing agenda | V2 Publishing Jan. 2016 agenda Orlando, FL]]<br />
*[[Oct. 2015 WGM V2 Publishing agenda | V2 Publishing Oct. 2015 agenda Atlanta, GA]] <br />
*[[May 2015 WGM V2 Publishing agenda | V2 Publishing May 2015 agenda Paris, France]]<br />
*[[Jan. 2015 WGM V2 Publishing agenda | V2 Publishing Jan. 2015 agenda San Antonio, TX]]<br />
*[[Sept. 2014 WGM V2 publishing agenda|V2 Publishing Sept. 2014 Agenda Chicago, IL ]]<br />
<br />
<br />
* [[V2_Examples_Requirements |V2.x Examples Requirements]]<br />
<br />
* [[V2.9 Chapter Status]]<br />
<br />
<br />
*[http://gforge.hl7.org/gf/project/v2-ballot-pkg/ V2 Publishing Packages in SVN on G-Forge] (Select SVN and click 'Trunk')<br />
<br />
==V2.x Publishing Refactor project==<br />
*[[v2.x_refactor_requirements]]<br />
<br />
==V2.x Publishing "How To ..." Documents==<br />
HL7 V2.x:<br />
* HL7 V2.x Style Guide (Vxx)<br />
*[http://www.hl7.org/documentcenter/public/wg/publishing/V2.7%20Style%20Guide%20-%2044.doc latest]<br />
<br />
==HL7 V3 Publishing Sub Group==<br />
The V3 Publishing is responsible for publishing all HL7 non-V2.x Standards (V3 Messaging, CDA, etc.)<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_PublishingSWOT.doc V3 Publishing Strengths, Weaknesses, Opportunities & Threats (SWOT) Analysis - 9/2008]<br />
*[http://wiki.hl7.org/index.php?title=Image:V3_Publishing_2008_Strategy_Plan.zip V3 Publishing 3-yr Strategic Plan - 9/2008]<br />
<br />
===Minutes, Conference Calls and WGM===<br />
*[[Recent Publishing ConCall Minutes|Minutes of Recent V3 Pub Calls]]<br />
*[[V3_Publishing_WGM_Agenda_2016_09|Agenda for September 2016 WGM in Baltimore]]<br />
*[[V3 Publishing WGM Agenda 2016 05|Agenda for May 2016 WGM in Montreal ]]'''<br />
*[[V3 Publishing WGM Agenda 2015 10|Agenda for October 2015 WGM in Atlanta ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 09|Agenda for September 2014 WGM in Chicago ]]'''<br />
*[[V3 Publishing WGM Agenda 2014 05|Agenda for May 2014 WGM in Phoenix ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 09|Agenda for September 2013 WGM in Cambridge ]]'''<br />
*[[V3 Publishing WGM Agenda 2013 05|Agenda for May 2013 WGM in Atlanta ]]'''<br />
<br />
===Issues and Current Work===<br />
*[[:category:V3 Publishing Issues|V3 Publishing Issues Category]]<br />
**[[:category:Referred Publishing Items|Reconciliation Issues "Referred" to V3 Publishing]]<br />
**[[Publishing Facilitators Guide Updates]]<br />
*[[Normative_Edition_2018_Review_List_by_WG|Normative Edition 2018 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2017_Review_List_by_WG|Normative Edition 2017 Content Review List Sorted By WG]]<br />
*[[Normative_Edition_2016_Review_List_by_WG|Normative Edition 2016 Content Review List Sorted By WG]]<br />
*[[V3 Publishing ANT Refactor]]<br />
*[[V3 Generator Acceptance Testing]]<br />
*[[V3 Publishing FAQ|V3 Publishing Frequently Asked Questions]]<br />
*[[V3_Patch_Policy|V3 Patching Policy for the V3 Ballot Web Site]]<br />
*[http://www.hl7.org/special/committees/publishing/schedules.cfm Annual Publishing Calendar from HL7 web site]<br />
<br />
===V3 Publishing "How To ..." Documents===<br />
HL7 V3:<br />
*[[V3 Publishing Process Overview]]<br />
*[[Publishing and Linking Thumbnail Graphics| How to Edit, Hyperlink and Publish Thumbnail Graphics with Desktop Publishing]]<br />
*[[CMET Documentation Guidelines| How to create documentation for CMETs]]<br />
*[[V3_Publishing_Process_Steps|V3 Publishing Process Steps Overview]]<br />
*[[V3_PubProcess_-_Prepare_Freehand_MIF|How to Edit Free-Hand MIF files]]<br />
*[[CMET Publication Task Workflow for Facilitators]]<br />
*[[Directory Structure in Subversion|Directory Structure for Version Control of V3 Publishing in Subversion]]<br />
*[[V3_PubProcess_Content_Submission|V3 Domain Content Preparation for Ballot Submission]]<br />
*[[Reconciliation_HowTo|How To Reconcile a Ballot, a General Overview]]<br />
*[[Withdraw_Negative|How to Withdraw Your Negative Vote on a Ballot]]<br />
*[[V3_Publishing_Section_and_Domain_Codes|Explanation of Section and Domain Codes in Ballot artifacts]]<br />
*[[:category:HowTo|All HowTos]]<br />
<br />
===V3 Publishing Older Items...===<br />
*[[:Category:V3 Publishing Tasks|'''VERY OLD''' V3 Publishing Task List as a "'''Category'''" of articles]]<br />
*[[Normative Edition 2011 Review List|Content Review List for Normative Edition 2011]]<br />
*[[Normative Edition 2010 Content List|Content Review List for Normative Edition 2010]]<br />
<br />
[[Category:Work_Group]]<br />
[[Category:Technical and Support Services Steering Division]]</div>Bpech