Difference between revisions of "FHIR Connectathon 19"

From HL7Wiki
Jump to navigation Jump to search
 
(57 intermediate revisions by 11 users not shown)
Line 6: Line 6:
  
 
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916
 
The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916
 +
 +
== Helpful Links ==
 +
 +
[http://conman.fhir.org/connectathon.html?event=baltimore2018 Con Man App]
 +
 +
[https://vimeo.com/291828706 Connectathon Manager Orientation Video]
 +
 +
[https://docs.google.com/spreadsheets/d/1ZgcdZ-iNEMFaztuND5EHSxyQP8M4GUbmKmEN6XzQtNU/edit#gid=1088922430 Tracking Spreadsheet]
 +
 +
[https://docs.google.com/spreadsheets/d/1fKoRbsD750R6hKcptCoCX4eufnwkBKkbTDBHQbpgVQ4/edit#gid=1311094847 Break Out Room Schedule]
 +
 +
[https://docs.google.com/document/d/1_CtY8MH0rpeQH4r5tpItJilJLbEsgogKntEarUpIGw4/edit?usp=sharing Outcomes Reporting]
  
 
== Important notes==
 
== Important notes==
* Please be sure to fill out our [https://www.surveymonkey.de/r/JYBPL9F Post-connectathon feedback survey]!
+
* Please be sure to fill out our [https://www.surveymonkey.com/r/Z6CZSWR PRE CONNECTATHON SURVEY] so that we know how many people will be in what track!
  
 
* 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.  
 
* 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.  
  
 
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.
 
* Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.
 +
 +
* Schedule Break Out Rooms [https://docs.google.com/spreadsheets/d/1fKoRbsD750R6hKcptCoCX4eufnwkBKkbTDBHQbpgVQ4/edit#gid=1311094847 HERE]!
  
 
== Tracks ==
 
== Tracks ==
Line 18: Line 32:
 
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.
 
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.
  
 +
*[http://wiki.hl7.org/index.php?title=201809_Argonaut_Questionnaire Argonaut Questionaire]
 
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]
 
*[http://wiki.hl7.org/index.php?title=201809_Attachments Attachments]
 
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]
 
*[http://wiki.hl7.org/index.php?title=201809_Bulk_Data Bulk Data]
 
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]
 
*[http://wiki.hl7.org/index.php?title=201809_Care_Plan Care Planning and Management]
*[http://wiki.hl7.org/index.php?title=201809_Catalog Catalog]
+
*[http://wiki.hl7.org/index.php?title=201809_Catalog_Track Catalog]
 +
*[http://wiki.hl7.org/index.php?title=201809_CIMI_Logical_Model_To_FHIR_Resource_Profile_Translation_Track CIMI]
 
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Genomics Clinical Genomics]
 
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Genomics Clinical Genomics]
 
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]
 
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Notes_Track Clinical Notes]
Line 27: Line 43:
 
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]
 
*[http://wiki.hl7.org/index.php?title=201809_Clinical_Reasoning Clinical Reasoning]
 
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]
 
*[http://wiki.hl7.org/index.php?title=201809_CDS_Hooks CDS Hooks]
 +
*[http://wiki.hl7.org/index.php?title=201809_Consumer_Mediated_Data_Exchange_(CMDE) Consumer Mediated Data Exchange (CMDE)]
 +
*[http://wiki.hl7.org/index.php?title=201809_Coverage_Requirements_Discovery Coverage Requirements Discovery (CRD)]
 +
*[http://wiki.hl7.org/index.php?title=201809_Direct/Certificates_Track Direct/Certificates]
 +
*[http://wiki.hl7.org/index.php?title=201809_EBMonFHIR Evidence Based Medicine (EBM)]
 
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]
 
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Documents Documents]
 
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]
 
*[http://wiki.hl7.org/index.php?title=201809_FHIRcast FHIRcast]
 
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]
 
*[http://wiki.hl7.org/index.php?title=201809_Financial_Track Financial Track]
*[http://wiki.hl7.org/index.php?title=201809_GDPR GDPR-General Data Protection Regulation]
 
*[http://wiki.hl7.org/index.php?title=201809_IHE-on-FHIR IHE on FHIR with focus on MHD]
 
 
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]
 
*[http://wiki.hl7.org/index.php?title=201809_International_Patient_Summary International Patient Summary]
*[http://wiki.hl7.org/index.php?title=201809_MedicationPlan-Track Medication Plan]
+
*[http://wiki.hl7.org/index.php?title=201809_LIVD#LIVD LOINC to In Vitro Diagnostic (LIVD)]
 +
*[http://wiki.hl7.org/index.php?title=201809_Open_mHealth_to_FHIR Open mHealth to FHIR Track]
 
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]
 
*[http://wiki.hl7.org/index.php?title=201809_Patient_Track Patient Track]
 +
*[http://wiki.hl7.org/index.php?title=201809_Public_Health Public Health]
 
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]
 
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics Storage and Analytics]
 +
*[http://wiki.hl7.org/index.php?title=201809_Structured_Data_Capture Structured Data Capture]
 +
*[http://wiki.hl7.org/index.php?title=201809_FHIR_Subscriptions Subscriptions]
 
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]
 
*[http://wiki.hl7.org/index.php?title=201809_Terminology_Services_Track Terminology Services]
*[http://wiki.hl7.org/index.php?title=201809_Questionnaire_Track Questionnaire Track]
 
*[http://wiki.hl7.org/index.php?title=201809_Versioned_API Versioned API]
 
  
 
== Connectathon Organization ==
 
== Connectathon Organization ==
Line 70: Line 90:
 
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]
 
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]
  
 +
== Tracking application ==
 +
 +
The tracking tool  [http://conman.fhir.org/connectathon.html?event=baltimore2018 ConMan] (stands for Connectathon Manager) is used by some tracks to record testing outcomes. Check with the tracks for details.
 +
 +
It is helpful to register your name even if your track is not using the tool as it has contact details of the participants. (When you load the page, click the 'Register new person' to add your details).
 +
 +
'''Note that you must still enroll at the event, as described above'''
  
 
== Test servers ==
 
== Test servers ==
Line 80: Line 107:
 
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1
 
* AEGIS.net, Inc.: http://wildfhir.aegis.net/fhir3-0-1
 
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir
 
* Telstra Health(HealthConnex): http://sqlonfhir-stu3.azurewebsites.net/fhir
* Intelligent Medical Objects (IMO): https://fhirconnectathon.e-imo.com/  
+
* Intelligent Medical Objects (IMO): https://fhir-terminology-demo.e-imo.com/api/swagger
 +
** Please contact teamhotel@imo-online.com for username and password
 
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)
 
* Knapp Consulting Inc.: http://www.pknapp.com:8081/con13 (Financial Track)
* 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
+
* Apelon (Terminology Service): http://fhir.ext.apelon.com:7080/dts/fhir/ and Demo Page at http://fhir.ext.apelon.com:7080/DtsOnFhirDemo/logon/Logon.action
 
**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.
 
**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.
 
* HSPC: http://sandbox.hspconsortium.org
 
* HSPC: http://sandbox.hspconsortium.org
Line 89: Line 117:
 
* Tukan FHI Server http://fhir.tukan.online/
 
* Tukan FHI Server http://fhir.tukan.online/
 
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz
 
* Terminz (NZ Terminology Service): http://its.patientsfirst.org.nz/RestService.svc/Terminz
 +
* Cerner: https://fhir-open.stagingcerner.com/r4/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca/
  
 
== FHIR Tutorials ==
 
== FHIR Tutorials ==
*There are 13 FHIR tutorials scheduled through-out the week
+
*There are 12 FHIR tutorials scheduled through-out the week
 +
 
 
*(Tues. AM)  Introduction to HL7 FHIR
 
*(Tues. AM)  Introduction to HL7 FHIR
 
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions
 
*(Tues. AM) Designing and Architecting HL7 FHIR Solutions
 
*(Tues. PM) Introduction to HL7 FHIR for Software Developers
 
*(Tues. PM) Introduction to HL7 FHIR for Software Developers
 
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers
 
*(Tues. PM) HL7 FHIR for Clinicians and Decision Makers
 +
*(Tues. PM) HL7 FHIR Profiling
 
*(Wed. AM)  HAPI on FHIR
 
*(Wed. AM)  HAPI on FHIR
 
*(Wed. AM)  Clinical Documents on HL7 FHIR
 
*(Wed. AM)  Clinical Documents on HL7 FHIR
 
*(Wed. PM)  Understanding and Using Terminology in HL7 FHIR
 
*(Wed. PM)  Understanding and Using Terminology in HL7 FHIR
*(Wed. PM) Designing and Architecting HL7 FHIR Solutions
+
*(Wed. PM) Clinical Genomics Using HL7 FHIR
 
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows
 
*(Thur. AM) HL7 FHIR for Clinical and Administrative Workflows
*(Thur. PM) HL7 FHIR Using SMART & CDS Hooks
+
*(Thur. PM) Driving Health Information Exchange Using XDS with CDA and FHIR  
*(Thur. PM) HL7 FHIR Profiling
+
*(All day - Wed. & Thurs.) FHIR Experience
  
*()  Clinical Genomics Using HL7 FHIR
+
Detailed descriptions are available in the [http://www.hl7.org/documentcenter/public_temp_D59B0CF2-1C23-BA17-0C624A59491D23B5/brochures/wgm/HL7_WGM_20180731.pdf Event Brochure]
*()  FHIR Experience
+
 
 +
==The FHIR Experience – An Immersive Hands-On Training Program - September 2018 WGM==
 +
 
 +
This is a two-day, hands-on FHIR training program being offered at the September 2018 WGM on Wednesday October 3rd and Thursday October 4th.
 +
It is designed to
 +
*empower students with the knowledge, skills, and confidence to implement HL7 FHIR applications
 +
*make informed decisions about FHIR technology, and
 +
*prepare for the FHIR Proficiency Certification Exam. 
 +
Theoretical material is blended with hands-on activities so that students are able to apply what they learn throughout the two-day experience.
 +
 
 +
The first day is devoted to evaluating and applying the base FHIR standards through hands-on interaction with FHIR servers.  Base standards topics include: FHIR Resources, RESTFUL API , transactions, operations, messages, documents, services, batch, bulk transfer, storage, Conformance and Terminology.
 +
 
 +
The second day focuses on reviewing and utilizing the FHIR implementation guides. Students will gain insight and hands-on experience with the US Core (Argonaut) and Provider Directory Implementation Guides.
 +
   
 +
The program culminates with a summative review of the two-day training through interactive preparation for the FHIR Proficiency Exam.
 +
 
 +
The Tutorial will Benefit:
 +
*Anyone interested in connecting his or her system/app to FHIR- or Argonaut- enabled EHRs or systems or who is implementing FHIR technology.
 +
 
 +
Upon Completion of This Tutorial, Students Will Be Able To:
 +
*Explain FHIR fundamental concepts
 +
*Implement API calls using Postman and FHIR server sandboxes.
 +
*Describe FHIR Implementation Guides and Profiles
 +
*Construct simple JavaScript applets that securely query clinical data using FHIR implementation guides.
 +
*Recall the required competencies and structure of the FHIR Proficiency certification exam
 +
*Identify gaps in FHIR proficiency by completing practice exam questions
 +
 
 +
Prerequisites
 +
*Participants in this program should either first take the Introduction to FHIR course or, at a minimum, review HL7 FHIR summaries in the FHIR specifications.
 +
*Participants are expected to be comfortable with technology and computer use. Prior knowledge of JavaScript and HTML will be useful.
  
Detailed descriptions are available in the [http://www.hl7.org/events/working_group_meeting/2018/09/ Event Brochure]
 
  
 
== FHIR Proficiency Exam ==
 
== FHIR Proficiency Exam ==
Line 113: Line 172:
 
*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.
 
*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.
  
*There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review
+
*Tutorials on the FHIR Proficiency Exam can be found in HL7's Education on Demand site: https://www.pathlms.com/hl7.
  
*The exam will be held on Thursday in the afternoon.
+
*The exam can be taken either online or at one of 900 HOST centers of HL7's testing service Kryterion. More details can be found at http://www.hl7.org/implement/certification.cfm?ref=nav.
  
 
== Work Group Meetings ==
 
== Work Group Meetings ==
 
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.
 
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.
  
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.   
+
You can take a look at the [http://www.hl7.org/documentcenter/public_temp_D5C8D384-1C23-BA17-0CDCE1FF782E5ED1/brochures/wgm/HL7_WGM_20180731.pdf Event Brochure] to get a sense of the breadth of discussions that will be taking place.   
  
 
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.
 
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.
Line 126: Line 185:
 
== Outcomes (for coordinators) ==
 
== Outcomes (for coordinators) ==
 
   
 
   
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].
+
 
 +
[https://docs.google.com/document/d/1_CtY8MH0rpeQH4r5tpItJilJLbEsgogKntEarUpIGw4/edit?usp=sharing Outcomes Reporting]
  
 
Guidelines for report out:
 
Guidelines for report out:
Line 136: Line 196:
 
*1 paragraph: discovered issues / questions (if there are any)
 
*1 paragraph: discovered issues / questions (if there are any)
 
*1 paragraph: now what?
 
*1 paragraph: now what?
 
=== Attachments===
 
 
*1 paragraph summary: what was the track trying to achieve
 
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.
 
*1 list of participants
 
Anthem Inc., HCSC
 
*1 paragraph: notable achievements
 
         
 
-        Built new patients and payer and provider information to build attachment requests
 
-        Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing.
 
-        Then acted as Provider and to build Communication to send the requested attachment.
 
-        Sent attachment once as jpeg link to Xray and then again as encoded with base 64.
 
-        Also acted as provider sending and unsolicited attachment to payor
 
 
Worked with Financial Management – Paul Knapp
 
- Built a claim from Provider
 
- Sent a Pre-Authorization request to Provider
 
 
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements
 
 
*1 paragraph: discovered issues / questions (if there are any)
 
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.
 
 
*1 paragraph: now what?
 
 
===Bulk Data===
 
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.
 
 
Participants: Google, Epic, Cerner, Boston Children's Hospital
 
 
Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.
 
 
Discovered issues:
 
Throttling while polling
 
we should have consistent error codes (e.g. 429 status code for "too many requests")
 
We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds
 
Should servers prevent client new exports while a previous request is running?
 
We need to test the API For deleting a pending request (i.e. DELETE [polling content location])
 
We need to test the API with security (backend services) in place.
 
Is it okay for a server to return multiple logically distinct resources with the same ID?
 
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)
 
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?
 
 
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.
 
 
===Care Planning and Management===
 
 
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.
 
 
Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration
 
       
 
Results:
 
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.
 
We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks.
 
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.
 
 
Discovered issues:
 
Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks.
 
 
Now What?
 
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.
 
Catalog
 
 
Summary:
 
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.
 
 
Participants:
 
Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)
 
   
 
Results:
 
The two clients were able to interact with the server.
 
Example:
 
 
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.
 
 
Discovered issues:
 
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.
 
 
Now what?
 
Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition.
 
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.
 
CDS Hooks
 
Goals
 
Gain implementer feedback on the balloted 1.0 specification.
 
Participants
 
EHRs
 
Cerner
 
Epic
 
CDS Services
 
Arpage AG / HL7 Switzerland
 
Clinical Cloud Solutions
 
HarmonIQ
 
HLN Consulting
 
IMO
 
Interopion
 
Lantana Consulting Group
 
McKesson
 
 
Notable Achievements
 
 
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.
 
 
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.
 
What’s Next?
 
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.
 
 
===Clinical Notes===
 
Summary
 
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.
 
Participants
 
Cerner, Epic, Argonaut
 
 
Results
 
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.
 
Discovered issues
 
Mime types and LOINC codes
 
Each FHIR server supports a different subset of the ValueSets at these elements
 
MIME type for DocumentReference.content.attachment.contentType.
 
LOINC code for DocumentReference.type.
 
Clients need to know what a server supports for create and read
 
Discovering this by trial and error is time consuming and unlikely to be comprehensive.
 
Communicating this out of band would pose implementation burden.
 
We considered several options for a server to communicate what they support on read and write:
 
CapabilityStatement.rest.resource.documentation - free text markdown
 
CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set
 
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.
 
Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using    /ValueSet?element=DocumentReference.type.
 
We also discussed a vendors just posting to their website :)
 
All these options are hard for clients add burden and challenge for clients without
 
Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’
 
Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.
 
 
===Clinical Research===
 
 
What was the track trying to achieve
 
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.
 
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. 
 
 
1 list of participants (with logos if you have time and energy)
 
Geoff Low, Medidata
 
 
Bob Milius, CIBMTR
 
 
Discovered issues / questions (if there are any)
 
Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review:
 
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.
 
Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.
 
 
Now what?
 
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.
 
 
===Clinical Reasoning===
 
 
*1 paragraph summary: what was the track trying to achieve
 
We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track
 
*1 list of participants (with logos if you have time and energy)
 
Zynx Health
 
Motive Medical Intelligence
 
Apelon
 
Philips
 
Accenture
 
*1 paragraph: notable achievements
 
Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence
 
*1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements
 
*1 paragraph: discovered issues / questions (if there are any)
 
Found and fixed several issues with our implementation of CDS Hooks
 
Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint
 
*1 paragraph: now what?
 
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.
 
 
===Direct / Certificates===
 
 
Goals
 
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.
 
 
Participants
 
                               
 
Notable achievements
 
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.
 
 
Track participation introduced the following questions:
 
1.    How will FHIR endpoints advertise what authentication method(s) are accepted?
 
 
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?
 
 
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?
 
 
 
What’s Next
 
Formalize client registration profiles
 
 
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
 
 
===Documents===
 
Goals
 
Test/update mappings/transforms from CDA to FHIR
 
Generate a fully bundled document from a Composition resource using the Generate Document operation
 
Participants
 
Sarah Gaunt (Lantana Consulting Group)
 
Corey Spears (Infor)
 
Gay Dolin (IMO)
 
Amnon Shabo (Philips)
 
Ron Shapiro (Qvera)
 
Lisa Nelson (MaxMD)
 
 
Notable Achievements[edit]
 
Scenario/Goal
 
Participants
 
Asserter
 
Result
 
Issues/Challenges/Notes
 
Create and persist Document (bundle) from a Composition resource using $document operation
 
Client: Postman
 
Server: http://test.fhir.org/r4
 
Gay Dolin,
 
Sarah Gaunt.
 
Amnon Shabo
 
Pass
 
 
Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care)
 
Client: Cloverleaf Integration Engine
 
Server: HAPI
 
Corey Spears,
 
Gay Dolin
 
Pass
 
 
Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD)
 
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine
 
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4
 
Corey Spears,
 
Ron Shapiro,
 
Gay Dolin
 
Pass
 
Refined transformations based on testing:
 
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.
 
Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD.
 
Discovered and resolved an issue around transformation of allergy status.
 
Explored medication timing transforms
 
Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109)
 
Different servers return quite different validation results.
 
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.
 
Create clinically robust examples to test transformations
 
Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine
 
Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4
 
Corey Spears,
 
Ron Shapiro,
 
Gay Dolin,
 
Amnon Shabo
 
Pass
 
Identified the need for more clinically robust examples
 
Create and test imaging report document
 
Client: Postman
 
Server: http://test.fhir.org/r3
 
Amnon Shabo
 
Pass
 
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.
 
Review prototype FHIR R4 Mapping Language files
 
n/a
 
Lisa Nelson,
 
Sarah Gaunt
 
n/a
 
Have noted issues with the mappings
 
More explanation is needed on how the mappings are used
 
Discovered issues
 
See notes in table
 
Next Steps
 
Continue update of CDA to FHIR transforms
 
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
 
Options:
 
Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource
 
Composition.relatesTo - maybe add DocumentReference as a choice
 
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
 
Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples
 
Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them
 
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
 
Negation - how to deal with negation in FHIR
 
 
===FHIRcast===
 
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.
 
 
Participants
 
Brett Esler - Oridashi
 
Isaac Vetter - Epic
 
Oliver Krauss - University of Applied Sciences Upper Austria
 
Martin Bellehumeur - Siemens Healthcare
 
Ashish Singh - Siemens Healthcare
 
Bas van den Heuvel - Philips
 
Richard Ettema - PenRad
 
 
 
Notable achievements
 
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.
 
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.
 
 
Also, see the video Brett made of FHIRcast in operation.
 
 
Discovered issues/questions
 
The track identified a number of outstanding issues, both with the sandbox and the specification itself.
 
Specification:
 
Issue #29: How can a subscribed app validate that it's subscription is active?
 
Issue #28: How can a subscribed app determine session context immediately upon subscribing?
 
Issue #27: Does the callback url need to be verified as belonging to the subscriber?
 
Issue #26: How are new events defined? Can we create a swagger definition for events?
 
Sandbox:
 
Issue #5: Notification context from sandbox doesn't conform to spec.
 
Issues #8: Url verification parameters from sand box doesn't conform to spec.
 
 
What's next?
 
The future is bright! Next steps include:
 
Resolving the above issues and reviewing and incorporating PRs #24 and #25.
 
Continuing to build the implementer community and respond to feedback.
 
Ballot specification into HL7.
 
 
===GDPR-General Data Protection Regulation===
 
 
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.
 
 
Participants:
 
Firely             
 
ByLight           
 
HL7 Austria   
 
CGM Clinical
 
VA/BZI
 
Infor
 
Accenture
 
 
Accomplishments
 
Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps
 
Most interesting gaps
 
Should there be a standardized operation for submitting an erasure request?
 
More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act.
 
More clear how to use AuditEvent to support a report of all uses of an identified patient’s data
 
 
IHE on FHIR with focus on MHD
 
 
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.
 
 
Participants
 
HL7 Switzerland
 
HL7 Argentina 
 
IHE Intnl     
 
IHE Services
 
Firely             
 
ByLight           
 
Ahdis                       
 
SAIHST   
 
 
Accomplishments:
 
The group primarily tested the FHIR conformance resources from MHD
 
6 bugs found and fixed
 
Developed StructureDefinitions for response messages for each transaction
 
Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition
 
Developed PDQm return response StructureDefinition
 
IHE validator tool will validate all MHD, PDQm, and PIXm transactions
 
 
===MedikationsplanPlus (German Medication Plan IG)===
 
 
===Summary===
 
Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples
 
===Participants===
 
* Molit Institut,
 
* HL7 Deutschland e.V.,
 
* Lang Health IT Consulting,
 
* Gefyra GmbH
 
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.
 
 
===Achievements===
 
Testserver is running with >300 example resources available (fhir.hl7.de)
 
===Discovered issues===
 
* Issues with the core spec:
 
** GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)
 
** GF#16586: Specify how $valide behaves with regard to resources with display values for  foreign language resources -> Currently differences between java/.NET validator
 
* Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)
 
 
* Issues with HAPI Server:
 
** core extensions missing, can’t be uploaded (solved!)
 
** 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.
 
** non-core constraints hardcoded into Java validator (resolved locally)
 
 
* Issues with HAPI FHIRPath engine:
 
** resolve() is not implemented
 
 
* Issues with .NET-Validator:
 
** errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)
 
 
* Issues with our profiles (all resolved)
 
** Errors in ValueSet Bindings
 
** Insufficient mustSupport-Flags
 
** Slicings that don’t work
 
** MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).
 
 
* Issues with our examples (all resolved)
 
** Missing mandatory elements
 
** Invalid units (wrong case)
 
** Invalid Dates (with Timezone)
 
** Empty values
 
** Invalid Extensions
 
 
* General issues with the “Medikationsplan plus” implementation guide:
 
** Clarification about context and usage of the profiles needs to be added in the implementation guide
 
** 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.
 
 
MedicationPlan  issue-tracker:
 
 
https://github.com/hl7germany/medikationsplanplusplus/issues
 
 
===Now what===
 
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.
 
 
===Storage and Analytics===
 
 
Objectives:
 
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.
 
 
Participants:
 
 
Notable achievements:
 
 
Hands-on guidelines with different implementation strategies created
 
Created a README for individual database technologies
 
Transferred queries between different query languages
 
Discussion about the used datasets: create it before the connectathon in different sizes
 
Discussion: Comparable queries are needed, based on CQL
 
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
 
 
Open questions:
 
 
Find common README format for individual database technologies
 
More meaningful queries are needed
 
Get more participation, more databases, more other technologies
 
Unify data with Bulk data track?
 
Use Vonk Loader for other databases?
 
How to combine _query with other search parameters? Is this needed? Based on FHIR Path?
 
 
 
Links:
 
Link to github account where detailed description and result of the track can be found.
 
 
===Terminology Services===
 
 
Questionnaire Track
 
Objectives
 
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.)
 
Track Participants
 
Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska
 
Additional discussion Participants
 
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
 
Achievements
 
Identified 3 approaches to pre-population
 
Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date)
 
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)
 
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
 
Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources)
 
Using definitions plus a profile containing fixed values
 
Using StructureMap
 
Using ActivityDefinition
 
Issues
 
StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings
 
Next steps
 
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
 
Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon
 
 
===Versioned API===
 
Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers.
 
Participants:
 
Kevin Olbrich
 
Christiaan Knaap
 
Toby Hu
 
Brian Postlethwaite
 
Achievements:
 
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
 
Clarifications about responsibilities of servers and clients
 
Servers:
 
Only one FHIR version in a response.  No mixed formats.  If you need resources with different formats, additional requests will need to be made.
 
Should conform to the REST API behavior specified by FHIR for the appropriate version
 
Should return the version in the ‘Content-Type’ of responses.
 
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.
 
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.
 
Maybe report the “available versions” in the CapabilityStatement.format element
 
Clients:
 
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.
 
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.
 
Discovered Issues:
 
We need a server that implements the proposed mechanism so we can test against it
 
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)
 
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)
 
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.
 
What’s next:
 
Get a reference server implementation so we can perform tests against it
 
  
 
== Other References ==
 
== Other References ==

Latest revision as of 16:01, 30 September 2018

Introduction

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 Sept. HL7 Working Group Meeting.


The contact for this event is Sandy Vance at sandra.vance@aegis.net or 614-273-5916

Helpful Links

Con Man App

Connectathon Manager Orientation Video

Tracking Spreadsheet

Break Out Room Schedule

Outcomes Reporting

Important notes

  • 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.
  • Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.
  • Schedule Break Out Rooms HERE!

Tracks

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.

Connectathon Organization

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.

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 (FHIR Test Servers ), but some participants may bring other servers along depending on the actors they are fulfilling. 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.

Each stream has a coordinator. The nominated coordinator's responsibilities:

  • In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other
  • During the connectathon act as a test mediator / progress tracker
  • track emergent issues that should be fed back to the committees

Connectathon Planning Team

Enrollment

If you or your company are interested in participating in the connectathon, please do the following.

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.

For any queries, either contact Sandy Vance at sandra.vance@aegis.net, a member of the planning team, or post your question in the FHIR list server

Tracking application

The tracking tool ConMan (stands for Connectathon Manager) is used by some tracks to record testing outcomes. Check with the tracks for details.

It is helpful to register your name even if your track is not using the tool as it has contact details of the participants. (When you load the page, click the 'Register new person' to add your details).

Note that you must still enroll at the event, as described above

Test servers

These are the STU3 servers we are aware of:

FHIR Tutorials

  • There are 12 FHIR tutorials scheduled through-out the week
  • (Tues. AM) Introduction to HL7 FHIR
  • (Tues. AM) Designing and Architecting HL7 FHIR Solutions
  • (Tues. PM) Introduction to HL7 FHIR for Software Developers
  • (Tues. PM) HL7 FHIR for Clinicians and Decision Makers
  • (Tues. PM) HL7 FHIR Profiling
  • (Wed. AM) HAPI on FHIR
  • (Wed. AM) Clinical Documents on HL7 FHIR
  • (Wed. PM) Understanding and Using Terminology in HL7 FHIR
  • (Wed. PM) Clinical Genomics Using HL7 FHIR
  • (Thur. AM) HL7 FHIR for Clinical and Administrative Workflows
  • (Thur. PM) Driving Health Information Exchange Using XDS with CDA and FHIR
  • (All day - Wed. & Thurs.) FHIR Experience

Detailed descriptions are available in the Event Brochure

The FHIR Experience – An Immersive Hands-On Training Program - September 2018 WGM

This is a two-day, hands-on FHIR training program being offered at the September 2018 WGM on Wednesday October 3rd and Thursday October 4th. It is designed to

  • empower students with the knowledge, skills, and confidence to implement HL7 FHIR applications
  • make informed decisions about FHIR technology, and
  • prepare for the FHIR Proficiency Certification Exam.

Theoretical material is blended with hands-on activities so that students are able to apply what they learn throughout the two-day experience.

The first day is devoted to evaluating and applying the base FHIR standards through hands-on interaction with FHIR servers. Base standards topics include: FHIR Resources, RESTFUL API , transactions, operations, messages, documents, services, batch, bulk transfer, storage, Conformance and Terminology.

The second day focuses on reviewing and utilizing the FHIR implementation guides. Students will gain insight and hands-on experience with the US Core (Argonaut) and Provider Directory Implementation Guides.

The program culminates with a summative review of the two-day training through interactive preparation for the FHIR Proficiency Exam.

The Tutorial will Benefit:

  • Anyone interested in connecting his or her system/app to FHIR- or Argonaut- enabled EHRs or systems or who is implementing FHIR technology.

Upon Completion of This Tutorial, Students Will Be Able To:

  • Explain FHIR fundamental concepts
  • Implement API calls using Postman and FHIR server sandboxes.
  • Describe FHIR Implementation Guides and Profiles
  • Construct simple JavaScript applets that securely query clinical data using FHIR implementation guides.
  • Recall the required competencies and structure of the FHIR Proficiency certification exam
  • Identify gaps in FHIR proficiency by completing practice exam questions

Prerequisites

  • Participants in this program should either first take the Introduction to FHIR course or, at a minimum, review HL7 FHIR summaries in the FHIR specifications.
  • Participants are expected to be comfortable with technology and computer use. Prior knowledge of JavaScript and HTML will be useful.


FHIR Proficiency Exam

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

Work Group Meetings

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.

You can take a look at the Event Brochure to get a sense of the breadth of discussions that will be taking place.

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.

Outcomes (for coordinators)

Outcomes Reporting

Guidelines for report out:

  • 1 paragraph summary: what was the track trying to achieve
  • 1 list of participants (with logos if you have time and energy)
  • 1 paragraph: notable achievements
  • 1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements
  • 1 paragraph: discovered issues / questions (if there are any)
  • 1 paragraph: now what?

Other References



Sept. 2018 Track Proposal Submissions are due July 11, 2018. Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.

FHIR_Connectathon_Track_Process.

Return to the FHIR Main Page