- Overview of who FHIR-I is/what we do
- Tracker items (TBD)
- Grahame provided an overview of GraphDefinition
- Noted that the current resource defines a tree, not a graph
- Reviewed Rene's proposal based on his comparison against GraphML
- Rene was not present, so Grahame and others had lots of questions that could not be answered
- Don't understand minInstances and maxInstances
- Don't understand mustSupport
- is profile ordered? why 1..*?
- ... and so on (Grahame captured in his notes, will ask him to add here)
- Grahame will present his questions to Rene and raise on a future FHIR-I call.
- Also seems that there are somethings you can define in the current GraphDefinition that would not be possible with the new one (i.e. equaledgeSource/Target do not seem to be the equivalent of compartment
- Discussed the different IG kinds
- US Core mixes 1 and 3 (the extensions are national, but Patient.name 1..* is an EHR exchange agreement inherited from Argonaut)
- Best practice should be to pick just one
- Discussed the cardinality of kind. Should probably be 1..*.
- Should the kind codes be extensible?
- ImplementationGuide.useContext might be appropriate for this, but is more complex than just a single code.
- Will update the task to create a set of codes and values for useContext that would serve this same purpose.
- Will change from exampleBoolean to isExample 0..1 (type = boolean) and change from exampleCannonical to just profile 0..*.
- Reasoning: conforming to a profile does not necessarily make something an example.
- Motion: Grahame Grieve/Eric Haas:
FHIR Tracker items
- What matters is not the capability of the system, but the purpose of the profile
- If profile is focused on decision support, and system happens to do read, the fact the element is MUST SUPPORT in the decision support profile has no bearing on what the system must do for read
- Agree to create examples of what must support might cover
- Not persuasive w/ mod
- 3 use-cases
- Lowest common denominator for the resource
- What meta.profiles will you recognize for search & validation
- What profiles define 'sub' behaviors for different subsets of the resource (e.g. lab vs. vitals)
- Will split into 3 different elements. Will also make clear that support for search is dependent on _profile search parameter.
FHIR Tracker items
- Apply changes already agreed to
- Agreed to change as proposed
- This was applied in R4, but was not applied (as was requested) to STU3
- Created a new issue - - FHIR-25766Getting issue details... STATUS to address the failure to apply to STU3 specifically
- Conformance is a boolean - you're conformant or not conformant.
- Proposed a candidate solution to this:
- Add a 'tag' that allows a system to explicitly declare "this instance is not conformant to the CapabilityStatement this instance asserts"
- IGs (or regulators) could constrain use of this tag - e.g. "must always be conformant - if you can't, suppress the data" or "can't be present for data created after 2015"
- Clients could decide how to handle data that declares itself to be non-conformants
- Punted to Patient Administration
- This was applied in R4, but not R3. - FHIR-25777Getting issue details... STATUS raised and approved to correct
- This will impact existing IGs and templates, but it makes and will make coding easier. This is a computable element.
- No reason not to be consistent
- Agreed to clarify
Wednesday Q4 (PA/FHIR-I) Joint Session
Question from PA. Would like to add encounter.start and encounter.end search parameters. Is there a better pattern to follow?
Lloyd gave an overview of CapabilityStatement and it's history (why parts are normative and other parts not, etc.)
Graham discussed adding "feature" to various parts of that would repeat and have a terminology binding to a set of features, likely a boolean for whether or not the feature is supported. Would also require the context (a triple of context, feature, and value), but the context is defined by where it is (such CapabilityStatement.rest.resource). Could potentially also contain a condition stating something like "we support this, but only for X", and documentation which would be markdown describing the feature.
Example 1: updateCreate in CapabilityStatement.rest.resource
- dontext: rest:server.Observation
- dapability: updateCreate
- documentation=Only for vitals
This would allow clients to ask for the feature set they need, such as a set of SMART features.
Maybe instead have one set of features on the root of CapabilityStatement and make the context explicit on each feature.
Example 2: Messaging
Example 3: Subscription Topics
Discussed servers with multiple endpoints. Right now each has their own CapabilityStatement at endpointx/metadata.
Consider returning the CapabilityStatement for the specific endpoint, but also a list of other CapabilityStatements that the server supports.
Might only be one endpoint (the gateway) that returns that list of other endpoints.
- CapabilityStatement.otherService 0..* canonical(CapabilityStatement)
- CapabilityStatement.feature 0..* BackboneElement
- CapabilityStatement.feature.context 1..1 code CapabilityStatementContext required
- CapabilityStatement.feature.name 1..1 code CapabilityStatementContext required
- CapabilityStatement.feature.value[x] 1..1 boolean | uri | integer | Coding ?
- CapabilityStatement.feature.documentaiton 0..1 markdown
- CapabilityStatement.type 0..1 code CapabilityStatementType required
The CapabilityStatementContext, CapabilityStatementProperty, and CapabilityStatementType will be code systems will include a grammar allowing extension by others
Will likely set StructureDefinition.experimental on CapabilityStatement2
Document the meta?context=foo,bar&feature=bar,foo
Motion to approve these changes: Grahame Grieve/Issac Vetter: 10-0-1
Motion: Nick George, Eric Haas: 11-0-0
Grahame will get a list of all trackers that are validation issues and provide to Yunwei to send an email to the submitters to check if there are still issues, and if so to submit a test case demonstrating that fact, since Grahame thinks that most of these are fixed now.
IG Related Tracker Items
Decided to rename to Full Structure instead of Full View. Will also add text to that tab describing what it is that mentions the old name "snapshot".
Persuasive with Mod
Motion: Rick Geimer/Grahame Grieve: 7-0-1
Will do, but try to find a better icon than US Core. Grahame will implement it as a popup and get feedback to see if it should just be a static button.
Motion: Rick Geimer/Eric Hass: 8-0-0
Agreed to add support for this and update the NPM package spec, though the HL7 package stack and server won't support this.
Motion: Rick Geimer/Grahame Grieve: 7-0-1
Need the URL of the bad example so will assign back to the submitter.
Grahame says the ID column shows the end of the OID for the value set, but it's not really useful here to he will remove it.
Persuasive with Mod
Motion: Rick Geimer/Eric Haas: 8-0-0
Changed to a technical correction, as it has already been fixed.
Pretty sure JSON signatures don't work at all, and the XML ones may work but need more experience.
Should have a Connectathon track before we make changes such as what this tracker suggested, such as propogating signature everywhere.
Thanks to Michael Donnelly for the following minutes:
Michael Donnelly: J#18445 - How is the scope of a signature determined? - N-Infra #133
Michael Donnelly: Lloyd: we know how to canonicalize a signature on a single resource but not on broader or narrower concepts.
Grahame: why does IHE need this?
John Moehrke: Not certain
GG: Are we content to wait for an implementer to push on this, or should we do so?
MD: wait for implementers
John: agree, though this is time wasted where nothing is used
GG: assign back to balloter?
LM: that's me
LM: e.g. Provenance can apply to multiple resources, so it's unclear how this would work.
Michael Donnelly: Lloyd and John discussed details of stitching, of metadata. A signature element contains a manifest of what was signed.
Michael Donnelly: MD: How soon are we to the point where this will trip up someone?
LM: hasn't happened yet; could be tomorrow
John: that's why we have a "here be dragons" indication on this non-normative content
Michael Donnelly: John: the stitching problem is addressed because a signature in and of itself isn't a signature of a single item, it's a sig of everything in the manifest. When you validate, you rely only on what's in the signature blob.
Michael Donnelly: [John Moehrke/Grahame Grieve: 6-0-0]
Will adjust the XML language as follow:
This specification defines the following method for canonicalizing FHIR resources, when represented as XML:
Each XML instance or fragment that is part of the collection being signed SHALL
- Contain no white-space other than single spaces in attribute values and in the XHTML in the Narrative
- Use default namespaces for the FHIR and XHTML namespaces
- Omit all comments
- Always use the Unicode character representation for any XML entities (e.g. ' instead of ")
- Include the XML processing instruction <?xml version="1.0" encoding="UTF-8"?>
- Using the XML canonical method Canonical XML 1.1 (http://www.w3.org/2006/12/xml-c14n11)
Will change the JSON as follows:
This specification defines the following method for canonicalizing FHIR resources, when represented as JSON:
The signed set of fragments SHALL be transformed such that:
- No whitespace is included other than single spaces in property values and in the xhtml in the Narrative
- Properties are ordered alphabetically within each object
- Multiple fragments are concatenated with no intervening white-space in the order defined by the element with the Signature data type.
Michael Donnelly: The WG adjourned the quarter at 15:32.