This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

FHIR Connectathon 18

From HL7Wiki
Jump to navigation Jump to search

Introduction

This page describes the Eighteenth FHIR Connectathon that will be held on Saturday/Sunday May 12-13 2018 at the host hotel, Maritim Hotel, Kolnin Cologne, Germany prior to the May HL7 Working Group Meeting.


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

Important notes

  • Track Planning and Orientation should be well under way. If you have not already, please be sure to create orientation slides for your track using the HL7 FHIR Connectathon 18 Track Orientation Template.
  • Connectathon will be based on the the R4 ballot candidate, unless stated otherwise in the track proposals.

Tracks

The following are the tracks for the Connectathon. Each item links to the original proposal, with the coordinators name and email on the linked page. View the link for details.

Connectathon Organization

The connectathon will be held over 2 days - Saturday May 12 9AM - 10PM and Sunday May 13 9AM - 5PM, prior to the HL7 Working Group Meeting.

Saturday is an extended day (9AM - 10PM), and is intended for participants to test and develop software in an informal way. Test servers are available (FHIR Test Servers ), but some participants may bring other servers along depending on the actors they are fulfilling. Sunday is also a full day. The actual programme is still being confirmed, but will likely involve concurrent break-out sessions for demonstrations and discussions of specific topics.

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

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


Connectathon Planning Team

Enrollment

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

Space at the venue is limited, so please register as soon as possible. Preference will be given to those who are participating in the technical event. Observers are welcome if space permits.

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


Test servers

These are the STU3 servers we are aware of:

FHIR Tutorials

  • There are 10 FHIR tutorials scheduled through-out the week
  • (Mon. PM) Introduction to HL7 FHIR
  • (Tues. AM) Designing and Architecting HL7 FHIR Solutions
  • (Tues. AM) Introduction to HL7 FHIR for Software Developers
  • (Tues. PM) HL7 FHIR for Clinicians and Decision Makers
  • (Tues. PM) HL7 FHIR Profiling
  • (Wed. AM) IHE on FHIR
  • (Wed. AM) Clinical Genomics Using HL7 FHIR
  • (Wed. AM) Clinical Documents on HL7 FHIR
  • (Wed. PM) Understanding and Using Terminology in HL7 FHIR
  • (Thur. AM) HL7 FHIR for Clinical and Administrative Workflows
  • (Thur. PM) HL7 FHIR Using SMART & CDS Hooks

Detailed descriptions are available in the Event Brochure

FHIR Proficiency Exam

  • The FHIR proficiency test allows test takers to demonstrate their knowledge and understanding of the specification. This is a basic proficiency test, not a professional credentialing test. It will be multiple choice, multi-select, and true/false and based on the STU3 specification and not on field knowledge. Those who pass the test will receive the FHIR Proficiency Certificate, a Certificate of Knowledge.
  • There will be a tutorial to help prepare for the exam: (Wed. PM) FHIR Proficiency Exam Review
  • The exam will be held on Thursday in the afternoon.

Work Group Meetings

HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources, and debating other aspects of FHIR implementation. There will also be meetings of the FHIR Governance Board and FHIR Management Group discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.

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

Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.

Outcomes (for coordinators)

A complete downloadable word document of the Outcomes for FHIR Connectathon 18 can be found on google docs.

Guidelines for report out:

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

Attachments

  • 1 paragraph summary: what was the track trying to achieve

Electronic attachments/medical records are a high priority for payer/provider interactions ( as most at least claims and prior authorization are manual processes today). Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track will explore the feasibility of this approach.

  • 1 list of participants

Anthem Inc., HCSC

  • 1 paragraph: notable achievements

- Built new patients and payer and provider information to build attachment requests - Send Solicited Communication Request from Payer to Provider for supportive document required (Left Knee Xray) for claims processing. - Then acted as Provider and to build Communication to send the requested attachment. - Sent attachment once as jpeg link to Xray and then again as encoded with base 64. - Also acted as provider sending and unsolicited attachment to payor

Worked with Financial Management – Paul Knapp - Built a claim from Provider - Sent a Pre-Authorization request to Provider

  • 1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements
  • 1 paragraph: discovered issues / questions (if there are any)

Attachments for claims and Pre/Prior Authorizations are considered administrative transactions in the US. Under HIPAA Regulation Standards Development Organization(SDO) X12 is the responsible SDO. However, there is substantial interest with FHIR-based messaging for exchanging attachments and prior authorizations. This track helps explore the feasibility of this approach.

  • 1 paragraph: now what?

Bulk Data

Summary: Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. This Connectathon track focused on testing export for all patients in a server, and for pre-specified groups of patients.

Participants: Google, Epic, Cerner, Boston Children's Hospital

Results: Connections! Two clients connecting to two servers. Exercised the API for kicking off a request, polling for results, and fetching files.

Discovered issues: Throttling while polling we should have consistent error codes (e.g. 429 status code for "too many requests") We need to test the currently defined approach with "Retry-After" header containing a http date or a delay time in seconds Should servers prevent client new exports while a previous request is running? We need to test the API For deleting a pending request (i.e. DELETE [polling content location]) We need to test the API with security (backend services) in place. Is it okay for a server to return multiple logically distinct resources with the same ID? What value does group-based export add vs. defining groups on-the-fly (e.g. using search parameters to define a set of patients with a given insurance plan) There is a growing desire to use this asynchronous pattern for other use-cases. Do we need to tease out documentation on asynchronous exchange from the bulk data aspects?

Now what? Encourage implementation of security, retry-after, and job deletion. Continue Argonaut review process and external security review by September WGM. Incorporate feedback into the Bulk Data spec and subsequently into the core FHIR spec.

Care Planning and Management

Summary: Effective care management includes active use of clinical practice guidelines and best practices that provide advice based on on evidence-based care, plus using these care protocols to create and share care plans among all members of a patient’s care team. This track emphasized integrating FHIR resources for PlanDefinition and CarePlan used to define protocols and create care plans, Business Process Modeling Notation (BPMN) standard to define clinical pathways, and FHIR PlanDefinition with Clinical Quality Language (CQL) to provide guidance at the point of care using CDS Hooks. Participants engaged in active coordination with Clinical Reasoning and CDS Hooks tracks.

Participants: Allscripts, Book Zurman, Clinical Cloud Solutions, InterSystems, Motive Medical Intelligence, Philips, Veterans Health Administration

Results: Continued work from January connectathon to develop sample FHIR resources that represent a realistic clinical scenario for a patient with Diabetes, Chronic Kidney Disease (CKD), and Congestive Heart Failure (CHF). All participants agreed that this realistically complex scenario provides a productive use case for analyzing and prototyping solutions for care planning and care management. This clinical use case is based on the NIH Chronic Kidney Disease (CKD) Care Plan project. We successfully connected FHIR care planning resources with clinical reasoning logic using the Clinical Quality Language (CQL) and CDS Hooks. The cqf-ruler server was used to develop a CDS Hooks service based on FHIR PlanDefintion and CQL to provide care management guidance for CKD a patient. CDS Hooks returns info cards with 2-year and 5-year kidney failure risk percentages, plus suggestion cards for ordering eGFR labs, referral to a nephrologist, or recommendtion for Pneumococcal Immunization, as needed based on clinical practice guidelines.

Discovered issues: Need to document required patterns for using FHIR PlanDefinition, ActivityDefinition, and CQL logic libraries to define CDS services for CDS Hooks.

Now What? Track participants agreed that these activities must continue with active collaboration and delivery milestones prior to the next connectathon in September. Discussed potential for proposing a project within the Healthcare Services Platform Consortium (HSPC) to develop reference implementations and document implementation guidelines. We also agreed to organize a Care Management interest table at the June FHIR DevDays meeting.

Catalog

Summary: This track is about sharing catalogs of orderable services or products in healthcare. Examples thereof include compendia of laboratory in vitro diagnostic services, medication formularies, directories of medical devices. This connectathon focuses on browsing through a clinical laboratory compendium, searching for entries which represent orderable tests or panels, and retrieving the details thereof: asked at order entry observations, specimens expected, output observations. The track is based on the R4 current ballot. A catalog [1] is a profile of the Composition resource. A catalog entry is using an EntryDefinition resource [2]. The other resources supporting the description of a laboratory entry are: ActivityDefinition, ObservationDefinition, SpecimenDefinition.

Participants: Phast (catalog server), University of Utah (catalog client), EMR Direct (catalog client)

Results: The two clients were able to interact with the server. Example:

The full scenario described on the catalog track page [3] was executed, which enabled to refine both the server and the clients.

Discovered issues: The set of resources defined for catalogs is adequate for a laboratory test/panel compendium, with all details. Some value sets of the new resources EntryDefinition, SpecimenDefinition still need to be finalized in the standard.

Now what? Need to finalize the bindings on the set of new resources: EntryDefinition, ObservationDefinition, SpecimenDefinition. Still need to test other kinds of catalogs (medications, other sevices, devices, …). Need to interest new parties on this topic, so as to grow for next connectathon in Baltimore. CDS Hooks Goals Gain implementer feedback on the balloted 1.0 specification. Participants EHRs Cerner Epic CDS Services Arpage AG / HL7 Switzerland Clinical Cloud Solutions HarmonIQ HLN Consulting IMO Interopion Lantana Consulting Group McKesson

Notable Achievements

HLN Consulting was able to integrate their immunization forecasting and electronic case reporting CDS Services with both EHRs and in doing so, identified a bug in the CDS Hooks Sandbox that we were able to fix as well as bugs in the EHR implementations. Lantana’s CDS Service evaluated a patient’s conditions and provided Zika screening decision support. Interopion was able to integrate with both EHRs to test their CDS Service that returns their SMART Pediatric Suite app to the user via a card. Additionally, we had a couple of participants create a CDS Service for the very first time. Seeing new blood participate in our track is great and a sign of a continually growing community.

We also held a CDS Hooks breakout session where we had a great discussion amongst track participants and those interested in CDS Hooks. This discussion resulted in great discussion on areas of the specification that we may need to improve based upon implementer feedback at the Connectathon. What’s Next? The CDS Hooks community is embarking on the ballot reconciliation process, the culmination of which will result in a published CDS Hooks 1.0 specification.

Clinical Notes

Summary Clinical Notes are a critical element for a clinician to communicate the status of a patient to another caregiver. These notes occur in various formats, such as: unstructured (XHTML, text), fixed file format (PDF, RTF), or structured (HL7 CDA/FHIR Composition). This Connectathon track focused on testing basic search and write using PDF, XHTML, and plain text. Participants Cerner, Epic, Argonaut

Results Progress! Two servers support returning clinical notes to initial scenarios. Exercised search by DocumentReference ID, patient, patient + note creation date, and patient + note type; and writing a new text or XHTML notes. Discovered issues Mime types and LOINC codes Each FHIR server supports a different subset of the ValueSets at these elements MIME type for DocumentReference.content.attachment.contentType. LOINC code for DocumentReference.type. Clients need to know what a server supports for create and read Discovering this by trial and error is time consuming and unlikely to be comprehensive. Communicating this out of band would pose implementation burden. We considered several options for a server to communicate what they support on read and write: CapabilityStatement.rest.resource.documentation - free text markdown CapabilityStatement.rest.resource extension - define extension to express this element is bound to a value set CapabilityStatement.rest.resource.supportedProfile - place to list all profiles you support for a given resource. Should also have a CapabilityStatement.rest.resource.profile which is minimum for all of that given resource. Extension on ValueSet to record which element(s) it constrains. This would allow a client to retrieve using /ValueSet?element=DocumentReference.type. We also discussed a vendors just posting to their website :) All these options are hard for clients add burden and challenge for clients without Test new DocumentReference.class value set to restrict DocumentReference retrieval to ‘clinical-note’ Imaging notes and Pathology reports may be retrievable as DiagnosticReport. Future discussion on whether those should be exposed through DocumentReference.

Clinical Research

What was the track trying to achieve We were working on providing some examples of the ResearchSubject and ResearchStudy Resources which could be used to supplement the implementation guide. We built the first two of 4. For real world we tried to map the content in a ClinicalTrials.gov trial registration to a ResearchStudy resource. There was a discussion around the use of the PlanDefinition for implementing a Clinical Trial Schedule of Activities. Issues encountered include association of a set of activities (ie as a CarePlan instance) with an ARM.

1 list of participants (with logos if you have time and energy) Geoff Low, Medidata

Bob Milius, CIBMTR

Discovered issues / questions (if there are any) Evaluation of the model identified a couple of augmentations to be referred to the BR&R group for review: The ResearchStudy has a single sponsor reference; ct.gov has references for a lead_sponsor and zero or more collaborators. Propose adding collaborator attribute to the ResearchStudy so collaborators can be associated with the study. Alignment of Interventions in ct.gov schema with study summary is not clear, and will need refinement.

Now what? Feedback to the BR&R project on the findings for ResearchStudy. Suggest a session at the WG Meeting in Baltimore to expand on the alignment between the PlanDefinition and ODM/Protocol elements.

Clinical Reasoning

  • 1 paragraph summary: what was the track trying to achieve

We had two goals, 1) running patient-view hooks with Cerner and Epic and 2) Providing decision support content for the Care Planning track

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

Zynx Health Motive Medical Intelligence Apelon Philips Accenture

  • 1 paragraph: notable achievements

Imported PlanDefinitions from Zynx Health and Motive Medical Intelligence

  • 1-2 screenshots if relevant and interesting and/or links to further information about implementations/acheivements
  • 1 paragraph: discovered issues / questions (if there are any)

Found and fixed several issues with our implementation of CDS Hooks Found that we need a mechanism to determine the version of the FHIR server and support multiple FHIR server versions with the same endpoint

  • 1 paragraph: now what?

We had discussions with the Care Planning Track around the lifecycle of PlanDefinition and RequestGroup and how the CarePlan for a patient would evolve over time. We agreed on an approach where the optionality in a RequestGroup would be resolved to a new CarePlan. We are now incorporating that into the implementations and will continue testing the approach with the Care Plan track at future connectathons.

Direct / Certificates

Goals The purpose of this track was to continue discussion and trial use of certificate-backed authentication and authorization to access FHIR resources, in Scenario 1 using Direct messages for transport and in Scenario 2 using public key infrastructure (PKI) based trust networks to securely scale RESTful transactions.

Participants

Notable achievements At the Koln connectathon, the track added certificate-based Dynamic Client Registration to our test scenarios and the participation of additional track constituents in certificate-backed authentication to FHIR resources. Both scenarios were successfully tested. JWT profiles were discussed and refined.

Track participation introduced the following questions: 1. How will FHIR endpoints advertise what authentication method(s) are accepted?

2. What is the profile for Dynamic Client Registration? What minimum bar of attributes must clients provide when registering, how must/may these attributes be validated and how are they subsequently communicated to users and RSes?

3. How can specific data use agreements be incorporated into a trust framework? We have established practices when intermediaries direct traffic between endpoints, but what does that say about the relationships between the endpoints themselves, at the terminus of interoperability in either direction?


What’s Next Formalize client registration profiles

Note: Connectathon results for the Direct/Certificates track will also be reviewed at a DirectTrust webinar on May 21, Using DirectTrust To Establish A Trusted Exchange Framework For FHIR: https://register.gotowebinar.com/register/3869567737308632579

Documents

Goals Test/update mappings/transforms from CDA to FHIR Generate a fully bundled document from a Composition resource using the Generate Document operation Participants Sarah Gaunt (Lantana Consulting Group) Corey Spears (Infor) Gay Dolin (IMO) Amnon Shabo (Philips) Ron Shapiro (Qvera) Lisa Nelson (MaxMD) � Notable Achievements[edit] Scenario/Goal Participants Asserter Result Issues/Challenges/Notes Create and persist Document (bundle) from a Composition resource using $document operation Client: Postman Server: http://test.fhir.org/r4 Gay Dolin, Sarah Gaunt. Amnon Shabo Pass

Created a narrative document from C-CDA Document (C-CDA on FHIR from Ambulatory Transitions of Care) Client: Cloverleaf Integration Engine Server: HAPI Corey Spears, Gay Dolin Pass

Create document with entries C-CDA on FHIR from Ambulatory Transitions of Care, CCD) Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4 Corey Spears, Ron Shapiro, Gay Dolin Pass Refined transformations based on testing: Made sure that the legal authenticator and authenticator in the C-CDA were being handled properly and put into separate attesters in the FHIR target. Started a larger discussion around how to reference the source (CDA) document in the target (FHIR) document (bundle). Will take to SD. Discovered and resolved an issue around transformation of allergy status. Explored medication timing transforms Created GForge Tracker issue about requiring inline resources in the context of a clinical document bundle. (#17109) Different servers return quite different validation results. How to deal with negated concepts (such as no family history of cancer from a C-CDA document) - there is no way to transform this into FHIR and not lose the negation. Create clinically robust examples to test transformations Client: Cloverleaf Integration Engine, Postman, QVera Interface Engine Server: WildFire, HAPI, Vonk, http://test.fhir.org/r3 & http://test.fhir.org/r4 Corey Spears, Ron Shapiro, Gay Dolin, Amnon Shabo Pass Identified the need for more clinically robust examples Create and test imaging report document Client: Postman Server: http://test.fhir.org/r3 Amnon Shabo Pass Need a way to report on findings together with the actual imaging report - findings are fully structured. Starting point was DIR report in C-CDA on FHIR. Have now created a valid example that is fairly closely aligned with DIR. Review prototype FHIR R4 Mapping Language files n/a Lisa Nelson, Sarah Gaunt n/a Have noted issues with the mappings More explanation is needed on how the mappings are used Discovered issues See notes in table Next Steps Continue update of CDA to FHIR transforms Talk to SD about how to best reference the CDA source of a FHIR document (that is the result of a CDA to FHIR transform) - have added (RelatedDocument (e.g Transform, replace etc.) for Transformed Documents (both directions): Best practice and options) to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1 Options: Bundle.link.relation=”convertedFrom” and Bundle.link.url - should be able to link to a documentReference resource Composition.relatesTo - maybe add DocumentReference as a choice Revisit making Sections reusable (create Section resource or data type or something) - have created a GForge Tracker issue #17114 - have added to SD (hosting FHIR-I) agenda here in Cologne - Tues Q1 Continue to work on imaging report document modeling (alignment and refinement of the DIR and further specifying the entries in the sections) and examples Need more explanation around the FHIR R4 Mapping language files - maybe a demonstration on how to use them Have all the transform tools, including the FHIR R4 Mapping language files, transform a set of documents and compare results, which will surface differences and help come to a consensus on the correct approach to mapping the data Negation - how to deal with negation in FHIR

FHIRcast

FHIRcast synchronizes healthcare applications in real time to show the same clinical content to a common user, by extending SMART on FHIR to achieve tight integration between disparate, full-featured applications. Following implementer feedback at the January connectathon, the specification was updated to model a common webhook design pattern (specifically the W3C WebSub RFC). The track goals were to implement this new version of the specification and gather additional implementer feedback on these changes.

Participants Brett Esler - Oridashi Isaac Vetter - Epic Oliver Krauss - University of Applied Sciences Upper Austria Martin Bellehumeur - Siemens Healthcare Ashish Singh - Siemens Healthcare Bas van den Heuvel - Philips Richard Ettema - PenRad

Notable achievements Since our last connectathon, the community created an opensource FHIRcast sandbox (notably Leo Bergnéhr and Niklas Svenzen from Sectra). Brett, Martin, Ashish and the PenRad team stressed the sandbox and even found and documented some bugs. Overall, the sandbox is a great tool for developers new to FHIRcast. In addition to the sandbox, Brett also created a Hub, so the track had two distinct servers. Martin and Ashish, and Isaac each developed their own FHIRcast clients. Oliver dove into the specification while beginning work on both his own client and hub. Brett demoed his Hub in use by the Oridashi clinical application synchronizing with three different instances of Isaac's python client. Lastly, we also continue to refine and enhance the specification; notably, PR #25 begins to define multiple launch and SSO scenarios using Oauth and PR #24 describes bidirectional synchronization -- both critically important.

Also, see the video Brett made of FHIRcast in operation.

Discovered issues/questions The track identified a number of outstanding issues, both with the sandbox and the specification itself. Specification: Issue #29: How can a subscribed app validate that it's subscription is active? Issue #28: How can a subscribed app determine session context immediately upon subscribing? Issue #27: Does the callback url need to be verified as belonging to the subscriber? Issue #26: How are new events defined? Can we create a swagger definition for events? Sandbox: Issue #5: Notification context from sandbox doesn't conform to spec. Issues #8: Url verification parameters from sand box doesn't conform to spec.

What's next? The future is bright! Next steps include: Resolving the above issues and reviewing and incorporating PRs #24 and #25. Continuing to build the implementer community and respond to feedback. Ballot specification into HL7.

GDPR-General Data Protection Regulation

Examine FHIR capabilities and how they relate to an organization being GDPR compliant. This is not a general discussion of GDPR, but focused on helping the reader understand the capabilities that exist in FHIR.

Participants: Firely ByLight HL7 Austria CGM Clinical VA/BZI Infor Accenture

Accomplishments Shared spreadsheet mapping FHIR Capabilities to GDPR, with identified gaps Most interesting gaps Should there be a standardized operation for submitting an erasure request? More clear AuditEvent for Export that can be used to know where data has been propagated, to support a potential Erasure or Correction act. More clear how to use AuditEvent to support a report of all uses of an identified patient’s data

IHE on FHIR with focus on MHD

Expose the FHIR Connectathon community to IHE and the tooling from IHE Connectathon. Focus testing on the MHD profile as the most desired testing from the participants that signed up.

Participants HL7 Switzerland HL7 Argentina IHE Intnl IHE Services Firely ByLight Ahdis SAIHST

Accomplishments: The group primarily tested the FHIR conformance resources from MHD 6 bugs found and fixed Developed StructureDefinitions for response messages for each transaction Worked through some regional specialization to support regional health document exchanges. Cascading StructureDefinition from region constraints, while using MHD StructureDefinition Developed PDQm return response StructureDefinition IHE validator tool will validate all MHD, PDQm, and PIXm transactions

MedikationsplanPlus (German Medication Plan IG)

Summary

Testing of the German Medication Plan Profiles, Provision of a test server with numerous valid examples

Participants

  • Molit Institut,
  • HL7 Deutschland e.V.,
  • Lang Health IT Consulting,
  • Gefyra GmbH

We had no implementers participating in the track, but held it anyway in order to get the testing environment up and running for later repetitions of the connectathon and Medication Plan tutorials.

Achievements

Testserver is running with >300 example resources available (fhir.hl7.de)

Discovered issues

  • Issues with the core spec:
    • GF#16675: example uri in Identifier type contains whitespace -> profiles with Identifier types don’t validate in HAPI (solved locally)
    • GF#16586: Specify how $valide behaves with regard to resources with display values for foreign language resources -> Currently differences between java/.NET validator
  • Issue with Forge: Adding/editing invariants at root level results in corrupted Profile (resolved, thanks Michel!)
  • Issues with HAPI Server:
    • core extensions missing, can’t be uploaded (solved!)
    • Implementation of Composition/$document (which is currently not part of the HAPI-FHIR master branch) not yet correct, should return a Bundle of type document, not a search result.
    • non-core constraints hardcoded into Java validator (resolved locally)
  • Issues with HAPI FHIRPath engine:
    • resolve() is not implemented
  • Issues with .NET-Validator:
    • errors if display value doesn’t match code (resolved: we created new expansions of our valueSets with German display values)
  • Issues with our profiles (all resolved)
    • Errors in ValueSet Bindings
    • Insufficient mustSupport-Flags
    • Slicings that don’t work
    • MedicationStatement was not fully self-contained; dosage.asNeeded should be used (but see FHIRPath issue above).
  • Issues with our examples (all resolved)
    • Missing mandatory elements
    • Invalid units (wrong case)
    • Invalid Dates (with Timezone)
    • Empty values
    • Invalid Extensions
  • General issues with the “Medikationsplan plus” implementation guide:
    • Clarification about context and usage of the profiles needs to be added in the implementation guide
    • Identified limitations in the use of the FHIR profiles due to required compatibility with the in-sync CDA representation, may lead to future improvements in the context of workflows.

MedicationPlan issue-tracker:

https://github.com/hl7germany/medikationsplanplusplus/issues

Now what

After having detected and resolved many issues with our specification and the test server, we are now confident to release the testserver to the public and encourage implementation and adoption of the specification.

Storage and Analytics

Objectives: The track was devoted to bringing together FHIR storage & search implementers. We wanted to share experience, understand pros and cons of different approaches to storage and discuss practical questions that arise during the implementation.

Participants:

Notable achievements:

Hands-on guidelines with different implementation strategies created Created a README for individual database technologies Transferred queries between different query languages Discussion about the used datasets: create it before the connectathon in different sizes Discussion: Comparable queries are needed, based on CQL More databases start to natively support JSON, support for raw selection of elements can be provided by _query + indexed search based on FHIR search parameters

Open questions:

Find common README format for individual database technologies More meaningful queries are needed Get more participation, more databases, more other technologies Unify data with Bulk data track? Use Vonk Loader for other databases? How to combine _query with other search parameters? Is this needed? Based on FHIR Path?


Links:

Terminology Services

Questionnaire Track Objectives Start testing the revised R4 version of Questionnaire, including the updated Structure Data Capture specification. Discuss how to better handle population of QuestionnaireResponse instances from existing FHIR data and how to extract information from QuestionnaireResponse instances to populate other FHIR resources (e.g. Observation, MedicationStatement, etc.) Track Participants Lloyd McKenzie (lead), Robinette Renner, Ajay Kanduru, Brian Postlethwaite, Ana Kostadinovska Additional discussion Participants Chris Grenz, Simone Heckman, Brett Marquard, Brett Esler, Joel Schneider, Oliver Kraus, Grahame Grieve, Rick Geimer, Kathleen Connor, Bas van den Heuvel, Adnan Turic, Kevin Olbrich, Isaac Vetter Achievements Identified 3 approaches to pre-population Automated pre-population where the answer can be selected directly from existing data (e.g. Patient birth date) Assisted pre-population where candidate answers are selected from the data for the user to then choose from and upon selection, the question answer can be automatically populated. (e.g. Concurrent medications that may be relevant to this reaction) Question-specific information retrieval where relevant information from the EHR can be displayed to the user to allow them to synthesize and manually answer a question Identified candidate technologies to extract information from a QuestionnaireResponse to populate one or more resources (and/or request update of existing resources) Using definitions plus a profile containing fixed values Using StructureMap Using ActivityDefinition Issues StructureMap doesn’t currently allow Questionnaire as a source or target structure for mappings Next steps Will create examples using candidate information extraction approaches and review to identify what approach(es) should be supported in the eventual revised Structured Data Capture (SDC) specification Will take the updated specification to ballot in August and look to exercise it at the Baltimore Connectathon

Versioned API

Goals: Identify and address issues related to proposed mechanism for negotiating FHIR versions between clients and servers. Participants: Kevin Olbrich Christiaan Knaap Toby Hu Brian Postlethwaite Achievements: Conversion of resources from one version to another is a separate concern. When conversions happen the server operator may wish to indicate to the client that such a conversion occurred and indicate the quality of the conversion. Supporting conversion is not strictly required, but Clarifications about responsibilities of servers and clients Servers: Only one FHIR version in a response. No mixed formats. If you need resources with different formats, additional requests will need to be made. Should conform to the REST API behavior specified by FHIR for the appropriate version Should return the version in the ‘Content-Type’ of responses. If a client specifies different versions in the accept and content-type headers when creating or updating a resource then this can be interpreted as a request to convert the new/updated resource from one format to another. Server operators are not required to implement conversion. If they do support conversion then the proper resource should be returned. If not the server should return a bad request with an operation outcome in the format requested by the accept header and not perform the create/update. If a client requests a resource in a version that the server cannot represent the data in, the server should return an operation outcome with an error indicating this problem. This may occur if the server stores data in a FHIR-specific format and does not have the ability to convert from one to another or if it just has not completed the conversion yet. Maybe report the “available versions” in the CapabilityStatement.format element Clients: Given a client requests a CapabilityStatement from a server while also specifying a set of requested versions. When the CapabilityStatement returned does not include one of the requested versions Then an error should be indicated. The ‘fhirVersion’ parameter should be appended to all mime-types in the ‘Content-Type’ header for all requests with a body. (use case here is for POSTs with search parameters…. The content type would be application/x-www-form-urlencoded;fhirVersion=x.x). This also would cover other formats like msgpack or protocol buffers if they become supported. Discovered Issues: We need a server that implements the proposed mechanism so we can test against it A server operator may wish to indicate that a FHIR version other than the requested one is preferred (and it may be an older or newer one than that requested by the client) Use of the _format query parameter to specify versions is an interesting concept, but currently most servers don’t handle it well (some give bad responses, others ignore the entire _format parameter) Some server operators may have difficulty converting resources from one FHIR version to another and may not be able to return complete records in some cases. Consider tagging those resources with SUBSETTED. What’s next: Get a reference server implementation so we can perform tests against it

Other References



May 2018 Track Proposal Submissions were due March 31st, 2018. Please complete the template found at the track Proposal link AND contact Sandy Vance immediately if you are interested in making a late submission.

FHIR_Connectathon_Track_Process.

Return to the FHIR Main Page

Retrieved from "https://wiki.hl7.org/w/index.php?title=FHIR_Connectathon_18&oldid=161570"