Skip to end of metadata
Go to start of metadata

See FHIR WGM Agendas 2020-01

Attendees: 

Tuesday Q1

  • Overview of who FHIR-I is/what we do
  • GraphDefinition
  • Tracker items (TBD)

GraphDefinition Discussion  FHIR-25474 - Getting issue details... STATUS

  • 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

FHIR-24885 - Getting issue details... STATUS

  • 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. 

FHIR-23965 - Getting issue details... STATUS

  • 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: 
    13 abstain
    0 against 
    21 for

Tuesday Q2

FHIR Tracker items

FHIR-23720 - Getting issue details... STATUS

  • 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

FHIR-25462 - Getting issue details... STATUS

  • 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.

Tuesday Q3

FHIR Tracker items

FHIR-24350 - Getting issue details... STATUS

  • Apply changes already agreed to

FHIR-24448 - Getting issue details... STATUS

  • Agreed to change as proposed

FHIR-25133 - Getting issue details... STATUS

  • This was applied in R4, but was not applied (as was requested) to STU3
  • Created a new issue -  FHIR-25766 - Getting issue details... STATUS  to address the failure to apply to STU3 specifically

FHIR-25183 - Getting issue details... STATUS

  • 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

FHIR-25733 - Getting issue details... STATUS

  • Punted to Patient Administration

FHIR-13331 - Getting issue details... STATUS

  • This was applied in R4, but not R3.  FHIR-25777 - Getting issue details... STATUS  raised and approved to correct

FHIR-25747 - Getting issue details... STATUS FHIR-25748 - Getting issue details... STATUS  assigned to SDC

FHIR-25569 - Getting issue details... STATUS

  • This will impact existing IGs and templates, but it makes and will make coding easier.  This is a computable element.

FHIR-25410 - Getting issue details... STATUS

  • No reason not to be consistent

FHIR-25281 - Getting issue details... STATUS

  • 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? 


Thursday Q4

CapabilityStatement discussion. 

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
  • valueBoolean=true
  • ?condition=category=vitals
  • 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

  • context=messaging.definition(http://foo)
  • capability=endoint
  • valueUrl=http://whatever

Example 3: Subscription Topics

  • context=subscriptions
  • capability=...
  • value[x]=...


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. 

Recommended changes

  • 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

Trackers

FHIR-25927 - Getting issue details... STATUS

Motion: Nick George, Eric Haas: 11-0-0


Friday Q3

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

FHIR-19967 - Getting issue details... STATUS

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


FHIR-20356 - Getting issue details... STATUS

Persuasive

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


FHIR-25772 - Getting issue details... STATUS


Agreed to add support for this and update the NPM package spec, though the HL7 package stack and server won't support this. 

Persuasive

Motion: Rick Geimer/Grahame Grieve: 7-0-1


FHIR-20180 - Getting issue details... STATUS

Need the URL of the bad example so will assign back to the submitter. 


FHIR-22988 - Getting issue details... STATUS

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


FHIR-21004 - Getting issue details... STATUS

Changed to a technical correction, as it has already been fixed. 


FHIR-16519 - Getting issue details... STATUS

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.













  • No labels