FHIR Workflow Minutes WGM 201705

FHIR Workflow Conference Call 3:00PM Eastern Time (Date above)

Return to FHIR Workflow Minutes

Monday Q4

Attendees

• Lloyd McKenzie - Chair
• Riki Merrick - Scribe

For full attendees, see The Google sign-up sheet

Agenda Item 1

• Workflow has published version 4 of their scenarios - improve publishing mechanism for scenarios, that did not make it into publication – ideally for all the different domains, so we have enough examples

Patterns

• Have reviewed the patterns – looking to discuss the biggest change with PC this week – referencing practitioner and other actors linkage (need to have the roles represent the organization for the practitioner (since now cardinality it 0..*) – so we now include the role and represented organization along with the reference to the practitioner – so could we rather create a linkage to practitioner role and point to that
• Is the same pattern applied to care team? All the resources that adopt the request event pattern would go to simpler representation of reference
• Care team has specific role for the specific care in question, that will still stay the same
• Care team cannot be used as referenced resource, only the individuals that are part of the care team can do that now
  • Request to revisit this and add it as a candidate author/performer in the patterns
• Medicaid is modeling their information model to provider / practitioner and find roles that don’t quite fit, so they will be coming with requests for changes there, too

Relevant Timelines

• Feedback on existing rules and patterns by end of May 2017 (issues with existing ones, proposals for change)
  • post to workflow listserve or email to Lloyd, and he will forward – bring this back to the WG

OR submit tracker item in gForge

• Candidate set of rules for R4 (including tooling support) will be published by FMG by end of June 2017
• FMG will accept feedback in early July (1st two weeks) and will publish final rules and tool updates by end of July
• After this will adjust the resources – ideally prior to Sep WGM – but prior to Dec deadline for Jan 2018 FHIR draft for comment ballot and then the STU ballot in May 2018 cycle

Product Director’s Priorities

• Patterns: change the W5 framework to a pattern (logical model), tie the patterns to ontology, and use of patterns to drive more consistency (and how to do this without decreasing quality)
• W5 framework is webpage with columns of meta data and the data elements needed for audit and provenance perspective and W5 is then mapped to audit event and provenance resources – this should also take into account if part of 80% rule
• Logical model looks like a resource, but we map to and from it – have model for request, event, definition = common patterns
• Mapped the same resources at the same time to W5 framework
• Now take the W5 structure and apply what we did for request, event and definition – once that has been done, that will automatically map the resource elements to the audit and provenance resources
• When reviewing a resource, that should make it more clear what is the WHO / WHAT / WHY / WHEN etc.
• Plans for other resources, like person, place thing? May be into catalog? For those entities that are catalog-able, that might apply, but there are also things that you can catalog that are not entities – no one has asked for entity resource
• Some WG interpreted the patterns as NEW RULES instead of just evaluating – in FHIR business need trumps pattern – reflect 8-% of need in the resource, pattern alignment was meant to help identify items that have different names and don’t need to, or have to change names, because what the business process requires as goal is to have intuitive names

Pattern issues/changes

• Sharing the request pattern page – http://hl7.org/fhir/request.html
• Feedback: felt forced to consider calling observation/condition an event; what would we do with things we have currently defined that does not fit this (relationship to other resources and how they fit with the reference model is taken into account) – definitely applies to observation, but for condition may not always be that (in theory someone requested evaluation, where condition is the outcome of that evaluation).
• Allergy/intolerance, have event like aspect, but stand time (encounter can do that, too, so just long duration does not make it not an event).
• Task is the bridge between the request and the event pattern, all others are mutually exclusive
• What about patient statements? – is captured using provenance, which is an event – capturing the informer information – not a distinct resource
• Distinction similar to medication administration vs medication statement;
• You have a plan where events have occurred based on the plan (request pattern) – each event that occurs based on the plan are events: the plan defines the desire of what is supposed to happen (request) – what happened is the reports of events
• Activity of the referral event - how does the completion of the activity feed back into the care plan? The completed event is captured as the procedure that happened.

Publishing workflow scenarios

• Lloyd showed a hand-written web-page showing an example of how the Comprehensive metabolic panel might be rendered
• Derived XML schema to capture actors, business objects, versioning of these items in the workflow, what steps, who does what => render workflow
• Diagram hover over step can click to detail step descriptions / business objects
• How to capture the variations of the steps – example CPOE may be in EHR-S rather than in the lab system? This is a specific example
• Create a page how to read each of the scenario pages – can then include hyperlink to the intro section, that explains that this is ONE way and not a definition – this is guidance
• Pure messaging approach vs pure service approach
• At national level or in implementation guide can create a definition that ALL should use in this instance.
• IG defines rules around the handling of the workflow for ALL instances (schema) – this is example of a specific instance using a specific solution; value of this is that it makes it more clear when presenting how specification works in real life.
• Change name from workflow to walk-through for these scenarios and make clear these are NOT prescriptive – need IG for that.
• Will we integrate this with the resources in the build and help with validation? Goal is for these examples to be part of the FHIR specification.
• Include view on how the resources used in the examples will be helpful to show folks how one instance of a request can result in a multitude of individual procedure requests – potentially need tabs for each stage of the walk-through – for now is just the end stage of the resources generated – but may add in key stages in the long term – see clinfhir.com and have videos on blog, too
• Looking for examples that are clinically relevant, so would like to create tooling (templated spreadsheets may be) to recruit more people to produce the instance data – looking for ideas here
• Create examples of mixed and matched resource combinations.
• Graft definition allows collection of interrelated resources – their relationships and references; instantiate grafts in messaging, care plans, documents, diagnostic reports, query – will apply rendering capability to those

Pattern Alignment Reports

• These will come out soon for WG review – consider is divergence needed to support business practice or not – then will compare across different WGs where alignment is off and no documentation about reasons why
• Doing quality rules out of MnM and pattern alignment from FHIR-I

Admin

Will stick with 1 quarter for next WGM focusing on discussion of the variation between resource alignment – same Timeslot – FHIR-I hosting