Alix Goss
Bob Dieterle
Patrick Murta
Tim Young
Ed Martin
Tony Little
Rick Geimer
Jason Walonoski
Dan Chaput
Alex Kontur
Deliverable – Issue Statements
Bob – Alix/Bob reviewed work from the fall, attempted to recast as issues rather than observations, solutions, etc.
Issue: Versioning – how do we manage multiple versions of FHIR endpoints/artifacts?
- Currently multiple versions of FHIR in production
- Regulation supports adoption of new versions
- FHIR will continue to evolve
- A single organization may have information provided on one or more patients from different versions of FHIR
- Breaking changes between versions restrict ability to translate between versions
Bob – are these good issue statements, do you agree with them, are we missing anything?
- Geimer – good issue statements; missing the concept that increasing number of normative resources will reduce number of conflicts between versions over time
- Tony – are there issues around extensions that we need to consider re: versioning
- Geimer – don’t think that would be a big issues as long as extensions are validated/recognized. Any issues w/extensions are not unique to versioning
- Jason – raises the issue of profiling & IGs…does that fall under the umbrella of versioning?
- Geimer – may be worth adding an issue related to versioning within profiles/IGs
- Bob – “version issues are not limited to releases to FHIR core artifacts, but include extensions, profiles, and IGs”
- Ed – Any issues related to adhering to a standard, e.g. implementation differs across EHR vendors
- Geimer – for example: Sequoia directory is based on a pre-release version of FHIR STU3 (not compatible with the published version of STU3); EHR vendors may require different things in their HTTP headers; routine errors in implementation
- Bob – suggest that testing/validation is out of scope for our Tiger Team; “issues related to the implementation of versions should be considered by the Testing & Certification Tiger Team”
- Patrick – concerned that the way we version deviates from standard RESTful patterns
- Tony – as an implementer, what do I need to know the version of? Do I need to know the version of FHIR as well as the version of REST?
- Geimer – FHIR provides a normative RESTful API. Implementers may have an issue dealing with older versions of FHIR (and therefore the RESTful API). Not much we can do about deviations from RESTful patterns
- Murta – there is a certain versioning pattern that exists in the world re: RESTful APIs…e.g. people expect to see certain information (indicating the version) in the URI that FHIR implementations don’t necessarily use
- Bob – FHIR versioning of RESTful APIs may differ from general industry definitions
Issue: Identifying FHIR Endpoints & Services
- Bob – ability to identify a FHIR endpoint associated with a specific organization and supported services
- Murta – what does endpoint mean?
- Geimer – a FHIR server endpoint with an available capability statement that describes the rules associated with the endpoint
- Bob – but an operational endpoint wouldn’t necessarily have that, and we have both
- Geimer – “…identify a FHIR endpoint or other FHIR-enabled service endpoint…”
- Final language: Ability to identify a FHIR endpoint (server w/capability statement) or other FHIR-enabled service endpoint associated with a specific organization and supported services
- Bob – ability to identify trust framework(s) and/or authentication requirements associated with a FHIR endpoint
- Bob – implicitly includes pre-registration requirements
- Ability to identify the version(s) of FHIR supported at a specific FHIR endpoint
- Bob – Ability to identify the services supported at a FHIR endpoint…not an issue because a FHIR endpoint has a capability statement?
- Capability statement are not constrained enough to always provide all of the information necessary to understand services
- Bob – Do we create a more constrained version of Capability Statement, or do we include the ability to more definitively understand an endpoint’s capabilities in the directory itself – “ability to clearly define and understand supported services”
- Bob - Wouldn’t I want the directory to tell me which endpoint to hit, rather than hit each of multiple endpoints to figure out their capabilities?
- Geimer – want the directory to provide that information, and then need to check the capability statement at the endpoint to confirm; directory should periodically pull capability statements to verify/build content
- Bob – want each endpoint to clearly define its capabilities, and want the directory to include enough information to understand how a given endpoint can be used
- Geimer – “Ability to keep directory information updated with actual endpoint capabilities”
- Bob – Ability to represent testing and/or certification information
- Bob – trusted source of information – e.g. medical school is the only trusted source for provider’s education. Good observation but probably not an issue we need to identify
- Bob – patient identification/reconciliation is not an endpoint issue
- Bob – ability to keep endpoint and service-related information current
- Alix – scope/breadth of directory content is more of a future state item than an issue
- Bob – Ability to manage authorization to access endpoint details
- Tony – are there privacy issues we need to consider (participants in directory have to be reasonably sure that their information is protected)
- Bob – rephrase: “ability to restrict access to endpoint details”
Final language of identifying FHIR endpoints/services issues:
- Ability to identify a FHIR endpoint (server w/ capability statement) or other FHIR- enabled service endpoint associated with a specific organization
- Ability to identify trust framework and/or authentication requirements associated with a FHIR endpoint
- Ability to identify the version(s) of FHIR supported at a specific FHIR endpoint
- Ability to clearly define and understand supported services
- Ability to keep directory information up-to-date with actual endpoint capabilities
- Ability to capture/represent testing/certification information
- Ability to keep endpoint and service related information current
- Ability to restrict access to endpoint details