Record Connectathon 17 Outcomes Here
Contents
- 1 Apps for Imaging Research
- 2 Attachments
- 3 Automated Profiling From Domain Models
- 4 Bulk Data
- 5 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 Terminology Services Track
- 26 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
- 1 paragraph: now what?
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
Notable Achievements
- Dynamic Health IT: 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
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Automated Profiling From Domain Models
Goal
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Bulk Data
Goal
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Care Plan
Goal
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
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
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
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.
- 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?
Next Steps
- Back to the Catalog task force (under OO WG) to complement the EntryDefinition resource (datatype changes, value sets, change parameters)
- Next connectathon will test the catalog management interactions (create, update, retire entries ...) and catalogs of knowledge artifacts
CDS Hooks
Goal
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Clinical Reasoning
Goal
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Clinical Research
Goal
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Consumer Centered Data Exchange
Goal
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
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
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
FHIR Documents
Goals
- Test/update mappings/transforms from CDA to FHIR
- To be able to import a CDA and transform it into it's 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 | Partial (still working on transforms update) | Updated CDA to FHIR XSLT transforms to support IHE Healthy Weight profile |
Display 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 |
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
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
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Financial
Goal
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Genomics
Goal
Genomic data are of increasing importance to clinical care and secondary analysis. 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. FHIR Genomics focuses on clinical genetics data reporting.
We will also look to compare current FHIR extension model with a component-based model. New genomics IG
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
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
- Diego Kaminker (Almadoc)
- Oliver Egger (The Hub Zürich Association)
- Steve Moore (IHE USA / Washington University)
- Bertil Reppen
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
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
Notable Achievements
- In addition to testing out the Device and Procedure resources we also tested Medication, MedicationAdministration, and Location. 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).
Other devices may be used to track changes in cancers and send information from implants.
Screenshots
- Not applicable at this time; this specification is meant to enable automatic data capture of identities, procode time, and location
Discovered issues
- There is a need to track the a tumor over a period of time as treatment and implants are applied to that site. Can we use BodySite for a turmo and "treat" the body site?
Next Steps
- We will add "MedicationAdmminstration" to the set of point-of-care procedures that may be report
Patient Match
Goal
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Patient Track
Goal
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Pharmacogenomics CDS
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
- Xin Liu, Boston Children's Hospital
- Fan Lin, Xiamen University
- Lei Liu, Xiamen University
- Bob Freimuth, Mayo Clinic
Notable Achievements
- Please limit to one paragraph summary
Screenshots
Overall worklow is shown in the following figure:
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Provider Directory
Goal
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Scheduling
Goal
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
Terminology Services Track
Goal
- Please limit to one paragraph summary
Participants
- Names and Company Names
- Logos optional
Notable Achievements
- Please limit to one paragraph summary
Screenshots
- 1-2 screenshots if relevant and interesting and/or links to further information about implementations / achievements
Discovered issues
- What challenged the group?
- What questions did you come away with?
Next Steps
- 1 paragraph: now what?
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
Next Steps
- Need some reference servers that implement this pattern for testing
- Identify test cases
- Try it
- formal proposal