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

FHIR Infrastructure Minutes WGM 201701

From HL7Wiki
Revision as of 17:15, 15 September 2017 by Lmckenzi (talk | contribs) (→‎Monday Q1)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

FHIR Infrastructure 2017 January San Antonio WGM Minutes

Return to FHIR Infrastructure Minutes

Agenda

Monday Q1

Chair: Lloyd McKenzie

Attendance sheet: File:2017-01 FHIR-I Attendees Sheet.pdf


Administrivia:

Need to appoint temporary co-chairs for Thursday joint meetings.

  • Thur Q1 - Simone Heckman (Devices)
  • Thur Q2 - Bryn Rhodes (CQI)
  • Thur Q3 - Rick Geimer (SD)

Approved: James Agnew/Richard Ettema: 35-0-0


Tracker Items:

  • 12198 - Default slices - Persuasive
  • 12295 - Make elementdefinition.base mandatory - tabled
  • 9791 - Clarify base for snapshot with profiled types - Withdrawn
  • 12259 - Clarify implicit type slicing behavior - Persuasive
  • 12061 - Element.url missing slicing - Persuasive
  • 12068 - Remove restrictions from _has - Persuasive
  • 12311 - ElementDefinition should have isOrdered - Persuasive

Monday Q2

Chair: Ewout Kramer

Attendance sheet: http://tinyurl.com/201701-fhir-i


Review items outlined in email sent by Lloyd McKenzie on 2017-01-15 18:23:00 with subject "PLEASE READ: FHIR tasks for all committees and publication countdown" - http://lists.hl7.org/read/messages?id=307213

  • looking for volunteers to help with these items
  • send an email or talk to FMG to coordinate


FHIR Release 4 discussion

  • primary focus is to take the Infrastructure Normative
    • this does not mean everything is Normative, but only the Infrastructure
    • most of the Infrastructure content is pretty stable and so it can be Normative
    • some sections will be Normative, others will still be Draft
    • dependency work needs to be done first--can't mark a resource as Normative that uses Experimental or Draft data types
  • take comments on Infrastructure
    • if substantive changes are required, we will not go Normative
    • if there are no substantive changes required, then we will go Normative
  • target Sept 2017 to close scope of what to include or not include in R4
    • example of search enhancements that continue to be brought up
    • discussion about bringing Observation, Medication, etc to Normative
      • need to accelerate them to Normative, but probably not R4


Tracker Items:

  • 12349 - Define Special Patch resource for supporting Patch in transactions, batches, history entries - defer for later discussion
  • 11419 - Reference may be by reource ID or Business Identifier. - 2016-09 core #577 - move to Block Vote
  • 12524 - Incorrect/conflicting location for the SUBSETTED Tag to be included - Persuasive
  • 11088 - Problem with automatic code generation from search params - 2016-09 core #169 - Persuasive with Mod
  • 12456 - IG Publisher expects unrealistic url for value sets in implementation guide - defer for later discussion


Monday Q3 (Workflow)

Chair: Lloyd McKenzie Minutes: Riki Merrick

Attendance sheet: http://tinyurl.com/201701-fhir-i

  • Connectathon track update:
    • Joined attachments group, using event request pattern and replied with attached documents for claims
      • Designed 3 use cases, only 1 aligns with the patterns defined
      • One of those is unsolicited – no request, so no need to align (different from workflow)
      • Use of data warehouse – should review that one for addition
    • Plans for workflow connectathon track in Madrid – looking for more participants – have 4 guaranteed Austrian companies (one virtual)
  • Updated patterns
    • Split into multiple tabs [1]
      • Ad hoc
      • Workflow management
      • Examples – looking for volunteers
    • Patterns supported for:
      • Event
        • Reference to practitioner can be associated with multiple organizations, added on behalf of as 0..1
      • Request:
        • Added intent as 1..1 – high level value set, can be extended for more
        • Some changes in cardinaltities
      • Definition:
        • Alignment with metadata from other definitional resources, like value set
  • Workflow project summary
    • Had grab bag of topics related to workflow
    • Consistency of how resources were managing fulfillment
    • Capturing proposal vs plan vs order
    • Differences in handling relationships – component orders or reflex orders
    • Create workflow wiki page to document all activity resources and categorize into 3 types: event, request, definition)
    • Define communication patterns that apply to the above categorized resource = how can you ask for something to be done
      • Some mechanisms where acknowledgments (saying accept or reject) not allowed via FHIR
      • Created task resource to handle state machine for fulfillment
    • Looking for real world scenarios on how that works in practice – worked on lab workflow, that need to get published
    • Representing the list of test that will be part of that workflow
      • ActivityDefintion and PlanDefinition (protocols, order sets, etc.) resources describes each task and relationship to others (parent task link, each child tasks has own state that can then be applied to the
    • tag of actionable status – MUST explicitly add to make something actionable – default is non-actionable, used tag outside the signature to allow “copy to” – that supports passing around information when it is not actionable
  • FHIR related email – MUST READ:
    • Request to add mappings to workflow from your resource – examples are in the task resource = identify the specific resource data elements that correspond to the so task element – names don’t need to align
      • Task acts as request
      • Task also represents event occurring
    • This will help identify divergence in naming and datatypes etc.
    • Also identify which task elements occur in most of the resources – so may not need to be included in core resource
    • Some elements may be applicable in extension (must define the extension before doing the mapping including the context for that extension), others may be never apply
  • MessageDefinition
    • Event
    • Category = Dealing with out of order receipt and how you can handle that
    • ResponseRequired
    • Message header can have 0..* as focus (resource and profile of that resource)
    • Max is using ST datatype, because we need to support * - so we have it constrained to numbers and *
    • Define allowed response messages
    • Please review if this makes sense
      • Looked in conformance profiles, v3 and v2 – what do you need to know for specifying a messaging interface
    • Asynchronous messaging can give you acknowledgment
    • Can also support this in operations
    • Did you have use case in mind – was thinking of lab, where you have to have receiver acknowledgment
    • If message definition is similar to events in v2 – is the WG defining these or is this adhoc only?
      • Several will be defined by HL7, but can define own operations in their space
      • Consider definition for general events for use internationally
    • Should this be introduced now?
      • Prefer to just have one way to do things
      • The current way does NOT support all use cases, but that is what passed ballot, so introducing the MessageDefintion to help folks know we have an option (experimental), when current approach does NOT work
      • Ultimately there should ONLY be one way, but this is following process that we don’t redo everything compared to what was balloted (would have to re-ballot, if we did that)
  • Open issues for workflow
    • Skip topic of using task in MessageHeader
    • OperationDefintion vs ActivityDefinition? to define task
      • OperationDefintion is service boundary, not describing what happens after that boundary
        • Defines parameters, which could be helpful for task
        • Give me observations that match code X and date range, or may be even last two of these – DataRequirement data type
      • ActivityDefintion describes the detail that should happen and has enough information to automate instantiation, though it may not always be used for automation
      • Example: task definition of: fill diagnostic request – may need mandatory input for a specific observation, like patient must be fasting before you fulfill this
      • Granularity needed is dependent on the use case – example eDOS on FHIR and then decide if the detailed information should be a separate resource or apply here
        • Also on OO agenda currently Wed Q3, but may move, as that became a spit quarter, both of which require Eric’s presence
    • Overlap between SupplyRequest/DeviceRequest/VisionPrescription – not discussed
  • Patterns for other resources like CatalogEntry etc – is tangentially related to the ActivityDefinition talking point above


Monday Q4 (Workflow)

Chair: Lloyd McKenzie

Attendance sheet: http://tinyurl.com/201701-fhir-i

  • Should we have patterns for other categories of resources? (e.g. catalog entry, entity, role)
    • discussion about establishing other patterns to provide consistency with similar resources
    • potential interest in defining additional patterns, but not a high priority--need to get workflow stable first
    • possibilities include catalog entry, "instance" entities, "kind" entities, "statements" (medication/device/procedure/etc.)
  • Outcomes of mapping exercise
    • Element inclusion, element names, vocabulary, definitions
  • Exercise of documenting intersection between Task, Request and Event state machines, including common exceptions


Tuesday Q3

Chair: Josh Mandel

Attendance sheet: http://tinyurl.com/201701-fhir-i

Tracker Items:

  • 9283 - Need support for resource element cardinality of 2..* - Persuasive with Mod
  • 11224 - ValueSet.id isn't in the representations - 2016-09 core #378 - Persuasive with Mod
    • considered rendering inherited elements in grey, but unsure how to show actual object that they are inherited from
    • suggest bringing the comments that show on the XML/JSON/Turtle views to the Structure view
  • 10249 - Consider displaying first level of hierarchy for Complex Types - Not Persuasive
  • 12081 - Extension naming differences due to IG build process - 2016-09 qicore #7 - Not Persuasive


Wednesday Q2

Chair: Ewout Kramer

Attendance sheet: http://tinyurl.com/201701-fhir-i

SMART on FHIR PSS:

  • Discussed the proposal, added Security as co-sponsor
  • Voted on the proposal, moved Michael Donnelly/Kevin Shekleton second: 10-0-0

FHIR-I tracker items:

  • 12349 - Define Special Patch resource for supporting Patch in transactions, batches, history entries - Persuasive with mod
  • 12618 - Make type of slicing explicit - Persuasive with mod.
    • Also split off the suggestions for "selector" extension into separate issue #12641
  • 10650 - Change ElementDefinition to allow multiple designations - Persuasive with mod.