FHIR Infrastructure Minutes WGM 201609

FHIR Infrastructure 2016 Sept Baltimore WGM Minutes

Return to FHIR Infrastructure Minutes

Agenda

• See FHIR_Agenda_201609_WGM

Monday Q3/Q4 Workflow

Attendees

Minutes: Q3

• Lloyd presented an overview of the content in the specification
  • Describing the logical model for request, event pattern
    • Flat patterns for these – can map resources to this – not exchangeable (no XML and no JSON)
  • Walking through the Request logical model elements: [1]
  • Request.stage – what kind of request (need a better name) – this does not change – need to create a new resource, if this changes
  • Focus – may need to get broadened
  • Supporting info should go to 0..*
  • Question – how would a given resource map to this – creating a structure map?
  • 4 mechanism possible:
    • structure map (very sophisticated allows transform, will need for reference representation creation)
    • concept map (less rigorous, less computable)
    • structure definitions in the v2 / RIM / DICOM mapping, and add in another column to add for workflow mapping (this is what we will be doing for now – captures core elements, but not extensions (names cardinality, datatype alignment check possible that way)
    • profile each resource based on the patterns
  • Agreement to go with mappings in the structure definitions for now
  • Question – difference between mapping between profiles and logical models / definitions – for mapping to Argonaut needs to retain some of their business logic etc. so not so easy to do for anything but structure map
    • Primary use case is to check for alignment in logical model to resources, depending on what of these categories they fall in
  • Should we wait until the logical model is more stable to avoid rework – some changes, but we used resources as basis – goal is to complete these models for STU 3 in the next 3 weeks
  • Mapping should be done before the content deadline for STU 3? Yes that is the desire – but can evaluate if these are critical for publication (propose not a publication requirement – will not hold release for this).
  • A lot of the mapping work does not require specific domain expertise, so have someone do a strawman for ALL resources – part of the process should be checking for alignment is important, so that will requires domain expertise – if alignment not possible, could still map what is there at high level.
• Reviewing Event: [2]
• Reviewing Definition: [3]
  • What difference between based on in request and parent usage
    • Based on = fulfillment (of a plan, or proposal)
    • Parent= child is part of the parent protocol = compositional view meant here, so fix the description, or the naming to “part of” parent describes an inheritances
    • propose renaming “parent” to “part of” – Lorraine, Bryn, further discussion: in observation you have related and related type – use the here so you can qualify the relationship – prefer to have specific element for a relationship rather than allowing the flexibility (component is also used in observation – that is from parent to child), while here we have the child pointing to the parent instead – like to have only one direction in the relationship in FHIR, against: 0, abstain: 0, in favor: 51
  • Definition – is that “basedOn” , “derivedFrom” vs it “hasDependency” and do we need that here and also in event and request

derivedFrom is pointing to protocols or plans, basedOn pointing to other requests

• • • if you need to document variances from the underlying protocol
    • in MedicationDispense deals with substitution and substitutionReason
    • this works in request, but in definition might want to still say – derivedFrom (not needed to execute) vs dependsOn (cannot run without) **** will add dependsOn
  • depending on the kind of things we are defining, we may need to expand on the definition resource – should these be enhancements to base pattern, or let everyone handle extensions
    • pattern = conceptually common across ALL definition things/events/request
  • question – visionPrescription is event, not request (not actionable)… any of these resources when created is an event, but request is intended for things that authorize action – visionPrescription ONLY specifies the controlled parts of the prescription, but cannot put the glasses together – missing defining information
    • have request resources, that have ALL the info to be actionable, while others may need more information before the request can be completed
    • VisionPrecription is outcome of the examination event
    • Request = authorization for action
    • Any order is subject to refusal, clarification etc – may be the description on visionPrescription is not quite right
• Fullfillment patterns: [4]
  • Several options - have diagrams for each options
  • Looking for input on how to make more readable – organized – will split
• Will add a cut-off for change requests for STU 3 publication expect 10/9
• Apply changes about 2 weeks after WGM, so please review workflow and patterns before then
• Hans slides: [File:WedQ3Catalog.pptx]
  • OO has started discussion about catalog resources
  • SOA Order Service is also interested in this space
  • Need WG and how to orchestrate coordination – need leads for the respective PSS

Minutes: Q4

• Catchup newcomers up to Q3 discussions and background info
• Need to make sure the second option H was not there – was not in the ballot version?
• If you post resource, it is not actionable UNLESS it has “actionable” tag on
• Ballot recon:
• 11190
  • Rename “stage” to “type” – in other resources we have used it – use “kind” - this vocab does NOT change in the resource – if it needs to change you need a new resource – so it is a kind in a stage – change to “intent”, except original and reflex order does not quite fit – have some higher level concepts along with the subtypes of order in this list
  • A reflex order is spawned under the authorization of the orginal order – may be a result or some other defined event that reflexes EVERY time – no additional authorization needed
  • Make intent and then authorization type – would have to make sure the specific intents are linked with the appropriate authorization type or intent type? – both level feed into business rules
  • What would implementers want – single mixed bag or 2 elements, where the high level may apply across all domains, while for the types it might be domain specific?
  • Other resources have category and code for this = we will also have category (imaging, lab, vital signs) in addition to the kind of order.
  • Split into

“intent” 1..1 code [plan| proposal | order ]

“intentType 0..1 codeable concept [e.g. original, coded, reflex, filler ] – this vocab is resource or even just domain specific, so extensible value set - filler and reflex seem to overlap – would be resource specific

• • in financial we will have very different requirements, but we do have similar notions = claim = please pay, pre-authorization, so may be change plan = , proposal = , order = (missed Paul’s examples) as a mapping to the resource structure, but we may need to add more concepts when we do the alignment work.
  • OR in the pattern just have the intent, and at the resource level map all the domain resources at the more granular level to the higher level, i.e. reflex order, original order both map to order. MAR (medication Administration Record maps to order? That is no longer actionable, it is the fulfillment of the order), so exchange with reflex order to avoid
  • In decision support they need to know, if something is actionable – so abstraction is helpful
  • At logical model we use plan | proposal | order – at the resource level the terms vary what is used there, but MAP to these model terms – would this need to be coding or codeable concept in order to deal with the extensibility in the resource level
  • Once approved, will need to lit this into its own tracker item, since this si on the logical model, but the comment was on **DiagnosticRequest = #11190, so created #12052
  • Motion to accept as proposed in tracker#12052 – Brendan, Hans, no further discussion, against: 0, abstain:3 , in favor: 38 – non-compatible, change required,
  • Reference#12052 in tracker item#11190
• 11492
  • need to add the word document to gForge still
  • Vassil submitted a word document for ballot comments – also in person – may need to vote on call, since not here ADD DOCUMENT HERE or the tracker Item created for it
  • Issue with use of term workflow:
  • Covers too many things – and have too many options – suggestion is to just use ONE way – may be split into simple and complex and then try to - this may not work in the current environment
  • Try to change name of the page, so we don’t use workflow for the age, the project and the patterns
  • Request to encompass the orders – but we had that discussion already twice, so leave
  • Request pattern = logical model vs task = resource – update the page and the hyperlinks accordingly
  • Still have some orchestration issues for simple transactions – but they don’t require the task resource – but we still need to describe this in the FHIR specification – can split out
  • Task came up in lab workflow – steps between the order from the doc to the specimen being drawn, sent to the lab, etc. – Lloyd will email the document to the workflow list serv – and request review of the workflow session and will take this up on the workflow calls Mondays and **Wednesday – starting Wednesday 9/28 or talk about this 10/3
  • Aim to deal with comments regarding renaming first, before re-organization of the pages in the spec
• [5]
  • Definition patterns in clinical decision resource space has more metadata elements that are common across all definitions – to be added to the pattern
  • there are some ballot comments on the CDS for metadata alignment – might want to do that first before applying to logical model

usage context has several specific context types – use it instead of the coverage and topic elements in the base elements – in CDS the reason for this:

• • • originally we had type as codeable concept – clinical venue = codeable concept and these associated codes need to b categorized, so the coding sysem would need to be able to do that and folks will have to maintain that hierarchy, if supported – so we wanted
    • then was split out into coverage and topic in order to make AND and OR statements
    • in usage context each element is 0..* - so you can mix and match expressions with multiple groupings (based on this gender and this age group and clinical focus OR a different age group and race etc. to support stratification) – if you remove this, then you have to have that mechanism in the terminology used
  • This will need further discussion – in principle it makes sense to align the metadata for knowledge artifacts

Wed Q1 (DAF Reconciliation)

Chair: Josh Mandel

Attendance sheet: [6]

Issues discussed / resolved:

• 11945
• 11965
• 11946
• 11949
• 11950
• 11951
• 11952

Wed Q3 - DAF Reconciliation

Chair: Josh Mandel

Attendance sheet: [7]

David Pyke presented a PSS for a Health Standards Integration project to bring IHE IGs to HL7. This was sponsored last year by FHIR-I, but didn't get done because TSC determined that HSI couldn't sponsor a project. Now HSI is hoping this will change soon, with positive input from leadership that this change is likely.

Motion: David Pyke/Keith Boone: 13-0-1

Discussed and resolved:

• 12050
• 12140

Discussed multiple bindings: 9195

Agenda Item 1

Goes here