Difference between revisions of "Record Connectathon 17 Outcomes Here"
(184 intermediate revisions by 29 users not shown) | |||
Line 27: | Line 27: | ||
===Next Steps=== | ===Next Steps=== | ||
− | * | + | * Create a persistently available hosted version of the component stack. Initially this would simply be an endpoint developers of research applications could query. The next step would be to make available a UI providing the patient perspective of consenting in an EHR portal. |
==Attachments== | ==Attachments== | ||
===Goal=== | ===Goal=== | ||
− | * | + | *Electronic attachments are a high priority for processing claims and other payer/provider interactions. Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest in experimenting with FHIR-based messaging for exchanging attachments. This track will explore the feasibility of this approach. |
+ | |||
===Participants=== | ===Participants=== | ||
− | * | + | *Dynamic Health IT: Mike Vishak, Ozlem, Raychelle |
− | * | + | *UHIN (Utah Health Information Network): Andrew, Blain, Zak, Cody, Ben, Matt, Jared |
+ | *Health LX: Will, Steven, Yuriy, Dmytro, Taars | ||
+ | *BCBS Alabama: Chris Johnson | ||
+ | *BCBS Illinois: Durwin Day | ||
+ | |||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | * | + | *Dynamic Health IT Team (local New Orleans) adjusted the Track scenarios to their business purpose of providing clinical documents to Patients. They defined Patients and Organizations and used the Communication Request to retrieve a CCD to deliver to a patient. They developed and implemented a .NET FHIR server for Patient Clinical Data access. Basically FHIR on the Fly from a 2.1 CCDA document which satisfies ONC Certification measure g(7-9). Dynamic FHIR Server |
+ | *UHIN Team | ||
+ | **Valuable connection were made. | ||
+ | **Started implementing the attachment resources and identified necessary improvements required to finish implementing the specification. | ||
+ | **Learned about the enhancements to the Provider Directory resources so we can improve our current FHIR provider directory. | ||
+ | **Gained knowledge on several tools that others are using. | ||
+ | **Learned what we were supposed put into the sender and receiver when forwarding the Communication and Communication Response. | ||
+ | * HealthLX completed the Attachment, Financial Management and Medical Device Tracks. On the Medical Device track, we worked with the track leader to implement an actual use case for which we have a client requesting an implementation by April of this year. | ||
+ | |||
===Screenshots=== | ===Screenshots=== | ||
− | * | + | *None |
+ | |||
===Discovered issues=== | ===Discovered issues=== | ||
− | * | + | *No major issues mostly everything worked cleanly |
− | * | + | *Would be nice to leverage the track wiki content to start a FHIR Attachments IG. |
+ | *Track would have benefited from an orientation presentation since some participants did not fully understand what happens at a FHIR Connectathon | ||
+ | |||
===Next Steps=== | ===Next Steps=== | ||
− | * | + | *It was recommended to create an addition to the Track for Clearinghouse Functions for the next meeting. |
+ | *Start FHIR Attachments IG work (PSS already in place) | ||
+ | |||
==Automated Profiling From Domain Models== | ==Automated Profiling From Domain Models== | ||
===Goal=== | ===Goal=== | ||
− | * | + | * Inventory, test, compare and validate multiple FHIR profile generation methods |
+ | * Make hypotheses about what makes a “good” profile | ||
+ | * Compare modeling methods on completeness, accuracy, ease of use | ||
+ | * Learn how to make the profiling process better | ||
+ | |||
===Participants=== | ===Participants=== | ||
− | * | + | * Mark Kramer – MITRE (Track lead) |
− | * | + | * Steve Bratt - MITRE |
+ | * Kurt Allen –Applicadia | ||
+ | * May Terry – Flatiron | ||
+ | * Mike Byland – Interopion, representing HSPC | ||
+ | * Jane Pollack – National Marrow Donor Program | ||
+ | * Michel Rutten – Firely (formerly Furore) | ||
+ | * Galen Mulrooney – JP Systems (VA, FHIM) | ||
+ | * Travis Stenerson – Evinance | ||
+ | * Sean Muir – Model Driven Health Tools | ||
+ | * Steve Hufnagel – VA | ||
+ | |||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | * | + | * Five different methods of generating FHIR profiles in two categories (model-driven and direct profiling) were represented: |
+ | ** Model-driven: | ||
+ | ***'''1) Standard Health Record Approach (demonstrated)''' | ||
+ | ***2) CIMI Approach (discussed) | ||
+ | ***3) Model Driven Health Tools Approach (discussed) | ||
+ | **Direct Profiling: | ||
+ | ***'''4) "FireCaster" (Evinance) Approach (demonstrated)''' | ||
+ | ***5) Forge Approach (discussed) | ||
+ | * Documented ideas on what makes a "good" FHIR profile | ||
+ | **1) Should be tagged for discoverability | ||
+ | **2) Use context should be described | ||
+ | **3) Should be validatable and available at its canonical URL | ||
+ | **4) Understandable for developers and informaticists | ||
+ | **5) Extensions should carry a semantic identifier | ||
+ | **6) Attributes that indicate provenance/authority | ||
+ | **7) Doesn’t duplicate something that exists (needs decision support) | ||
+ | * Compared profiles from one model-driven and one direct profiling approach | ||
+ | * Determined the resulting profiles where largely commensurate | ||
+ | * Uploaded the generated profiles to Simplifier | ||
+ | |||
===Screenshots=== | ===Screenshots=== | ||
*1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements | *1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements | ||
===Discovered issues=== | ===Discovered issues=== | ||
*What challenged the group? | *What challenged the group? | ||
+ | Details of slicing were challenging | ||
+ | Deciding whether complex Observation should be components or panels | ||
*What questions did you come away with? | *What questions did you come away with? | ||
===Next Steps=== | ===Next Steps=== | ||
− | + | Work out bugs in current profiling tools | |
+ | Drive profiles from workflows rather than data inventories | ||
+ | |||
==Bulk Data== | ==Bulk Data== | ||
+ | '''[https://docs.google.com/document/d/1Ps9OJVixnGO8qgLhxkprpZrH4icmBJC7-VAXLoOYd1U/edit#heading=h.wqdb1ohk3g0e Bulk Data Gdoc] | ||
+ | ''' | ||
+ | |||
+ | ==Care Management and Planning (Care Plan)== | ||
===Goal=== | ===Goal=== | ||
− | + | Advance the maturity of FHIR resources for care management ([http://hl7.org/fhir/careplan.html CarePlan], [http://hl7.org/fhir/careteam.html CareTeam], [http://hl7.org/fhir/goal.html Goal], [http://hl7.org/fhir/condition.html Condition], and others), the definition of computable clinical protocols ([http://hl7.org/fhir/plandefinition.html PlanDefinition], [http://hl7.org/fhir/activitydefinition.html ActivityDefinition]), and to document industry best practices for improving care coordination using shared care plans. This work will inform the development of more comprehensive implementation guides and profiles for care management based on FHIR Release 3 (STU), which is the primary target for testing in this track. This connectathon track will be coordinated with the Chronic Conditions track at [http://wiki.hl7.org/index.php?title=Clinicians_on_FHIR_-_Jan_2018,_New_Orleans._LA Clinicians on FHIR] where they focus on ''clinical interoperability'' and harmonizing differences between the technical and clinical perspectives of FHIR resources. | |
===Participants=== | ===Participants=== | ||
− | * | + | * Academy of Nutrition and Dietetics |
− | * | + | * Allscripts |
+ | * Cerner | ||
+ | * Clinical Cloud Solutions | ||
+ | * Healthcare Services Platform Consortium (HSPC) | ||
+ | * InterSystems | ||
+ | * Lantana Consulting Group | ||
+ | * SAMHSA | ||
+ | * Veterans Health Administration (VHA) | ||
+ | |||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | * | + | * Successful collaboration with clinical use case based on the [https://www.niddk.nih.gov/health-information/communication-programs/nkdep/working-groups/health-information-technology/development-electronic-ckd-care-plan NIH Chronic Kidney Disease (CKD) Care Plan project]. Because frequent transitions of care are common among patients with CKD, an electronic CKD care plan could potentially improve patient outcomes by helping to ensure that critical patient data are consistently available to both the patient and his/her providers. |
+ | * Successful results associating PlanDefinitions with applicable ActivityDefinition for a Diabetes care protocol and creating a recommended CarePlan for a specific patient. | ||
===Screenshots=== | ===Screenshots=== | ||
− | + | [[Image:Care Plans using planDefinition.jpg|300px]] | |
+ | [[Image:CarePlan-clinFHIR-CKD.png|300px]] | ||
+ | |||
===Discovered issues=== | ===Discovered issues=== | ||
− | * | + | * Questions on use of clinFHIR to create and edit example FHIR resources for the CKD use case using a shared HSPC FHIR server. Successful and happy users after scheduling a breakout room review with David Hay. |
− | + | ||
===Next Steps=== | ===Next Steps=== | ||
− | * | + | * Illustrate benefits and use of distributing a library of care protocols using FHIR PlanDefinition, and applying those protocols to improve care management / care coordination by using: |
− | + | ** CDS to create or update patient care plans | |
− | + | ** Provider directories to improve care coordination | |
− | * | + | * Support use of evidence-based protocols for care planning with FHIR PlanDefinitions |
− | + | * Continue to expand comprehensive FHIR care planning example for Chronic Kidney Disease and other conditions | |
− | * | + | ** Document best practices and FHIR implementation guides for care management |
− | * | + | |
− | |||
− | * | ||
− | |||
− | |||
− | |||
− | * | ||
− | * | ||
− | |||
− | |||
==Catalog== | ==Catalog== | ||
===Goal=== | ===Goal=== | ||
Line 104: | Line 165: | ||
===Screenshots=== | ===Screenshots=== | ||
− | + | [[File:CatalogTab.jpg|600px]] | |
+ | |||
===Discovered issues=== | ===Discovered issues=== | ||
− | * [http://build.fhir.org/search.html#has Reverse chaining for search parameters] is currently under-specified in the standard. It is only described through a couple of examples. It would be nice to provide the full grammar to construct such kind of parameters. | + | * [http://build.fhir.org/search.html#has Reverse chaining for search parameters] is currently under-specified in the standard. It is only described through a couple of examples. It would be nice to provide the full grammar to construct such kind of parameters. [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=14957 #14957] |
− | *The naming convention for search parameters, using dash character as word separator (e.g.; code-value-date) is cumbersome and prevents from using current APIs (e.g. WebAPI from microsoft). Wouldn't it be better to use a camel case convention? | + | *The naming convention for search parameters, using dash character as word separator (e.g.; code-value-date) is cumbersome and prevents from using current APIs (e.g. WebAPI from microsoft). Wouldn't it be better to use a camel case convention? [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=14961 #14961] |
===Next Steps=== | ===Next Steps=== | ||
− | *Back to the Catalog task force (under OO WG) to complement the EntryDefinition resource (datatype changes, value sets, | + | *Back to the Catalog task force (under OO WG) to complement the EntryDefinition resource (datatype changes, value sets, search parameters) |
− | *Next connectathon will test the catalog management interactions (create, update, retire entries ...) | + | *Next connectathon will test the catalog management interactions (create, update, retire entries ...) and catalogs of knowledge artifacts |
==CDS Hooks== | ==CDS Hooks== | ||
===Goal=== | ===Goal=== | ||
− | + | ||
+ | Gather implementor feedback on the draft 1.0 CDS Hooks specification, including feedback on the CDS Hooks security model. Additionally, we want to connect as many CDS Service providers and EHR vendors as possible, to demonstrate interoperable CDS. | ||
+ | |||
===Participants=== | ===Participants=== | ||
− | * | + | |
− | * | + | We had 43 participants across a wide variety of EHR vendors, CDS Service Providers, and healthcare institutions. Below is a list of the companies who participated. This should not be considered a comprehensive list; however, effort was made to be as complete as possible. |
+ | |||
+ | '''EHRs''' | ||
+ | * Allscripts | ||
+ | * Cerner | ||
+ | * eClinicalWorks | ||
+ | * Epic | ||
+ | * T-System Inc | ||
+ | |||
+ | '''CDS Service Providers''' | ||
+ | * Alcidion | ||
+ | * Cigna | ||
+ | * Clinical Cloud Solutions | ||
+ | * EBSCO Health | ||
+ | * Elimu | ||
+ | * Elsevier | ||
+ | * First Databank (FDB) | ||
+ | * Flatiron Health | ||
+ | * HarmonIQ | ||
+ | * Health Samurai | ||
+ | * Healthwise | ||
+ | * IMO | ||
+ | * Interopion | ||
+ | * Lush Group, Inc | ||
+ | * McKesson Specialty Health | ||
+ | * Northrop Grumman | ||
+ | * Premier Inc | ||
+ | * River Rock | ||
+ | * Stanson Health | ||
+ | * University of Utah | ||
+ | * Wolters Kluwer | ||
+ | |||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | + | We had 7 EHR implementations of CDS Hooks, one more than the last Connectathon which is very notable. Additionally, we had a very large number of CDS Service providers implementing CDS Hooks for the first time; attracting additional individuals and companies into our community is very important to us. Additionally, we had two very successful breakout discussions in which we discussed several changes to the CDS Hooks specification and reached consensus on approaches. | |
+ | |||
+ | Several participants successfully implemented a diverse set of use cases using CDS Hooks, demonstrating their service integrated with a variety of EHRs. | ||
+ | |||
===Screenshots=== | ===Screenshots=== | ||
− | + | [[File:Cds-hooks-infobutton.jpg|200px|thumb|left|Infobutton on CDS Hooks]] | |
+ | |||
+ | [[File:Cds-hooks-med-prescribe.png|200px|thumb|left|medication-prescribe in Cerner]] | ||
+ | |||
+ | [[File:Cds-hooks-opioid.png|200px|thumb|left|Univ of Utah's Opioid CDS Service]] | ||
+ | |||
===Discovered issues=== | ===Discovered issues=== | ||
− | + | ||
− | + | We realized several important changes to the specification that we are incorporating for the 1.0 CDS Hooks specification release. Some of these changes are breaking (which is always painful), but as a community we agreed these changes are correct and important to make for our 1.0 release. | |
+ | |||
===Next Steps=== | ===Next Steps=== | ||
− | + | ||
+ | The CDS Hooks community is continuing to work on on getting the specification ready for a 1.0 release. We logged several Github issues during the Connectathon and are actively working on pull requests to address each of these issues. We plan to release 1.0 of the CDS Hooks specification in Q1 2018 based upon the feedback from the implementors at the Connectathon, as well as the broader CDS Hooks community. | ||
+ | |||
==Clinical Reasoning== | ==Clinical Reasoning== | ||
===Goal=== | ===Goal=== | ||
− | + | 1. Demonstrate distribution of quality improvement artifacts through exchange of PlanDefinition, ActivityDefinition, Library, and Measure resources. | |
+ | 2. Demonstrate population-level measure evaluation | ||
+ | 3. Coordinate with Bulk Data track to run a quality measure | ||
+ | 4. Coordinate with CDS Hooks track to integrate decision support in an EHR | ||
+ | |||
===Participants=== | ===Participants=== | ||
− | * | + | |
− | * | + | * Ben Hamlin, NCQA |
+ | * Anne Smith, NCQA | ||
+ | * Julie Scherer, Motive Medical Intelligence | ||
+ | * Seena Farzaneh, Motive Medical Intelligence | ||
+ | * Aruna Goli, Motive Medical Intelligence | ||
+ | * Lindee Chin, Edifecs | ||
+ | * Bas van den Heuvel, Phillips Healthcare | ||
+ | * Chris Schuler, HarmonIQ | ||
+ | * Bryn Rhodes, HarmonIQ | ||
+ | |||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | + | 1. Added population-level measure evaluation to the CQF Ruler. | |
+ | |||
+ | 2. Evaluated Alcohol Dependence HEDIS Measure (ASF). | ||
+ | |||
+ | 3. Evaluated BCS, CCS, and COL at the population level. | ||
+ | |||
+ | 4. Imported and evaluated PlanDefinition resources for Diabetes Care Management decision support from Motive Medical Intelligence (MMI) using CQF Ruler. | ||
+ | |||
+ | 5. Edifecs population health platform consumed MMI Diabetes Care Management decision support by calling MMI REXS CDS Hooks service. The CDS Hooks cards and qualifying criteria were presented in the Edifecs interface. | ||
+ | |||
===Screenshots=== | ===Screenshots=== | ||
− | + | Cancer Screening Summary Measure Report: | |
+ | [[File:MeasureReportSummary.png]] | ||
+ | |||
+ | Diabetes Care Recommendation in Population Health Platform: | ||
+ | [[File:MmiEdfDmCareRecommendations012818.JPG]] | ||
+ | |||
===Discovered issues=== | ===Discovered issues=== | ||
*What challenged the group? | *What challenged the group? | ||
Line 144: | Line 277: | ||
*1 paragraph: now what? | *1 paragraph: now what? | ||
==Clinical Research== | ==Clinical Research== | ||
+ | |||
===Goal=== | ===Goal=== | ||
− | + | The Clinical Research Track is focused on getting the key elements in place to make the reuse of EHR data in Clinical Research a reality. | |
+ | |||
===Participants=== | ===Participants=== | ||
− | + | Co-leads: Trisha Simpson (UCB), Geoff Low (Medidata) | |
− | + | Attendees: | |
+ | Sam Hume - CDISC | ||
+ | Steve Munini - Helios Software | ||
+ | Jean Sposaro, Rina Farah, Gloria McHugh - TCB | ||
+ | Robert Barr - PPD | ||
+ | Galvez, Jose - (NIH/CC/BTRIS) [E] | ||
+ | Donald Jennings, Angie Romano - Eli Lilly | ||
+ | Bhargava Reddy - UCB | ||
+ | Amy Nordo, Chet Corey - Duke | ||
+ | Jesper Kyer - Novo Nordisk | ||
+ | Michelle Cherry - Pfizer | ||
+ | Eric Hillaert - Edetek | ||
+ | Jon Huff - PRA | ||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | + | Successfully bulk uploaded and then downloaded set of Lab data with complete fields. | |
+ | Need to work on assumption about completeness of records for lab data for pragmatic data import. | ||
+ | Very fruitful discussions around about development of initiatives for making healthcare research a reality - pragmatic development plan | ||
+ | Deep dive of ODM API for data exchange | ||
+ | Key discussion on traceability for clinical trials and continued commitment to development towards solution. | ||
+ | Worked on changes to the Python fhir-parser, intending to make a Pull Request in near future. | ||
+ | Testing ResearchStudy and ResearchSubject (including against ClinicalTrials.gov schema) | ||
===Screenshots=== | ===Screenshots=== | ||
− | + | NA | |
===Discovered issues=== | ===Discovered issues=== | ||
− | + | Some assumptions around completeness of lab data should be addressed | |
− | + | Couple of refinements for the ResearchStudy to be discussed with BR&R group when compared with existing trial registries | |
===Next Steps=== | ===Next Steps=== | ||
− | + | Planning for next 6 months to get greater engagement with EHR vendors | |
+ | Meeting regularly to further requirements for process issues | ||
+ | Deepen engagement with Sites to understand how the eSource data capture process (through FHIR use and other innovative approaches) can improve site experience | ||
+ | |||
==Consumer Centered Data Exchange== | ==Consumer Centered Data Exchange== | ||
===Goal=== | ===Goal=== | ||
− | * | + | |
+ | The CCDE Track is focused on two scenarios from the consumer's perspective. | ||
+ | *Scenario 1: The consumer is interactively involved in the sharing of their health information via standards based OAuth | ||
+ | *Scenario 2: The consumer is able to convey their HIPAA Right of Access privacy preferences and persist them in a a discoverable way. | ||
+ | |||
+ | Both of theses scenarios rely on FHIR standards, specifically in relation to the Consent and related resources. | ||
+ | |||
+ | The goal of the track is to advance the use of these standards to verify their applicability and goodness of fit for these scenarios. | ||
+ | |||
+ | [[January 2018 New Orleans CCDE Connectathon Track 2|Additional HL7 Security WG Background]] | ||
+ | |||
===Participants=== | ===Participants=== | ||
− | * | + | |
− | * | + | Track Lead - Aaron Seib NATE\NewWave aaron.seib@nate-trust.org |
− | + | ||
− | * | + | *Lauren Kosowski - MiHIN |
− | + | *Courtney Delgoffe - MiHIN | |
− | * | + | *Virginia Lorenzi - NYP\Columbia U |
+ | *Aahlad Karumuru - NewWave | ||
+ | *Bo Dagnall - DXC | ||
+ | *David Hay - Orion | ||
+ | *Jenni Syed - Cerner | ||
+ | *Jin Yang - Cambria | ||
+ | *Kathleen Connor - HL7 Security WG, VA/BZI | ||
+ | *Mohammad Jafari - HL7 Security WG, VA/BZI | ||
+ | *Kyle Bradford - LA Public Health Inst | ||
+ | *Ali Kahn - ONC\ESAC | ||
+ | *Cooper Thompson - Epic | ||
+ | *Man M Garr - DXC | ||
+ | *Mark Scrimshire - CMS | ||
+ | *Michele Mottini - CareEvolution | ||
+ | *Mohan Kasi - Cambia | ||
+ | *Peter Kim - NewWave | ||
+ | *Peter Murphy - DXC | ||
+ | *Rama Manne - NewWave | ||
+ | *Randy Ullrich - Humetrix | ||
+ | *Sandeep Giri - UCSF | ||
+ | *Steve Mickelson - Humetrix | ||
+ | *Joyce Dunlop - DXC | ||
+ | |||
===Discovered issues=== | ===Discovered issues=== | ||
− | + | We discovered that the developer registration for BB API had an issue related to registering Mobile Apps. | |
+ | |||
+ | A fix is being developed and will be available soon. | ||
+ | |||
*What questions did you come away with? | *What questions did you come away with? | ||
− | === | + | |
− | + | There is a global question that persist between what is computable in comparison to what is currently documented in paper based HIPAA disclosure forms that requires additional examination and collaborative evaluation on the best way to address the gaps that may be outside the domain of the FHIR specifications. | |
+ | |||
+ | ===Notable Achievements=== | ||
+ | [[File:Vimeo-still.JPG|200px|thumb|left|vimeo.com/253352106]] | ||
+ | The OAuth Scenario group have drafted an IG that constrains the Consent Resource for the narrowly defined use case where the consumer is interactively authorizing the sharing of their health information with the consumer controlled app of their choice. This will be made available for broader inputs shortly. | ||
+ | |||
+ | The asynchronous consent team demonstrated how a Consent Resource captured by one system could be shared and reused by another server in a privacy preserving way. The following video demonstrates the interoperable use of a Consent Resource to convey a consumer's privacy preferences across enterprises and systems featuring DXC, MiHIN, NewWave, Humetrix and other participants of the Track: | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | https://vimeo.com/253352106 | ||
+ | |||
==Direct Track== | ==Direct Track== | ||
===Goal=== | ===Goal=== | ||
Line 334: | Line 543: | ||
==Encounter== | ==Encounter== | ||
===Goal=== | ===Goal=== | ||
− | + | To get as much feedback as possible on property usage on the Encounter resource by scanning resource instances from as many servers as possible. | |
===Participants=== | ===Participants=== | ||
− | * | + | * Brian Postlethwaite (Telstra Health) |
− | * | + | * Cooper Thompson (Epic) |
===Notable Achievements=== | ===Notable Achievements=== | ||
− | + | The Resource property usage app was tested against Telstra Health (44/44), Health Intersections (44/44), Epic (19/44), Accenture (44/44) and CQF Demo servers (19/44) with some good results found. | |
− | = | + | [https://sqlonfhir-stu3.azurewebsites.net/fhir/TestReport/5a6ced74ffb546fca4845316100e617c/_history/1?_format=html Example Results] |
− | + | ||
+ | Also ran the tool against the CQF Demo PlanDefinition resource and works no issues (40/75). | ||
+ | The tool is available on github: https://github.com/brianpos/FhirResourceScanner | ||
+ | |||
===Discovered issues=== | ===Discovered issues=== | ||
− | * | + | * Many servers don't support open searching |
− | * | + | * Tooling needed to be able to run on local bundle files |
===Next Steps=== | ===Next Steps=== | ||
− | * | + | * Publish the tool for others usage |
+ | * Seek others to run the tool on their own infrastructure/servers to get more feedback | ||
+ | |||
==FHIR Documents== | ==FHIR Documents== | ||
===Goals=== | ===Goals=== | ||
* Test/update mappings/transforms from CDA to FHIR | * Test/update mappings/transforms from CDA to FHIR | ||
− | * To be able to import a CDA and transform it into | + | * To be able to import a CDA and transform it into its equivalent FHIR resources |
* Generate a fully bundled document from a Composition resource using the Generate Document operation | * Generate a fully bundled document from a Composition resource using the Generate Document operation | ||
* Figure out what to do with Notes (e.g. History and Physical note) | * Figure out what to do with Notes (e.g. History and Physical note) | ||
Line 364: | Line 578: | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
− | ! style="text-align: center; font-weight: bold;" | Scenario | + | ! style="text-align: center; font-weight: bold;" | Scenario/Goal |
! style="text-align: center; font-weight: bold;" | Participants | ! style="text-align: center; font-weight: bold;" | Participants | ||
! style="text-align: center; font-weight: bold;" | Asserter | ! style="text-align: center; font-weight: bold;" | Asserter | ||
Line 370: | Line 584: | ||
! style="text-align: center; font-weight: bold;" | Note | ! style="text-align: center; font-weight: bold;" | Note | ||
|- | |- | ||
− | | | + | | Create and persist Document (bundle) from a Composition resource using $document operation |
| Client: Postman | | Client: Postman | ||
Server: http://test.fhir.org/r3 | Server: http://test.fhir.org/r3 | ||
Line 377: | Line 591: | ||
| When using persist=true, server returned error about being unable to find Patient resource. When not using persist parameter, server returned all resources referenced by Composition (including the Patient resource). (Server subsequently went down so we were unable to test further) | | When using persist=true, server returned error about being unable to find Patient resource. When not using persist parameter, server returned all resources referenced by Composition (including the Patient resource). (Server subsequently went down so we were unable to test further) | ||
|- | |- | ||
− | | | + | | Create narrative document (C-CDA on FHIR from IHE Healthy Weight profile) |
− | | Client: | + | | Client: HAPI UI |
− | Server: | + | Server: HAPI |
− | | | + | | Corey Spears |
− | | Pass/ | + | | Pass |
− | | | + | | Updated CDA to FHIR XSLT transforms to support IHE Healthy Weight profile |
+ | |- | ||
+ | | Create document with section entries (C-CDA on FHIR from IHE Healthy Weight profile) | ||
+ | | Client: HAPI UI | ||
+ | Server: HAPI | ||
+ | | Corey Spears | ||
+ | | Pass | ||
+ | | Updated CDA to FHIR XSLT transforms to support IHE Healthy Weight profile | ||
+ | |- | ||
+ | | Extract resources from document (C-CDA on FHIR from IHE Healthy Weight profile) | ||
+ | | Client: HAPI UI | ||
+ | Server: HAPI | ||
+ | | Corey Spears | ||
+ | | Pass | ||
+ | | Updated CDA to FHIR XSLT transforms to support IHE Healthy Weight profile | ||
+ | |- | ||
+ | | Create document with section entries | ||
+ | | Client: Qvera | ||
+ | Server: Redox | ||
+ | | Michael Hutton / Benjamin Flessner | ||
+ | | Pass | ||
+ | | Redox server parsed the CDA into FHIR composition (inline resources) | ||
+ | |- | ||
+ | | Create document with section entries | ||
+ | | Client: Qvera | ||
+ | Server: Dynamic FHIR Server | ||
+ | | Michael Hutton / Raychelle Fernadez | ||
+ | | Pass | ||
+ | | Dynamic FHIR server parsed the CDA into FHIR composition + separate resources (e.g. Condition, Observation, etc.) | ||
+ | |- | ||
+ | | Display document | ||
+ | | Client: Qvera | ||
+ | Server: HAPI-3 | ||
+ | | Michael Hutton | ||
+ | | Pass | ||
+ | | Display the FHIR produced from Lantana translated CDA | ||
|} | |} | ||
Line 400: | Line 649: | ||
*Update CDA to FHIR transforms to use a free parser (not SAXON-PE) | *Update CDA to FHIR transforms to use a free parser (not SAXON-PE) | ||
*Continue update of CDA to FHIR trasnforms to support IHE Healthy Weight Summary | *Continue update of CDA to FHIR trasnforms to support IHE Healthy Weight Summary | ||
+ | *Consider adding the FHIR version of the International Patient Summary (IPS) as a future scenario for Cologne. | ||
==FHIR Subscriptions== | ==FHIR Subscriptions== | ||
Line 424: | Line 674: | ||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | * | + | * Sectra, Epic implemented a successful, single direction FHIRcast implementation for patient and imagingstudy synchronization. |
− | + | * Began using github to track issues in force. [Jeremy] | |
− | * | + | * Kicked off a project to create an internet-accessible reference implementation. |
+ | * Began creating list of targeted usecases for FHIRcast specification. | ||
+ | * AEGIS implemented subscriptions and some testscripts for subscription | ||
+ | |||
===Discovered issues=== | ===Discovered issues=== | ||
− | * | + | * We're recording issues here: https://github.com/fhircast/docs/issues |
− | + | * II did question if it's the correct working group to sponsor FHIRcast. | |
+ | |||
===Next Steps=== | ===Next Steps=== | ||
− | * | + | * Provide update to Imaging Integration group. |
+ | * Establish some recurring calls around https://github.com/fhircast/docs/issues/13 | ||
+ | * Elliot will submit PSS to SSD SD | ||
+ | * Reference implementation | ||
+ | * Testscripts for may wgm for fhicast | ||
==Financial== | ==Financial== | ||
===Goal=== | ===Goal=== | ||
− | + | To test the exchange of eligibility, claim, pre-authorization, supporting information (attachments) and requests for payment reconciliation, explanation of benefit and processing status between clients (both Postman and actual clients) and servers. | |
+ | |||
===Participants=== | ===Participants=== | ||
− | * | + | *Mark Scrimshire (CMS) |
− | * | + | *Benoit Schoeffler (Almerys) |
+ | *Paul Knapp (Knapp Consulting Inc.) | ||
+ | *Louis Bedor (Cognosante) | ||
+ | *Dmytro (Health LX) | ||
+ | |||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | + | Clients and servers successfully communicated. | |
+ | |||
===Screenshots=== | ===Screenshots=== | ||
− | + | [[Image:Con17_FM_PK.PNG]] | |
+ | [[Image:Con17_claim.JPG]] | ||
+ | |||
===Discovered issues=== | ===Discovered issues=== | ||
− | + | No discovered issues with the specification, some internet and VPN issues. | |
− | + | ||
===Next Steps=== | ===Next Steps=== | ||
− | + | May 2018 trial of R4 Resources. | |
+ | |||
==Genomics== | ==Genomics== | ||
===Goal=== | ===Goal=== | ||
− | + | Genomics consists of the Sequence resource and several profiles built on top of existing FHIR resources (DiagnosticReport-genetics profile, DiagnosticOrder-genetics profile, Observation-genetics profile). The Sequence resource is a core resource in FHIR Genomics. It is used to represent complex genetics data. We are focused on clinical genetics data reporting. | |
We will also look to compare current FHIR extension model with a component-based model. [http://build.fhir.org/ig/HL7/genomics2/index.html New genomics IG] | We will also look to compare current FHIR extension model with a component-based model. [http://build.fhir.org/ig/HL7/genomics2/index.html New genomics IG] | ||
===Participants=== | ===Participants=== | ||
− | * | + | * Lloyd McKenzie - Gevity - lmckenzie@gevityinc.com |
− | * | + | * Bob Milius - NMDP/CIBMTR - bmilius@nmdp.org |
+ | * Martin Maiers - NMDP/CIBMTR -mmaiers@nmdp.org | ||
+ | * Alex Mankovich - Philips - alex.mankovich@philips.com | ||
+ | * Xin Liu - BCH - xinliu215@gmail.com | ||
+ | * Fan Lin- XMU- fanatxmu@gmail.com | ||
+ | * Lei Liu - XMU - liulei6696@gmail.com | ||
+ | * Joel Schneider - CIBMTR / NMDP - jschneid@nmdp.org | ||
+ | |||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | + | HLA use case: | |
+ | Modify of the PhaseSet extension element, PhaseSet may need to be a single Observation in HLA use case, discuss more if we use component to store the PhaseSet Information | ||
+ | Created simple HLA SMART app (read-only) | ||
+ | |||
+ | Unification (Component-based model): | ||
+ | The latest version of IG discussed. | ||
+ | |||
+ | HLA Terminology: | ||
+ | Work towards hosting HLA terminology in a Terminology server. | ||
+ | |||
===Screenshots=== | ===Screenshots=== | ||
− | * | + | * Reviewed IG model: [[File:Genomics-UnifedIG-201801.pdf]] |
+ | |||
===Discovered issues=== | ===Discovered issues=== | ||
− | * | + | * Unification questions |
− | * | + | ** Sequence resource as a definitional resource |
+ | ** How do we say “what was looked at” (and nothing was found)? | ||
+ | ** Need for ComplexVariant versus Genotype/Haplotype? | ||
+ | ** Merge copy number change into described variant? | ||
+ | |||
===Next Steps=== | ===Next Steps=== | ||
− | * | + | * Continue to review the new IG |
+ | * Determine if we need to have more specific tracks | ||
==IHE-on-FHIR== | ==IHE-on-FHIR== | ||
Line 474: | Line 763: | ||
===Participants=== | ===Participants=== | ||
− | *Diego Kaminker (Almadoc) | + | * Steve Moore (IHE USA / Washington University): Track Lead |
+ | * Diego Kaminker / Fernando Campos (Almadoc) | ||
* Oliver Egger (The Hub Zürich Association) | * Oliver Egger (The Hub Zürich Association) | ||
− | |||
* Bertil Reppen | * Bertil Reppen | ||
− | |||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | * | + | * Connect NIST toolkit to Almadoc FHIR server (Document Recipient) |
+ | ** Modifications to NIST toolkit to support bearer tokens. A more elegant solution is needed. | ||
+ | ** Review of MHD metadata that should be taken up by committee. | ||
+ | |||
===Screenshots=== | ===Screenshots=== | ||
− | * | + | * This is a screen shot that shows what the XDS Toolkit looks like when it has run a part of a test. |
+ | |||
+ | [[File:xds-toolki.png|300px]] | ||
+ | |||
===Discovered issues=== | ===Discovered issues=== | ||
*What challenged the group? | *What challenged the group? | ||
+ | ** Could have used a general purpose proxy | ||
+ | ** Bearer token required by FHIR server not supplied by client app | ||
+ | ** Further requirements in metadata that were not supplied by client app | ||
*What questions did you come away with? | *What questions did you come away with? | ||
+ | |||
===Next Steps=== | ===Next Steps=== | ||
− | * | + | * Need better IHE tools to help fill in gaps |
+ | * Need test scripts that use the FHIR testing system | ||
==Medical Device and Implantables Tracking using UDI== | ==Medical Device and Implantables Tracking using UDI== | ||
===Goal=== | ===Goal=== | ||
− | * | + | *To use FHIR to record information about procedures performed at the point-of-care using medical devices (single-use, implantable, monitoring) and record the procedure (e.g. implant, monitoring), identity of the device(s) (e.g. UDI), references to patient, providers,etc. |
+ | This track was intended to validate the FHIR profiles developed to supproto the "Point-of-care Medical Device Tracking" (PMDT) integration profile developed by VA and AORN (Asssociation of PeriOperative Nurses) as an IHE Patient Care Coordination Technical Framework supplement. | ||
+ | |||
===Participants=== | ===Participants=== | ||
− | * | + | *Ioana Singureanu, VHA (Track Lead) |
− | * | + | *John Rhodes, Philips Medical Systems |
+ | *Stephen Hollifield, HealthLX | ||
+ | *Will Tesch, HealthLX | ||
+ | *Richard Esmond, PenRad | ||
+ | *Greg Gustafson, PenRad | ||
+ | |||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | * | + | *In addition to testing out the Device and Procedure resources we also tested Medication, MedicationAdministration, and Location to support the requirements of a new IoT device. The personal injection device is intended to record and transmit the identity of the operator, the geolocation (using Location), the type, route, and medication dose (using Medication and MedicationAdministration). |
+ | *We discovered these resources could be used with RFID tagged devices - using a needle application or could molded into a larger device to provider RFID for the larger implant. The metal alloys used in devices are carefully research to avoid impact on future diagnostic imaging (avoid shadows and echos).The UDI could be used to track devices to the unique id of tumor and share the id of the tumor over time, among various system. | ||
+ | |||
===Screenshots=== | ===Screenshots=== | ||
− | * | + | *Not applicable at this time; this specification is meant to enable automatic data capture of identities, procode time, and location. |
+ | *Some implants can identity location of a lump and provide RFID: | ||
+ | [[File:20180128 142218.jpg|250 px]] | ||
+ | |||
===Discovered issues=== | ===Discovered issues=== | ||
− | * | + | *We need to track the a tumor (using a unique id) across systems, over a period of time as treatment are applied to the site. Can we use BodySite to represent a tumor and "treat" the body site? |
− | * | + | * We decided to use "Medication.supportingInformation" to specific a Location reference for the place where the device was used to self-deliver medication (e.g. chemo, insulin). |
+ | |||
===Next Steps=== | ===Next Steps=== | ||
− | * | + | *We will add "MedicationAdministration", "Medication", and "Location" to the set resources and profiles we could use to document point-of-care procedures. |
==Patient Match== | ==Patient Match== | ||
===Goal=== | ===Goal=== | ||
− | * | + | * Exercise the updated Patient $match operation |
===Participants=== | ===Participants=== | ||
− | * | + | * Brian Postlethwaite (Telstra Health) |
− | * | + | * Cooper Thompson (Epic) |
===Notable Achievements=== | ===Notable Achievements=== | ||
− | * | + | * Successfully the operation using fiddler to the 1 and only current implementation |
− | |||
− | |||
===Discovered issues=== | ===Discovered issues=== | ||
− | * | + | * No new issues in the one implementation (which was facading existing functionality) |
− | |||
===Next Steps=== | ===Next Steps=== | ||
− | * | + | * Really do need further implementation experience on this operation |
+ | |||
==Patient Track== | ==Patient Track== | ||
===Goal=== | ===Goal=== | ||
− | * | + | * The Patient Track continues to provide an introduction to FHIR and give participants an opportunity to get some hands on experience using the Patient resource. The Patient Track also provides participants with the opportunity to test their servers and clients using the TestScript resources that have been created--this testing is accomplished using the AEGIS Touchstone testing platform. |
===Participants=== | ===Participants=== | ||
− | * | + | * James Cheung, Kaiser Permanente |
− | * | + | * Raphael Majeed, University Oldenburg |
+ | * Amina Shaikh, Philips Healthcar | ||
+ | * Brain Wright, Mayo Clinic | ||
+ | * Joshua Varner, Corepoint Health | ||
+ | * Tyler Tallman, Breeze EHR | ||
+ | * Victor Vaysman MD, MedSide Healthcare | ||
+ | * Swastika, BC/BS of Louisiana | ||
+ | * Ron Shapiro, Qvera | ||
+ | * Richard Ettema, AEGIS | ||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | * | + | * Continue to provide newcomer orientation and direction towards participation |
+ | * 25-30 attendees at the FHIR Overview and FHIR Testing breakout sessions on Saturday | ||
+ | * 9+ organizations successfully exchanged FHIR Patient resource | ||
+ | * 4+ organizations successfully executed FHIR TestScripts on AEGIS Touchstone | ||
===Screenshots=== | ===Screenshots=== | ||
− | + | [[File:201801_Patient_Track_screen1.png|480px]] | |
+ | |||
+ | [[File:201801_Patient_Track_screen2.png|480px]] | ||
===Discovered issues=== | ===Discovered issues=== | ||
− | * | + | * Enhance Create Patient Test Scripts for Server Assigned ID to validate that the resource ID returned is different than the resource ID provided by the client, if provided. |
− | |||
===Next Steps=== | ===Next Steps=== | ||
− | * | + | * Add ability to 'publish' results from Touchstone directly to the Connectathon Management Application. |
==Pharmacogenomics CDS== | ==Pharmacogenomics CDS== | ||
+ | * PGx CDS connectathon track proposal: http://wiki.hl7.org/index.php?title=201801_Pharmacogenomics_CDS | ||
+ | * PGx CDS Service storyboard: https://docs.google.com/document/d/1VqPrf6aaOB8RhSbAq2JYDxZYbDm-RT9DxA0u6-RxYo0/edit | ||
+ | |||
===Goal=== | ===Goal=== | ||
− | + | Upon order entry of a medication, check for drug-gene interactions and produce recommendations. | |
+ | |||
===Participants=== | ===Participants=== | ||
− | * | + | *Bob Dolin, Elimu Informatics (track lead) |
− | * | + | *Aziz Boxwala, Elimu Informatics |
+ | *Kevin Power, Cerner | ||
+ | *Dave O'Larte, Cerner | ||
+ | *Xin Liu, Boston Children's Hospital | ||
+ | *Fan Lin, Xiamen University | ||
+ | *Lei Liu, Xiamen University | ||
+ | *Bob Freimuth, Mayo Clinic | ||
+ | |||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | * | + | *'''PGx CDS Service''' |
+ | **PGx CDS Service interacts with EHR (via CDS Hooks), OMIC Data Store (via FHIR), and Terminology Server (via FHIR). | ||
+ | *'''OMIC Data Store''' | ||
+ | **Interacts with PGx CDS Service (via FHIR) | ||
+ | *'''EHR''' | ||
+ | **Order entry of a medication triggers a “medication-prescribe” CDS hook which invokes the PGx CDS Service and provides it with a FHIR MedicationOrder instance. | ||
+ | *'''Terminology Service''' | ||
+ | **Interacts with PGx CDS Service (via FHIR) to see if the ordered drug is in an “Actionable PGx Drug” value set. | ||
+ | |||
===Screenshots=== | ===Screenshots=== | ||
− | + | Overall worklow is shown in the following figure: | |
+ | |||
+ | [[File:Workflow.PNG]] | ||
+ | |||
===Discovered issues=== | ===Discovered issues=== | ||
− | * | + | *Challenging to deal with structural variations |
− | * | + | *Challenging to represent star alleles, haplotypes, and genotypes (and their correspondence to variants) |
+ | *Multiple ways to represent variations (e.g. observation-genetics, PGx example, HLA resource) | ||
+ | |||
===Next Steps=== | ===Next Steps=== | ||
− | * | + | *Add in additional drug-gene interactions (in addition to azathioprine/TPMT) |
+ | *Modify logic to leverage Ancestry where applicable to guide PGx recommendations | ||
+ | *Enhanced CDS functionality, such as: patient already on med (therefore suppress alert), provider has chosen to suppress a particular alert, etc. | ||
+ | *Deeper dive into interplay between star alleles and variants | ||
==Provider Directory== | ==Provider Directory== | ||
===Goal=== | ===Goal=== | ||
− | * | + | * Provide Guidance and get feedback on the current provider directory resources/IGs (Core/Argonaut/Validated Healthcare Directory) |
===Participants=== | ===Participants=== | ||
− | * | + | * Brian Postlethwaite (Telstra Health) |
− | * | + | * Tim Berezny (CareDove) |
+ | * Nikolay Ryzhikov (Health Samurai) | ||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | * | + | * Reviewed Canadian Referral IG and how it relates to Provider Directories, and compared it to an Australian directory IG that is also in progress at HL7 Au. |
− | + | * Performed some testing on the Care Dove implementation using Fiddler (found some minor API issues). | |
− | * | + | * Health Samurai provide NPES data as FHIR API (interested in collaborating to make public) |
===Discovered issues=== | ===Discovered issues=== | ||
− | * | + | * Identified some of the duplicated content among the directory resources, but was able to explain why this is the case, and how to handle these |
− | * | + | * Maybe some additional |
+ | * Since the introduction of the Endpoint resource, the HealthcareService's referral method should be re-validated | ||
===Next Steps=== | ===Next Steps=== | ||
− | * | + | * The Canadian and Australian IGs on eReferral and Directory support will co-ordinate activities |
==Scheduling== | ==Scheduling== | ||
===Goal=== | ===Goal=== | ||
− | * | + | * Pilot the Argonaut Scheduling Implementation Guide (https://argonautproject.github.io/scheduling/OperationDefinition-appointment-find.html) |
+ | ** Discovery of what works and what doesn’t | ||
+ | *Determination of Future steps | ||
+ | *Network with Fellow Schedulers | ||
+ | *Chat and Commune with the FHIR Community | ||
+ | |||
===Participants=== | ===Participants=== | ||
− | * | + | ==Expected participants== |
− | * | + | <!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track --> |
+ | |||
+ | |||
+ | Servers: | ||
+ | |||
+ | {| class="wikitable" | ||
+ | |Name | ||
+ | |Use Case 1 | ||
+ | |Use Case 2 | ||
+ | |Use Case 3 | ||
+ | |Use Case 4 | ||
+ | |Use Case 5 | ||
+ | |- | ||
+ | |Cooper Thompson: Epic | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |X | ||
+ | |X | ||
+ | |- | ||
+ | |Andrew Torres: Cerner | ||
+ | | | ||
+ | | | ||
+ | |X | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Brian Postlethwaite: Telstra Health (HealthConnex) | ||
+ | |X | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Eric Haas *Track Lead*: Health eData Inc (Flask Facade on Test server) | ||
+ | |X | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | |||
+ | Clients: | ||
+ | |||
+ | {| class="wikitable" | ||
+ | |Name | ||
+ | |Use Case 1 | ||
+ | |Use Case 2 | ||
+ | |Use Case 3 | ||
+ | |Use Case 4 | ||
+ | |Use Case 5 | ||
+ | |- | ||
+ | |Brandon LaRue , Eugene Yao: ZocDoc | ||
+ | | | ||
+ | | | ||
+ | |X | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Eric Haas *Track Lead*: Health eData Inc (Postman) | ||
+ | |X | ||
+ | |X | ||
+ | |X | ||
+ | |X | ||
+ | |X | ||
+ | |- | ||
+ | |} | ||
+ | |||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | * | + | * Review of Prefetching Appointments Scenario |
+ | * Resolution of Outstanding Issues | ||
+ | * Simple Demonstration Application reflecting most basic scenario | ||
+ | * Future Plans | ||
+ | ** Final edits and updates to IG | ||
+ | ** Publishing date at end of February | ||
+ | ** Implementations based on IG in late 2018 | ||
===Screenshots=== | ===Screenshots=== | ||
− | * | + | *[https://argonautproject.github.io/scheduling/index.html Argonaut Scheduling Implementation Guide] |
+ | *[http://testpy-env.us-west-2.elasticbeanstalk.com/ Testing application(beta)] | ||
===Discovered issues=== | ===Discovered issues=== | ||
− | * | + | * The prefetching scenario described in the IG lead to several breakout sessions to resolve the workflow and APIs needed for implementation. |
− | * | + | ** Identified solution for each issue and were able to document the changes to the IG make prefetching more implementable. |
===Next Steps=== | ===Next Steps=== | ||
− | * | + | * Future Plans |
+ | ** Final edits and updates to IG | ||
+ | ** Publishing date at end of February | ||
+ | ** Participation at DevDays USA in June ( Speaker TBD ) | ||
+ | ** Implementations based on IG in late 2018 | ||
==Terminology Services Track== | ==Terminology Services Track== | ||
===Goal=== | ===Goal=== | ||
− | * | + | *Formal Testing of Terminology Services |
+ | *Introduction to Terminology and Terminology Services | ||
+ | *Developing Terminology Servers and Clients | ||
+ | *Engaging/Involving Other Tracks with Terminology and Terminology Services | ||
===Participants=== | ===Participants=== | ||
− | * | + | *Ettema Richard AEGIS.net, Inc. |
− | * | + | *Ho John 3M Health Information Systems |
+ | *Schneider Joel NMDP / CIBMTR | ||
+ | *Kramer Ewout Furore | ||
+ | *Macumber Carol Apelon, Inc. | ||
+ | *Wang Yunwei IMO | ||
+ | *Calderero Michael Accenture | ||
+ | *Egelkraut Reinhard HL7 Austria | ||
+ | *Graham Carol Clinical Architecture | ||
+ | *Hausam Rob Hausam Consulting LLC | ||
+ | *Humpherys Kristen 3M HIS | ||
+ | *Jordan Peter HL7 New Zealand | ||
+ | *Kartchner Tosh 3M Health Information Systems | ||
+ | *McClendon Craig Accenture | ||
+ | *McClure Robert MD Partners, Inc. | ||
+ | *McIlvenna Sean Lantana Consulting Group | ||
+ | *Nachimuthu Senthil 3M Health Information Systems, Inc. | ||
+ | *Ross Ron Clinical Architecture | ||
+ | *Mike Lapshin Health Samurai | ||
+ | *Sagy Pundak Mintz Allscripts | ||
+ | *Patrick Werner Heilbronn University | ||
+ | *Bertil Reppen Apertura | ||
+ | |||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | * | + | *Track orientation breakout |
+ | *Formal testing of multiple terminology service operations on multiple terminology servers (results below may not be complete) | ||
+ | |||
+ | :There are 11 participants and 7 watchers. | ||
+ | :There are 4 unique Servers associated with scenarios in this track. These are: | ||
+ | |||
+ | :*IMO (Yunwei Wang) | ||
+ | :*Hausam Consulting Test Server (R4) (Robert Hausam) | ||
+ | :*Terminz (Peter Jordan) | ||
+ | :*Clinical Architecture 3.0.1 (Ron Ross) | ||
+ | :There are 3 unique Clients associated with scenarios in this track. These are: | ||
+ | |||
+ | :*Postman (Robert Hausam) | ||
+ | :*Trifolia DEV Environment (Sean P McIlvenna) | ||
+ | :*Touchstone Testing Platform (Richard Ettema) | ||
+ | :*Questionnaire Builder (Sean P McIlvenna) | ||
+ | |||
+ | :There were 46 test results reported. The test results broke down as follows: | ||
+ | |||
+ | :Result Count % | ||
+ | :pass 34 74% | ||
+ | :fail 2 4% | ||
+ | :partial 6 13% | ||
+ | :note 4 9% | ||
+ | |||
+ | *Code system supplement breakout | ||
+ | *Terminology versioning breakout | ||
+ | |||
===Screenshots=== | ===Screenshots=== | ||
− | + | ||
===Discovered issues=== | ===Discovered issues=== | ||
*What challenged the group? | *What challenged the group? | ||
+ | **Haven't yet achieved consensus on the capabilities of and rules around code system supplements - will continue to work on this. | ||
+ | **Have further work to do in determining how we need value set and code system versions to be represented and used in FHIR, and in achieving consistency across different terminology servers. Need this to be aligned at least generally in the conformance resources (e.g. CodeSystem, ValueSet, StructureDefinition). | ||
+ | :::https://docs.google.com/spreadsheets/d/1LMZiy_WDxRJ0Ys9NAuGsoDEBdsIv4q-sDTezmWRnK_w/edit?usp=sharing | ||
+ | *GForge trackers created | ||
+ | **[https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=14645&start=0 14645] Code System Supplement discussion resolution | ||
+ | **[https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=14670&start=0 14670] Suggest splitting up $expand operation | ||
+ | **[https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=14672&start=0 14672] Valueset.date descriptions are inconsistent and unclear | ||
*What questions did you come away with? | *What questions did you come away with? | ||
+ | |||
===Next Steps=== | ===Next Steps=== | ||
− | * | + | *Further enhance formal terminology testing. |
+ | *Develop tests around value set and code system versions - that was planned for this time, but not progressed as far as we desired. | ||
+ | *Consider doing direct comparison of results of terminology service operations across various servers (could do this in a breakout session?). | ||
==Versioned API== | ==Versioned API== | ||
===Goal=== | ===Goal=== | ||
− | * | + | * Develop a strategy and some technical techniques so that server operators and clients can indicate which version of the FHIR standard they wish to use for communication. This will be helpful for maintaining compatibility with a variety of clients without requiring server operators to maintain as much infrastructure and will help avoid distributing canonical urls for resources that are tied to a specific version specific endpoint. |
===Participants=== | ===Participants=== | ||
− | * | + | * Grahame Grieve (Health Intersections) |
− | * | + | * Bradley Strecker (Cerner) |
+ | * Chris Gentz (Analysts) | ||
+ | * Cooper Thompson (Epic) | ||
+ | * Ewout Kramer (firely) | ||
+ | * Kevin Olbrich (McKesson Specialty Health) | ||
+ | * others... | ||
+ | |||
===Notable Achievements=== | ===Notable Achievements=== | ||
− | * | + | * MIME-type usage for versions |
− | === | + | ** Requests |
− | * | + | *** Client optionally specifies the version of the API request |
+ | *** 'Content-Type' header | ||
+ | **** Odd for GET (and other) request verbs, but not forbidden | ||
+ | **** named 'application/fhir+json; fhirVersion=3.0' using the major and minor versions of the semantic version. | ||
+ | **** patch version levels will be ignored by the server | ||
+ | **** no version or no header are interpreted as the default version for the server | ||
+ | *** 'Accept' header | ||
+ | **** provide a comma separated list of mime types in order of preference (i.e., 'Accept: application/fhir+json; fhir-version=3.0, application/fhir+json; fhir-version=1.0.2, application/fhir+json, application/json+fhir, application/json') | ||
+ | **** Don't use 'q' to indicate order | ||
+ | ** Server determines the version of the request and responds | ||
+ | *** Error conditions | ||
+ | **** if the resource in the request is not compatible with the version specified (i.e. it doesn't exist in that version) | ||
+ | **** if the server does not support the specified version | ||
+ | *** Response | ||
+ | **** Server uses the 'Accept' header to determine which version to use for the response | ||
+ | ***** Use mime types in order specified, first one satisfied by the server should be used | ||
+ | ***** Server should ignore versions it does not support | ||
+ | ***** Ignore patch version if specified (i.e., `fhirVersion=3.0.1` is the same as `fhirVersion=3.0`) | ||
+ | ***** If no version is specified, use the default server version. | ||
+ | **** Server should indicate the version used in the response by adding the `fhirVersion=3.0` parameter to the 'Content-Type' header of the response. | ||
+ | *** CapabilityStatement / Conformance | ||
+ | **** Server returns a CapabilityStatement or Conformance that is appropriate for the version of FHIR requested and the default version if it is not. | ||
+ | **** The capabilities may be different between versions. A server operator may choose to have older FHIR versions be read-only or not support searching or other operations. | ||
+ | *** Proposed `[base]/$versions` operation will return a list of FHIR versions supported by the server (optional, and obviously not supported on legacy servers). | ||
+ | * Versioned API urls | ||
+ | ** This approach remains useful when the header can't be specified or preserved | ||
+ | ** Not precluded by the MIME type approach | ||
+ | * All resources in a bundle/request must be the same version | ||
===Discovered issues=== | ===Discovered issues=== | ||
− | * | + | * Transforming Resources from one version to another is fraught with peril. It can work in some cases, but won't in many others. |
− | * | + | * ValueSets and other terminology will be quite problematic between versions. |
+ | * Resources written to storage may become decoupled from the version information. | ||
+ | * There are nuances about the mime type approach with regard to normative resources that remain to be fully explored. | ||
+ | * OAuth scopes need to be carefully considered | ||
+ | * _format parameter behavior has not been explored | ||
+ | |||
===Next Steps=== | ===Next Steps=== | ||
− | * | + | * Need some reference servers that implement this pattern for testing |
+ | * Identify test cases | ||
+ | * Try it | ||
+ | * formal proposal |
Latest revision as of 08:39, 8 February 2018
Contents
- 1 Apps for Imaging Research
- 2 Attachments
- 3 Automated Profiling From Domain Models
- 4 Bulk Data
- 5 Care Management and Planning (Care Plan)
- 6 Catalog
- 7 CDS Hooks
- 8 Clinical Reasoning
- 9 Clinical Research
- 10 Consumer Centered Data Exchange
- 11 Direct Track
- 12 Electronic Case Reporting
- 13 Encounter
- 14 FHIR Documents
- 15 FHIR Subscriptions
- 16 Financial
- 17 Genomics
- 18 IHE-on-FHIR
- 19 Medical Device and Implantables Tracking using UDI
- 20 Patient Match
- 21 Patient Track
- 22 Pharmacogenomics CDS
- 23 Provider Directory
- 24 Scheduling
- 25 Expected participants
- 26 Terminology Services Track
- 27 Versioned API
Apps for Imaging Research
Goal
Demonstrate the ability to make a consenting patient's imaging studies accessible for research applications using the SMART on FHIR-based Sync for Science transaction model.
Participants
- Chris Carr (RSNA), Steve Moore (Washington University), Wyatt Tellis (UCSF) - RSNA Image Share Project
- Brad Genereaux - Agfa Healthcare
Notable Achievements
The RSNA Image Share project team, in coordination with the Sync for Science team, developed a set of components to connect current state-of-practice radiology systems (HL7 v2 radiology information system / DICOM3 PACS). These components include the following:
- DICOMWeb Broker: A web service for adding DICOM-RS support to legacy PACS. The broker supports translating QIDO-RS and WADO-RS requests to the corresponding C-FIND and C-MOVE transactions to enable legacy PACS applications to participate in the S4S network.
- FHIR Broker: A web service that accepts FHIR RESTful calls on behalf of an EHR and brokers them to DICOMWeb calls to a PACS.
- Introspection Service: A web service that assists the FHIR Broker in authenticating research applications’ access to imaging data for a specific patient.
The components were packaged, along with a standalone PACS (DCM4CHEE) populated with a modest amount of test data in a Docker compose file available here: https://github.com/RSNA/s4s-stack. In our track we were able to load the Docker container on a new system and run it successfully.
Screenshots
Apps for Imaging Research track; FHIR Connectathon 17. Screenshot of sample results of imaging query.
Discovered issues
- Limited participation was the main challenge the track faced. Specifically, the absence of a research application to query for and retrieve imaging studies. The track could potentially also include DICOM3 and DICOM Web-enabled PACS and EHR systems that could use the FHIR broker or integrate its functionality. This initial implementation focused exclusively on finding and retrieving images. Future development should focus on enabling access to imaging reports.
- While the track as defined focused on image sharing for research purposes, the same set of transactions could enable access to images across sites for clinical care. We might consider broadening the scope if the track is repeated in future. We might also consider integrating this track into more generally scope tracks using SMART on FHIR to access medical records for clinical care and research.
Next Steps
- Create a persistently available hosted version of the component stack. Initially this would simply be an endpoint developers of research applications could query. The next step would be to make available a UI providing the patient perspective of consenting in an EHR portal.
Attachments
Goal
- Electronic attachments are a high priority for processing claims and other payer/provider interactions. Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest in experimenting with FHIR-based messaging for exchanging attachments. This track will explore the feasibility of this approach.
Participants
- Dynamic Health IT: Mike Vishak, Ozlem, Raychelle
- UHIN (Utah Health Information Network): Andrew, Blain, Zak, Cody, Ben, Matt, Jared
- Health LX: Will, Steven, Yuriy, Dmytro, Taars
- BCBS Alabama: Chris Johnson
- BCBS Illinois: Durwin Day
Notable Achievements
- Dynamic Health IT Team (local New Orleans) adjusted the Track scenarios to their business purpose of providing clinical documents to Patients. They defined Patients and Organizations and used the Communication Request to retrieve a CCD to deliver to a patient. They developed and implemented a .NET FHIR server for Patient Clinical Data access. Basically FHIR on the Fly from a 2.1 CCDA document which satisfies ONC Certification measure g(7-9). Dynamic FHIR Server
- UHIN Team
- Valuable connection were made.
- Started implementing the attachment resources and identified necessary improvements required to finish implementing the specification.
- Learned about the enhancements to the Provider Directory resources so we can improve our current FHIR provider directory.
- Gained knowledge on several tools that others are using.
- Learned what we were supposed put into the sender and receiver when forwarding the Communication and Communication Response.
- HealthLX completed the Attachment, Financial Management and Medical Device Tracks. On the Medical Device track, we worked with the track leader to implement an actual use case for which we have a client requesting an implementation by April of this year.
Screenshots
- None
Discovered issues
- No major issues mostly everything worked cleanly
- Would be nice to leverage the track wiki content to start a FHIR Attachments IG.
- Track would have benefited from an orientation presentation since some participants did not fully understand what happens at a FHIR Connectathon
Next Steps
- It was recommended to create an addition to the Track for Clearinghouse Functions for the next meeting.
- Start FHIR Attachments IG work (PSS already in place)
Automated Profiling From Domain Models
Goal
- Inventory, test, compare and validate multiple FHIR profile generation methods
- Make hypotheses about what makes a “good” profile
- Compare modeling methods on completeness, accuracy, ease of use
- Learn how to make the profiling process better
Participants
- Mark Kramer – MITRE (Track lead)
- Steve Bratt - MITRE
- Kurt Allen –Applicadia
- May Terry – Flatiron
- Mike Byland – Interopion, representing HSPC
- Jane Pollack – National Marrow Donor Program
- Michel Rutten – Firely (formerly Furore)
- Galen Mulrooney – JP Systems (VA, FHIM)
- Travis Stenerson – Evinance
- Sean Muir – Model Driven Health Tools
- Steve Hufnagel – VA
Notable Achievements
- Five different methods of generating FHIR profiles in two categories (model-driven and direct profiling) were represented:
- Model-driven:
- 1) Standard Health Record Approach (demonstrated)
- 2) CIMI Approach (discussed)
- 3) Model Driven Health Tools Approach (discussed)
- Direct Profiling:
- 4) "FireCaster" (Evinance) Approach (demonstrated)
- 5) Forge Approach (discussed)
- Model-driven:
- Documented ideas on what makes a "good" FHIR profile
- 1) Should be tagged for discoverability
- 2) Use context should be described
- 3) Should be validatable and available at its canonical URL
- 4) Understandable for developers and informaticists
- 5) Extensions should carry a semantic identifier
- 6) Attributes that indicate provenance/authority
- 7) Doesn’t duplicate something that exists (needs decision support)
- Compared profiles from one model-driven and one direct profiling approach
- Determined the resulting profiles where largely commensurate
- Uploaded the generated profiles to Simplifier
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
Details of slicing were challenging Deciding whether complex Observation should be components or panels
- What questions did you come away with?
Next Steps
Work out bugs in current profiling tools Drive profiles from workflows rather than data inventories
Bulk Data
Care Management and Planning (Care Plan)
Goal
Advance the maturity of FHIR resources for care management (CarePlan, CareTeam, Goal, Condition, and others), the definition of computable clinical protocols (PlanDefinition, ActivityDefinition), and to document industry best practices for improving care coordination using shared care plans. This work will inform the development of more comprehensive implementation guides and profiles for care management based on FHIR Release 3 (STU), which is the primary target for testing in this track. This connectathon track will be coordinated with the Chronic Conditions track at Clinicians on FHIR where they focus on clinical interoperability and harmonizing differences between the technical and clinical perspectives of FHIR resources.
Participants
- Academy of Nutrition and Dietetics
- Allscripts
- Cerner
- Clinical Cloud Solutions
- Healthcare Services Platform Consortium (HSPC)
- InterSystems
- Lantana Consulting Group
- SAMHSA
- Veterans Health Administration (VHA)
Notable Achievements
- Successful collaboration with clinical use case based on the NIH Chronic Kidney Disease (CKD) Care Plan project. Because frequent transitions of care are common among patients with CKD, an electronic CKD care plan could potentially improve patient outcomes by helping to ensure that critical patient data are consistently available to both the patient and his/her providers.
- Successful results associating PlanDefinitions with applicable ActivityDefinition for a Diabetes care protocol and creating a recommended CarePlan for a specific patient.
Screenshots
Discovered issues
- Questions on use of clinFHIR to create and edit example FHIR resources for the CKD use case using a shared HSPC FHIR server. Successful and happy users after scheduling a breakout room review with David Hay.
Next Steps
- Illustrate benefits and use of distributing a library of care protocols using FHIR PlanDefinition, and applying those protocols to improve care management / care coordination by using:
- CDS to create or update patient care plans
- Provider directories to improve care coordination
- Support use of evidence-based protocols for care planning with FHIR PlanDefinitions
- Continue to expand comprehensive FHIR care planning example for Chronic Kidney Disease and other conditions
- Document best practices and FHIR implementation guides for care management
Catalog
Goal
This track aims at testing and consolidating the set of new resources (EntryDefinition, ObservationDefinition, SpecimenDefinition) and profiles (catalog) that were added to the standard to enable the sharing of catalogs of health care products and services. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon uses a clinical laboratory compendium and focuses on the consultation of this catalog. The general scenario is "Query and retrieve the definitions of orderable tests and panels from a lab compendium, together with asked at order entry observations and specimens expected".The track is based on the R4 current ballot.
Participants
- Claude Nanjo - University of Utah Health Care
- François Macary - Phast
- Michel Blondel - Phast
Notable Achievements
Success on the planned scenario. The performed interactions were: 1) List available catalogs on the server; 2) List the entries of a catalog; 3) Search by name and/or by category an entry in an identified catalog 4) Obtain the full details of an entry of a catalog. A major outcome is a set of search parameters and refinements to the EntryDefinition resource.
Screenshots
Discovered issues
- Reverse chaining for search parameters is currently under-specified in the standard. It is only described through a couple of examples. It would be nice to provide the full grammar to construct such kind of parameters. #14957
- The naming convention for search parameters, using dash character as word separator (e.g.; code-value-date) is cumbersome and prevents from using current APIs (e.g. WebAPI from microsoft). Wouldn't it be better to use a camel case convention? #14961
Next Steps
- Back to the Catalog task force (under OO WG) to complement the EntryDefinition resource (datatype changes, value sets, search parameters)
- Next connectathon will test the catalog management interactions (create, update, retire entries ...) and catalogs of knowledge artifacts
CDS Hooks
Goal
Gather implementor feedback on the draft 1.0 CDS Hooks specification, including feedback on the CDS Hooks security model. Additionally, we want to connect as many CDS Service providers and EHR vendors as possible, to demonstrate interoperable CDS.
Participants
We had 43 participants across a wide variety of EHR vendors, CDS Service Providers, and healthcare institutions. Below is a list of the companies who participated. This should not be considered a comprehensive list; however, effort was made to be as complete as possible.
EHRs
- Allscripts
- Cerner
- eClinicalWorks
- Epic
- T-System Inc
CDS Service Providers
- Alcidion
- Cigna
- Clinical Cloud Solutions
- EBSCO Health
- Elimu
- Elsevier
- First Databank (FDB)
- Flatiron Health
- HarmonIQ
- Health Samurai
- Healthwise
- IMO
- Interopion
- Lush Group, Inc
- McKesson Specialty Health
- Northrop Grumman
- Premier Inc
- River Rock
- Stanson Health
- University of Utah
- Wolters Kluwer
Notable Achievements
We had 7 EHR implementations of CDS Hooks, one more than the last Connectathon which is very notable. Additionally, we had a very large number of CDS Service providers implementing CDS Hooks for the first time; attracting additional individuals and companies into our community is very important to us. Additionally, we had two very successful breakout discussions in which we discussed several changes to the CDS Hooks specification and reached consensus on approaches.
Several participants successfully implemented a diverse set of use cases using CDS Hooks, demonstrating their service integrated with a variety of EHRs.
Screenshots
Discovered issues
We realized several important changes to the specification that we are incorporating for the 1.0 CDS Hooks specification release. Some of these changes are breaking (which is always painful), but as a community we agreed these changes are correct and important to make for our 1.0 release.
Next Steps
The CDS Hooks community is continuing to work on on getting the specification ready for a 1.0 release. We logged several Github issues during the Connectathon and are actively working on pull requests to address each of these issues. We plan to release 1.0 of the CDS Hooks specification in Q1 2018 based upon the feedback from the implementors at the Connectathon, as well as the broader CDS Hooks community.
Clinical Reasoning
Goal
1. Demonstrate distribution of quality improvement artifacts through exchange of PlanDefinition, ActivityDefinition, Library, and Measure resources. 2. Demonstrate population-level measure evaluation 3. Coordinate with Bulk Data track to run a quality measure 4. Coordinate with CDS Hooks track to integrate decision support in an EHR
Participants
- Ben Hamlin, NCQA
- Anne Smith, NCQA
- Julie Scherer, Motive Medical Intelligence
- Seena Farzaneh, Motive Medical Intelligence
- Aruna Goli, Motive Medical Intelligence
- Lindee Chin, Edifecs
- Bas van den Heuvel, Phillips Healthcare
- Chris Schuler, HarmonIQ
- Bryn Rhodes, HarmonIQ
Notable Achievements
1. Added population-level measure evaluation to the CQF Ruler.
2. Evaluated Alcohol Dependence HEDIS Measure (ASF).
3. Evaluated BCS, CCS, and COL at the population level.
4. Imported and evaluated PlanDefinition resources for Diabetes Care Management decision support from Motive Medical Intelligence (MMI) using CQF Ruler.
5. Edifecs population health platform consumed MMI Diabetes Care Management decision support by calling MMI REXS CDS Hooks service. The CDS Hooks cards and qualifying criteria were presented in the Edifecs interface.
Screenshots
Cancer Screening Summary Measure Report:
Diabetes Care Recommendation in Population Health Platform:
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Clinical Research
Goal
The Clinical Research Track is focused on getting the key elements in place to make the reuse of EHR data in Clinical Research a reality.
Participants
Co-leads: Trisha Simpson (UCB), Geoff Low (Medidata) Attendees: Sam Hume - CDISC Steve Munini - Helios Software Jean Sposaro, Rina Farah, Gloria McHugh - TCB Robert Barr - PPD Galvez, Jose - (NIH/CC/BTRIS) [E] Donald Jennings, Angie Romano - Eli Lilly Bhargava Reddy - UCB Amy Nordo, Chet Corey - Duke Jesper Kyer - Novo Nordisk Michelle Cherry - Pfizer Eric Hillaert - Edetek Jon Huff - PRA
Notable Achievements
Successfully bulk uploaded and then downloaded set of Lab data with complete fields. Need to work on assumption about completeness of records for lab data for pragmatic data import. Very fruitful discussions around about development of initiatives for making healthcare research a reality - pragmatic development plan Deep dive of ODM API for data exchange Key discussion on traceability for clinical trials and continued commitment to development towards solution. Worked on changes to the Python fhir-parser, intending to make a Pull Request in near future. Testing ResearchStudy and ResearchSubject (including against ClinicalTrials.gov schema)
Screenshots
NA
Discovered issues
Some assumptions around completeness of lab data should be addressed Couple of refinements for the ResearchStudy to be discussed with BR&R group when compared with existing trial registries
Next Steps
Planning for next 6 months to get greater engagement with EHR vendors Meeting regularly to further requirements for process issues Deepen engagement with Sites to understand how the eSource data capture process (through FHIR use and other innovative approaches) can improve site experience
Consumer Centered Data Exchange
Goal
The CCDE Track is focused on two scenarios from the consumer's perspective.
- Scenario 1: The consumer is interactively involved in the sharing of their health information via standards based OAuth
- Scenario 2: The consumer is able to convey their HIPAA Right of Access privacy preferences and persist them in a a discoverable way.
Both of theses scenarios rely on FHIR standards, specifically in relation to the Consent and related resources.
The goal of the track is to advance the use of these standards to verify their applicability and goodness of fit for these scenarios.
Additional HL7 Security WG Background
Participants
Track Lead - Aaron Seib NATE\NewWave aaron.seib@nate-trust.org
- Lauren Kosowski - MiHIN
- Courtney Delgoffe - MiHIN
- Virginia Lorenzi - NYP\Columbia U
- Aahlad Karumuru - NewWave
- Bo Dagnall - DXC
- David Hay - Orion
- Jenni Syed - Cerner
- Jin Yang - Cambria
- Kathleen Connor - HL7 Security WG, VA/BZI
- Mohammad Jafari - HL7 Security WG, VA/BZI
- Kyle Bradford - LA Public Health Inst
- Ali Kahn - ONC\ESAC
- Cooper Thompson - Epic
- Man M Garr - DXC
- Mark Scrimshire - CMS
- Michele Mottini - CareEvolution
- Mohan Kasi - Cambia
- Peter Kim - NewWave
- Peter Murphy - DXC
- Rama Manne - NewWave
- Randy Ullrich - Humetrix
- Sandeep Giri - UCSF
- Steve Mickelson - Humetrix
- Joyce Dunlop - DXC
Discovered issues
We discovered that the developer registration for BB API had an issue related to registering Mobile Apps.
A fix is being developed and will be available soon.
- What questions did you come away with?
There is a global question that persist between what is computable in comparison to what is currently documented in paper based HIPAA disclosure forms that requires additional examination and collaborative evaluation on the best way to address the gaps that may be outside the domain of the FHIR specifications.
Notable Achievements
The OAuth Scenario group have drafted an IG that constrains the Consent Resource for the narrowly defined use case where the consumer is interactively authorizing the sharing of their health information with the consumer controlled app of their choice. This will be made available for broader inputs shortly.
The asynchronous consent team demonstrated how a Consent Resource captured by one system could be shared and reused by another server in a privacy preserving way. The following video demonstrates the interoperable use of a Consent Resource to convey a consumer's privacy preferences across enterprises and systems featuring DXC, MiHIN, NewWave, Humetrix and other participants of the Track:
Direct Track
Goal
- Evaluate two scenarios:
- Use of DirectTrust network to send / query FHIR resources. Identify any issues or enhancements needed for this capability.
- Utilizing DirectTrust certificates with the FHIR RESTful API to enable trust relationships to scale. Identify any issues or enhancements needed.
Participants
- Bruce Schreiber – MaxMD
- Calvin Beebe - Mayo Clinic
- David Kibbe - DirectTrust
- Don Jorgenson - Inpriva
- James Fisher — MedAllies
- Julie Maas – EMR Direct
- Lisa Nelson - Life Over Time Solutions
- Luis Maas – EMR Direct
- Thomas J Ramsey
Notable Achievements
Scenario | Participants | Asserter | Result | Note |
---|---|---|---|---|
Patient request for data | Client: MyPHD Wellness Manager (Direct Trust Source)
Server: MaxMDFhirResource (Target FHIR Server) |
Lisa Nelson | Pass | Important demonstration of individual access to health information - access to C-CDA or FHIR resources. |
Patient request for data | Client: EMR Direct HealthToGo (Direct Trust target)
Server: EMR Direct Stage Server (Source FHIR Server) |
Luis Maas | pass | success for use case #3, 4, and 5 |
Patient request for data | Client: Direct mdEmail 3.0 (Direct Trust target)
Server: MaxMDFhirResource (Target FHIR Server) |
Bruce Schreiber | pass | Patient Direct address - patient queried for his own record and retrieved them. |
Patient request for data | Client: Direct mdEmail 3.0 (Direct Trust Source)
Server: MaxMDFhirResource (Target FHIR Server) |
Bruce Schreiber | pass | C-CDA attachment was sent via DirectTrust and stored as both a C-CDA document and a series of resources mapped into FHIR resources. |
Patient request for data | Client: EMR Direct HealthToGo (Target EMR)
Server: Cerner DSTU 2 Secure - Patient Access (Source FHIR Server) |
Julie Maas | pass | |
Patient request for data | Client: EMR Direct FHIR over Direct Client (Target EMR)
Server: MaxMDFhirResource (Target FHIR Server |
Bruce Schreiber | pass | |
Patient request for data | Client: EMR Direct HealthToGo (Target EMR)
Server: Kaiser Permanente CTO EIS POC Server (Source FHIR Server) |
Julie Maas | pass | |
Provider request for data | Client: Direct mdEmail 3.0 (Direct Trust target)
Server: HAPI-3 (Source FHIR Server) |
Bruce Schreiber | pass | Provider uses a Direct Message to query for a Patient's health data. The result was returned using Direct. |
Provider request for data | Client: FHIR Over Direct Client (Direct Trust target)
Server: EMR Direct FHIR over Direct Server (Direct Trust Source) |
James Fisher | pass | Sent encapsulated message "GET /Patient/1234 HTTP/1.1". Received FHIR response in JSON format. |
Provider request for data | Client: EMR Direct FHIR over Direct Client (Direct Trust target)
Server: EMR Direct FHIR over Direct Server (Direct Trust Source) |
Julie Maas | pass | Workflow IG using Context IG |
Provider request for data | Client: Direct mdEmail 3.0 (Direct Trust Source)
Server: HAPI-3 (Source FHIR Server) |
Bruce Schreiber | pass | C-CDA attachment was sent via DirectTrust and stored as both a C-CDA document and a series of resources mapped into FHIR resources. |
Screenshots
Discovered issues
- What challenged the group?
- Explaining to Connectathon participants how use of DirectTrust certificates and trust framework can scale inter-organizational FHIR queries in an efficient and proven manner. We met this challenge on numerous occasions over the two days, and this was valuable.
- The new IG for Expressing Context in Direct Messaging needs some extensions to better handle workflows that are valuable in health information exchange via Direct.
- Lack of space around the table, slow wifi.
- What questions did you come away with?
- No clear signal from FHIR community on DirectTrust certificate-based solutions for scaling FHIR, as there are several alternatives.
- Who should we approach and how do we get broader participation for an Implementation Guide for use of DirectTrust certificates in authenticating and authorizing FHIR queries in inter-organizational use cases?
- How do we effectively coordinate with the FHIR community after this event? How do we bring our communities together. How do we work together effectively?
Next Steps
- 1 paragraph: now what?
Electronic Case Reporting
Goal
Electronic case reporting (eCR) has been maturing in the CDA product family, and some preliminary FHIR case reporting specifications have now been developed and are being balloted for comment. This track will explore various aspects of FHIR case reporting as they mature, beginning with trigger code representation and dissemination, initial Electronic Case Report (eICR) and Reportability Response (RR) instance generation, and eventually expanding to distributing decision support logic and other items for the support of reporting and management in future Connectathons. This track could include discussions on additional resource needs for these use cases and discussion of items in the current “For Comment” eCR ballot.
Participants
- John Loonsk, CGI Federal
- Srinath Remala, CDC
- Rishi Tarar, Northrup Grumman Corp.
- Sarah Gaunt, Lantana
- Rick Geimer, Lantana
Notable Achievements
- Successfully tested Subscription to Bundle resource containing triggering value sets across multiple servers and channels for both routine and emergency use cases.
- Successfully created reportability response and supporting resources.
- Partially created initial case report and supporting resources.
- Identified issues with eICR profiles that will need correcting.
Screenshots
Discovered issues
- eICR profiles need corrections (slicing issues, etc.)
- Submitted change requests for Subscription
Next Steps
- Triggering:
- Consider using Bundle tags to differentiate between emergency and routine update use cases.
- Consider profiles on Bundle and possibly ValueSet
- Consider using Subscription for more than value set distribution (i.e. distributing CQL, etc.)
- Working with FHIR server vendors to advance consistent implementation of Subscription.
- Shepard change requests for updates to Subscription to include the resource URL when no payload is specified vs. just an empty notification that "something" was modified.
- eICR and RR submission
- Update eICR profiles to fix validation issues
- Finish sample files for eICR and RR
- Misc
- Follow up with more EHR vendors on track results
- Discuss FHIR messaging and it's applicability for this use case
Encounter
Goal
To get as much feedback as possible on property usage on the Encounter resource by scanning resource instances from as many servers as possible.
Participants
- Brian Postlethwaite (Telstra Health)
- Cooper Thompson (Epic)
Notable Achievements
The Resource property usage app was tested against Telstra Health (44/44), Health Intersections (44/44), Epic (19/44), Accenture (44/44) and CQF Demo servers (19/44) with some good results found. Example Results
Also ran the tool against the CQF Demo PlanDefinition resource and works no issues (40/75). The tool is available on github: https://github.com/brianpos/FhirResourceScanner
Discovered issues
- Many servers don't support open searching
- Tooling needed to be able to run on local bundle files
Next Steps
- Publish the tool for others usage
- Seek others to run the tool on their own infrastructure/servers to get more feedback
FHIR Documents
Goals
- Test/update mappings/transforms from CDA to FHIR
- To be able to import a CDA and transform it into its equivalent FHIR resources
- Generate a fully bundled document from a Composition resource using the Generate Document operation
- Figure out what to do with Notes (e.g. History and Physical note)
Participants
- Sarah Gaunt (Lantana Consulting Group)
- Benjamin Flessner (Redox)
- Michael Hutton (Qvera)
- Corey Spears (Infor)
- Joel Francis (Canada Health Infoway)
Notable Achievements
Scenario/Goal | Participants | Asserter | Result | Note |
---|---|---|---|---|
Create and persist Document (bundle) from a Composition resource using $document operation | Client: Postman
Server: http://test.fhir.org/r3 |
Joel Francis / Sarah Gaunt | Fail | When using persist=true, server returned error about being unable to find Patient resource. When not using persist parameter, server returned all resources referenced by Composition (including the Patient resource). (Server subsequently went down so we were unable to test further) |
Create narrative document (C-CDA on FHIR from IHE Healthy Weight profile) | Client: HAPI UI
Server: HAPI |
Corey Spears | Pass | Updated CDA to FHIR XSLT transforms to support IHE Healthy Weight profile |
Create document with section entries (C-CDA on FHIR from IHE Healthy Weight profile) | Client: HAPI UI
Server: HAPI |
Corey Spears | Pass | Updated CDA to FHIR XSLT transforms to support IHE Healthy Weight profile |
Extract resources from document (C-CDA on FHIR from IHE Healthy Weight profile) | Client: HAPI UI
Server: HAPI |
Corey Spears | Pass | Updated CDA to FHIR XSLT transforms to support IHE Healthy Weight profile |
Create document with section entries | Client: Qvera
Server: Redox |
Michael Hutton / Benjamin Flessner | Pass | Redox server parsed the CDA into FHIR composition (inline resources) |
Create document with section entries | Client: Qvera
Server: Dynamic FHIR Server |
Michael Hutton / Raychelle Fernadez | Pass | Dynamic FHIR server parsed the CDA into FHIR composition + separate resources (e.g. Condition, Observation, etc.) |
Display document | Client: Qvera
Server: HAPI-3 |
Michael Hutton | Pass | Display the FHIR produced from Lantana translated CDA |
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- Server issues
- Slicing
- Tooling differences that prevented use of other tools (e.g. Qvera tool unable to make use of Lantana CDA to FHIR tooling)
- What questions did you come away with
Next Steps
- Take some time to update FHIR slicing documentation
- Continue testing $document operation
- Update CDA to FHIR transforms to a one file solution/non web server dependent
- Update CDA to FHIR transforms to use a free parser (not SAXON-PE)
- Continue update of CDA to FHIR trasnforms to support IHE Healthy Weight Summary
- Consider adding the FHIR version of the International Patient Summary (IPS) as a future scenario for Cologne.
FHIR Subscriptions
Goal
Mature FHIRcast, sustain and increase community involvement. Grow FHIR Subscriptions.
Participants
- Niklas Svensen - Sectra
- Leo Bergnehr - Sectra
- Jeremy Richardson - MModal
- Jim Schafer - PenRad
- Max Philips - Cerner
- Eitan Behar - Allscripts
- Segay Mintz - Allscripts
- Jenni Syed - Cerner
- Will Maethner - Epic
- Isaac Vetter - Epic
- Brad Genereaux - Agfa, II
Remote:
- Martin Bellehumeur - Siemens
- Hardik - Siemens
- Ashish - Siemens
Notable Achievements
- Sectra, Epic implemented a successful, single direction FHIRcast implementation for patient and imagingstudy synchronization.
- Began using github to track issues in force. [Jeremy]
- Kicked off a project to create an internet-accessible reference implementation.
- Began creating list of targeted usecases for FHIRcast specification.
- AEGIS implemented subscriptions and some testscripts for subscription
Discovered issues
- We're recording issues here: https://github.com/fhircast/docs/issues
- II did question if it's the correct working group to sponsor FHIRcast.
Next Steps
- Provide update to Imaging Integration group.
- Establish some recurring calls around https://github.com/fhircast/docs/issues/13
- Elliot will submit PSS to SSD SD
- Reference implementation
- Testscripts for may wgm for fhicast
Financial
Goal
To test the exchange of eligibility, claim, pre-authorization, supporting information (attachments) and requests for payment reconciliation, explanation of benefit and processing status between clients (both Postman and actual clients) and servers.
Participants
- Mark Scrimshire (CMS)
- Benoit Schoeffler (Almerys)
- Paul Knapp (Knapp Consulting Inc.)
- Louis Bedor (Cognosante)
- Dmytro (Health LX)
Notable Achievements
Clients and servers successfully communicated.
Screenshots
Discovered issues
No discovered issues with the specification, some internet and VPN issues.
Next Steps
May 2018 trial of R4 Resources.
Genomics
Goal
Genomics consists of the Sequence resource and several profiles built on top of existing FHIR resources (DiagnosticReport-genetics profile, DiagnosticOrder-genetics profile, Observation-genetics profile). The Sequence resource is a core resource in FHIR Genomics. It is used to represent complex genetics data. We are focused on clinical genetics data reporting.
We will also look to compare current FHIR extension model with a component-based model. New genomics IG
Participants
- Lloyd McKenzie - Gevity - lmckenzie@gevityinc.com
- Bob Milius - NMDP/CIBMTR - bmilius@nmdp.org
- Martin Maiers - NMDP/CIBMTR -mmaiers@nmdp.org
- Alex Mankovich - Philips - alex.mankovich@philips.com
- Xin Liu - BCH - xinliu215@gmail.com
- Fan Lin- XMU- fanatxmu@gmail.com
- Lei Liu - XMU - liulei6696@gmail.com
- Joel Schneider - CIBMTR / NMDP - jschneid@nmdp.org
Notable Achievements
HLA use case: Modify of the PhaseSet extension element, PhaseSet may need to be a single Observation in HLA use case, discuss more if we use component to store the PhaseSet Information Created simple HLA SMART app (read-only)
Unification (Component-based model): The latest version of IG discussed.
HLA Terminology: Work towards hosting HLA terminology in a Terminology server.
Screenshots
- Reviewed IG model: File:Genomics-UnifedIG-201801.pdf
Discovered issues
- Unification questions
- Sequence resource as a definitional resource
- How do we say “what was looked at” (and nothing was found)?
- Need for ComplexVariant versus Genotype/Haplotype?
- Merge copy number change into described variant?
Next Steps
- Continue to review the new IG
- Determine if we need to have more specific tracks
IHE-on-FHIR
Goal
- Send one document to a server using the IHE MHD transaction. This includes a DocumentManifest, a DocumentReference and a Binary document
- Retrieve the document from the server
- Exercise Alarm Communication and Management
Participants
- Steve Moore (IHE USA / Washington University): Track Lead
- Diego Kaminker / Fernando Campos (Almadoc)
- Oliver Egger (The Hub Zürich Association)
- Bertil Reppen
Notable Achievements
- Connect NIST toolkit to Almadoc FHIR server (Document Recipient)
- Modifications to NIST toolkit to support bearer tokens. A more elegant solution is needed.
- Review of MHD metadata that should be taken up by committee.
Screenshots
- This is a screen shot that shows what the XDS Toolkit looks like when it has run a part of a test.
Discovered issues
- What challenged the group?
- Could have used a general purpose proxy
- Bearer token required by FHIR server not supplied by client app
- Further requirements in metadata that were not supplied by client app
- What questions did you come away with?
Next Steps
- Need better IHE tools to help fill in gaps
- Need test scripts that use the FHIR testing system
Medical Device and Implantables Tracking using UDI
Goal
- To use FHIR to record information about procedures performed at the point-of-care using medical devices (single-use, implantable, monitoring) and record the procedure (e.g. implant, monitoring), identity of the device(s) (e.g. UDI), references to patient, providers,etc.
This track was intended to validate the FHIR profiles developed to supproto the "Point-of-care Medical Device Tracking" (PMDT) integration profile developed by VA and AORN (Asssociation of PeriOperative Nurses) as an IHE Patient Care Coordination Technical Framework supplement.
Participants
- Ioana Singureanu, VHA (Track Lead)
- John Rhodes, Philips Medical Systems
- Stephen Hollifield, HealthLX
- Will Tesch, HealthLX
- Richard Esmond, PenRad
- Greg Gustafson, PenRad
Notable Achievements
- In addition to testing out the Device and Procedure resources we also tested Medication, MedicationAdministration, and Location to support the requirements of a new IoT device. The personal injection device is intended to record and transmit the identity of the operator, the geolocation (using Location), the type, route, and medication dose (using Medication and MedicationAdministration).
- We discovered these resources could be used with RFID tagged devices - using a needle application or could molded into a larger device to provider RFID for the larger implant. The metal alloys used in devices are carefully research to avoid impact on future diagnostic imaging (avoid shadows and echos).The UDI could be used to track devices to the unique id of tumor and share the id of the tumor over time, among various system.
Screenshots
- Not applicable at this time; this specification is meant to enable automatic data capture of identities, procode time, and location.
- Some implants can identity location of a lump and provide RFID:
Discovered issues
- We need to track the a tumor (using a unique id) across systems, over a period of time as treatment are applied to the site. Can we use BodySite to represent a tumor and "treat" the body site?
- We decided to use "Medication.supportingInformation" to specific a Location reference for the place where the device was used to self-deliver medication (e.g. chemo, insulin).
Next Steps
- We will add "MedicationAdministration", "Medication", and "Location" to the set resources and profiles we could use to document point-of-care procedures.
Patient Match
Goal
- Exercise the updated Patient $match operation
Participants
- Brian Postlethwaite (Telstra Health)
- Cooper Thompson (Epic)
Notable Achievements
- Successfully the operation using fiddler to the 1 and only current implementation
Discovered issues
- No new issues in the one implementation (which was facading existing functionality)
Next Steps
- Really do need further implementation experience on this operation
Patient Track
Goal
- The Patient Track continues to provide an introduction to FHIR and give participants an opportunity to get some hands on experience using the Patient resource. The Patient Track also provides participants with the opportunity to test their servers and clients using the TestScript resources that have been created--this testing is accomplished using the AEGIS Touchstone testing platform.
Participants
- James Cheung, Kaiser Permanente
- Raphael Majeed, University Oldenburg
- Amina Shaikh, Philips Healthcar
- Brain Wright, Mayo Clinic
- Joshua Varner, Corepoint Health
- Tyler Tallman, Breeze EHR
- Victor Vaysman MD, MedSide Healthcare
- Swastika, BC/BS of Louisiana
- Ron Shapiro, Qvera
- Richard Ettema, AEGIS
Notable Achievements
- Continue to provide newcomer orientation and direction towards participation
- 25-30 attendees at the FHIR Overview and FHIR Testing breakout sessions on Saturday
- 9+ organizations successfully exchanged FHIR Patient resource
- 4+ organizations successfully executed FHIR TestScripts on AEGIS Touchstone
Screenshots
Discovered issues
- Enhance Create Patient Test Scripts for Server Assigned ID to validate that the resource ID returned is different than the resource ID provided by the client, if provided.
Next Steps
- Add ability to 'publish' results from Touchstone directly to the Connectathon Management Application.
Pharmacogenomics CDS
- PGx CDS connectathon track proposal: http://wiki.hl7.org/index.php?title=201801_Pharmacogenomics_CDS
- PGx CDS Service storyboard: https://docs.google.com/document/d/1VqPrf6aaOB8RhSbAq2JYDxZYbDm-RT9DxA0u6-RxYo0/edit
Goal
Upon order entry of a medication, check for drug-gene interactions and produce recommendations.
Participants
- Bob Dolin, Elimu Informatics (track lead)
- Aziz Boxwala, Elimu Informatics
- Kevin Power, Cerner
- Dave O'Larte, Cerner
- Xin Liu, Boston Children's Hospital
- Fan Lin, Xiamen University
- Lei Liu, Xiamen University
- Bob Freimuth, Mayo Clinic
Notable Achievements
- PGx CDS Service
- PGx CDS Service interacts with EHR (via CDS Hooks), OMIC Data Store (via FHIR), and Terminology Server (via FHIR).
- OMIC Data Store
- Interacts with PGx CDS Service (via FHIR)
- EHR
- Order entry of a medication triggers a “medication-prescribe” CDS hook which invokes the PGx CDS Service and provides it with a FHIR MedicationOrder instance.
- Terminology Service
- Interacts with PGx CDS Service (via FHIR) to see if the ordered drug is in an “Actionable PGx Drug” value set.
Screenshots
Overall worklow is shown in the following figure:
Discovered issues
- Challenging to deal with structural variations
- Challenging to represent star alleles, haplotypes, and genotypes (and their correspondence to variants)
- Multiple ways to represent variations (e.g. observation-genetics, PGx example, HLA resource)
Next Steps
- Add in additional drug-gene interactions (in addition to azathioprine/TPMT)
- Modify logic to leverage Ancestry where applicable to guide PGx recommendations
- Enhanced CDS functionality, such as: patient already on med (therefore suppress alert), provider has chosen to suppress a particular alert, etc.
- Deeper dive into interplay between star alleles and variants
Provider Directory
Goal
- Provide Guidance and get feedback on the current provider directory resources/IGs (Core/Argonaut/Validated Healthcare Directory)
Participants
- Brian Postlethwaite (Telstra Health)
- Tim Berezny (CareDove)
- Nikolay Ryzhikov (Health Samurai)
Notable Achievements
- Reviewed Canadian Referral IG and how it relates to Provider Directories, and compared it to an Australian directory IG that is also in progress at HL7 Au.
- Performed some testing on the Care Dove implementation using Fiddler (found some minor API issues).
- Health Samurai provide NPES data as FHIR API (interested in collaborating to make public)
Discovered issues
- Identified some of the duplicated content among the directory resources, but was able to explain why this is the case, and how to handle these
- Maybe some additional
- Since the introduction of the Endpoint resource, the HealthcareService's referral method should be re-validated
Next Steps
- The Canadian and Australian IGs on eReferral and Directory support will co-ordinate activities
Scheduling
Goal
- Pilot the Argonaut Scheduling Implementation Guide (https://argonautproject.github.io/scheduling/OperationDefinition-appointment-find.html)
- Discovery of what works and what doesn’t
- Determination of Future steps
- Network with Fellow Schedulers
- Chat and Commune with the FHIR Community
Participants
Expected participants
Servers:
Name | Use Case 1 | Use Case 2 | Use Case 3 | Use Case 4 | Use Case 5 |
Cooper Thompson: Epic | X | X | |||
Andrew Torres: Cerner | X | ||||
Brian Postlethwaite: Telstra Health (HealthConnex) | X | ||||
Eric Haas *Track Lead*: Health eData Inc (Flask Facade on Test server) | X |
Clients:
Name | Use Case 1 | Use Case 2 | Use Case 3 | Use Case 4 | Use Case 5 |
Brandon LaRue , Eugene Yao: ZocDoc | X | ||||
Eric Haas *Track Lead*: Health eData Inc (Postman) | X | X | X | X | X |
Notable Achievements
- Review of Prefetching Appointments Scenario
- Resolution of Outstanding Issues
- Simple Demonstration Application reflecting most basic scenario
- Future Plans
- Final edits and updates to IG
- Publishing date at end of February
- Implementations based on IG in late 2018
Screenshots
Discovered issues
- The prefetching scenario described in the IG lead to several breakout sessions to resolve the workflow and APIs needed for implementation.
- Identified solution for each issue and were able to document the changes to the IG make prefetching more implementable.
Next Steps
- Future Plans
- Final edits and updates to IG
- Publishing date at end of February
- Participation at DevDays USA in June ( Speaker TBD )
- Implementations based on IG in late 2018
Terminology Services Track
Goal
- Formal Testing of Terminology Services
- Introduction to Terminology and Terminology Services
- Developing Terminology Servers and Clients
- Engaging/Involving Other Tracks with Terminology and Terminology Services
Participants
- Ettema Richard AEGIS.net, Inc.
- Ho John 3M Health Information Systems
- Schneider Joel NMDP / CIBMTR
- Kramer Ewout Furore
- Macumber Carol Apelon, Inc.
- Wang Yunwei IMO
- Calderero Michael Accenture
- Egelkraut Reinhard HL7 Austria
- Graham Carol Clinical Architecture
- Hausam Rob Hausam Consulting LLC
- Humpherys Kristen 3M HIS
- Jordan Peter HL7 New Zealand
- Kartchner Tosh 3M Health Information Systems
- McClendon Craig Accenture
- McClure Robert MD Partners, Inc.
- McIlvenna Sean Lantana Consulting Group
- Nachimuthu Senthil 3M Health Information Systems, Inc.
- Ross Ron Clinical Architecture
- Mike Lapshin Health Samurai
- Sagy Pundak Mintz Allscripts
- Patrick Werner Heilbronn University
- Bertil Reppen Apertura
Notable Achievements
- Track orientation breakout
- Formal testing of multiple terminology service operations on multiple terminology servers (results below may not be complete)
- There are 11 participants and 7 watchers.
- There are 4 unique Servers associated with scenarios in this track. These are:
- IMO (Yunwei Wang)
- Hausam Consulting Test Server (R4) (Robert Hausam)
- Terminz (Peter Jordan)
- Clinical Architecture 3.0.1 (Ron Ross)
- There are 3 unique Clients associated with scenarios in this track. These are:
- Postman (Robert Hausam)
- Trifolia DEV Environment (Sean P McIlvenna)
- Touchstone Testing Platform (Richard Ettema)
- Questionnaire Builder (Sean P McIlvenna)
- There were 46 test results reported. The test results broke down as follows:
- Result Count %
- pass 34 74%
- fail 2 4%
- partial 6 13%
- note 4 9%
- Code system supplement breakout
- Terminology versioning breakout
Screenshots
Discovered issues
- What challenged the group?
- Haven't yet achieved consensus on the capabilities of and rules around code system supplements - will continue to work on this.
- Have further work to do in determining how we need value set and code system versions to be represented and used in FHIR, and in achieving consistency across different terminology servers. Need this to be aligned at least generally in the conformance resources (e.g. CodeSystem, ValueSet, StructureDefinition).
- GForge trackers created
- What questions did you come away with?
Next Steps
- Further enhance formal terminology testing.
- Develop tests around value set and code system versions - that was planned for this time, but not progressed as far as we desired.
- Consider doing direct comparison of results of terminology service operations across various servers (could do this in a breakout session?).
Versioned API
Goal
- Develop a strategy and some technical techniques so that server operators and clients can indicate which version of the FHIR standard they wish to use for communication. This will be helpful for maintaining compatibility with a variety of clients without requiring server operators to maintain as much infrastructure and will help avoid distributing canonical urls for resources that are tied to a specific version specific endpoint.
Participants
- Grahame Grieve (Health Intersections)
- Bradley Strecker (Cerner)
- Chris Gentz (Analysts)
- Cooper Thompson (Epic)
- Ewout Kramer (firely)
- Kevin Olbrich (McKesson Specialty Health)
- others...
Notable Achievements
- MIME-type usage for versions
- Requests
- Client optionally specifies the version of the API request
- 'Content-Type' header
- Odd for GET (and other) request verbs, but not forbidden
- named 'application/fhir+json; fhirVersion=3.0' using the major and minor versions of the semantic version.
- patch version levels will be ignored by the server
- no version or no header are interpreted as the default version for the server
- 'Accept' header
- provide a comma separated list of mime types in order of preference (i.e., 'Accept: application/fhir+json; fhir-version=3.0, application/fhir+json; fhir-version=1.0.2, application/fhir+json, application/json+fhir, application/json')
- Don't use 'q' to indicate order
- Server determines the version of the request and responds
- Error conditions
- if the resource in the request is not compatible with the version specified (i.e. it doesn't exist in that version)
- if the server does not support the specified version
- Response
- Server uses the 'Accept' header to determine which version to use for the response
- Use mime types in order specified, first one satisfied by the server should be used
- Server should ignore versions it does not support
- Ignore patch version if specified (i.e., `fhirVersion=3.0.1` is the same as `fhirVersion=3.0`)
- If no version is specified, use the default server version.
- Server should indicate the version used in the response by adding the `fhirVersion=3.0` parameter to the 'Content-Type' header of the response.
- Server uses the 'Accept' header to determine which version to use for the response
- CapabilityStatement / Conformance
- Server returns a CapabilityStatement or Conformance that is appropriate for the version of FHIR requested and the default version if it is not.
- The capabilities may be different between versions. A server operator may choose to have older FHIR versions be read-only or not support searching or other operations.
- Proposed `[base]/$versions` operation will return a list of FHIR versions supported by the server (optional, and obviously not supported on legacy servers).
- Error conditions
- Requests
- Versioned API urls
- This approach remains useful when the header can't be specified or preserved
- Not precluded by the MIME type approach
- All resources in a bundle/request must be the same version
Discovered issues
- Transforming Resources from one version to another is fraught with peril. It can work in some cases, but won't in many others.
- ValueSets and other terminology will be quite problematic between versions.
- Resources written to storage may become decoupled from the version information.
- There are nuances about the mime type approach with regard to normative resources that remain to be fully explored.
- OAuth scopes need to be carefully considered
- _format parameter behavior has not been explored
Next Steps
- Need some reference servers that implement this pattern for testing
- Identify test cases
- Try it
- formal proposal