Skip to end of metadata
Go to start of metadata

Attendance

Feb 2020 WGM PCWG Attendance

Agenda

Day

DateTime
Room/SizeEventHostJoiningChairScribeNotes
TuesdayFeb 4AM

Q1

Room: Exhibition 3.9

10

PC Admin

PCN/AMichelle/JayMichael


Q2

Room: Exhibition 3.9

20IPS - Block votes (Rob Hausam)PCEHRMichaelEmma
PM

Q3

Room: Exhibition 3.9


Mega Report OutEHRAccepted:  PCNA
Stephen/Emma

Q4A

Room: Convention 3.3


FHIR Workflow

Other FHIR Topics

FHIR-IAccepted: PCNAMichelle/Stephen

Q4B

Room: Exhibition 3.3


Medication ListPharmPC


DayDateTime
RoomEventHostJoiningChairScribeNotes
WednesdayFeb 5AM

Q1

Room: Exhibition 3.3

20CIMIPC

Accepted:  CIMI, ED, LHS

Jay

Q2

Room: Exhibition 3.3

40

Grahame - International Patient Access FHIR Implementation Guide

FHIR Trackers

PC
MichelleMichelle
PM

Q3

Room: Exhibition 3.8

30Child health project reportingPC
StephenMichael

Q4

Room: Convention 3.2

40

PC/Vocab/CQI

Negatives (formally known as Negation) ballot

Review and approval vote of Edits to DEQM PSS for Gaps in Care (CDS is a co-sponsor) - Viet, Bryn or Floyd (CQI is primary)

PC

Accepted:  Vocab, CIMI, OO, CQI


Declined:  SD


JayEmma
DayDateTime
RoomEventHostJoiningChairScribeNotes
ThursdayFeb 6AM

Q1

Room: Exhibition 3.9


PA/PCPAAccepted: PCNAMichelle/Stephen

Q2A

Room: Exhibition 3.9


PA/PCPAAccepted: PC
Michelle/Stephen
Q2B
IPSEHRPC (Rob H?)NAMichael Tan
PM

Q3

Room: Convention 3.2

30FHIR TrackersPC



Q3

Room: Exhibition 5.8


OO hosted:  OO owned FHIR resource review. Observation-Media-DocumentReference-DiagnosticReport-CompositionOOAccepted:  PCNAMichelle/Stephen

Q4

Room: Convention 3.3

30AdverseEventPCAccepted: BRRMichelleMichelle
DayDateTime
RoomEventHostJoiningChairScribeNotes
FridayFeb 7AM

Q1

Room: Convention 3.3

40

CarePlan report out (Updates)

  • CarePlan DAM 2.0 (Stephen Chu)
  • eCarePlan (Emma Jones)
  • Child Health? (Stephen Chu)
  • Advance Care Care Plan (Lisa Nelson)
  • Gravity Project (Lisa Nelson)
  • Care Team DAM (Russell Leftwich)
PC

Accepted:  Pharm, CIC, ED, LHS

Declined:  CBCC (not at WGM), SD

StephenEmma

Q2

Room: Exhibition 3.3

30

SD

Cross-WG template review

SDoH / Gravity?

PC

Accepted:  SD, Security

StephenEmma
Lunch10Patient Care Co-Chair Next WGM PlanningPC
MichelleEmma
PM

Q3

Room: Convention 3.3

30IPS ballotsPC
StephenEmma

Q4

Room: Convention 3.5


CareTeam DAM Ballot Preparation

LHSAccepted: PCNAEmma

Minutes

Tues Q1

Russ, Michael T, Jay, Michelle, Emma, Stephen; Karen, Nichol

Several Australian stakeholders are attending a paid tutorial FQ3. We will move the child care quarter from Fri to Wed Q3.

FHRI Trackers topic may move to FQ3 or may not, per Michelle.

Attendance link added to agenda page.

Request for time slot for edits to DEQM PSS. Add to Wed Q4; with F3 backup time; send invitation to Viet, Bryn, & Floyd. Accepted for Wednesday.

M Q4 FHIR-I workflow meeting has been cancelled.

Tues Q2


IPS - Block votes (Rob Hausam)

Ballot not pre-applied

JIRA: 25012; 25006; 25005; 25002; 2500; 24999; 23932; 23931; 23911 (Rob will send link)

These items were the ones needing further discussion. 

23903 - was non-persuasive because the comment was to keep the reference
Vote: motion to block vote on the block - Rob Hausam

Second: Georgio Cangioli

Abstain: 0; Against:0; For:13


Ballot Pre-Applied

Ballot comments pre-applied (persuasive and persuasive with mod; not persuasive with mod)

JIRA: 25018; 25011; 25010; 25009; 25008; 25007; 25004; 25003; 25001; 23957; 23974 (Rob will send link)


Vote: motion to block vote on the block - Rob Hausam

Second: Alexander 

Abstain: 1; Against:0; For:12


No ballot and Specification

Suggestion to prioritize comments from non-IPS members. 

23740 - allows ability to include additional codes for condition.category.

Discussion: Adopted the same as US core slice with fixed value. Withdrawn from the block and need further investigation

Error publishing messages - some are due to the tooling. Can suppress the output to be able to get to the real errors. These publishing errors were suppressed. 

Using the dataType profile to achieve the same results as US Core use of UCUM

Rob Moved

Second: Alexander 

Abstain: 0; Against:0; For:12


Unresolved items

HumanName and Address

patient.name - Includes humanName.text as required to allow the receiver to see how the name is composed. Allowing for at least two parts of the structured name.

IPS understand the reason for the request bust should not be a required element. 

Per Grahame, there is no reliable way to ensure the name is present unless there is a required text for the name. See this zulip chat

Need alignment with CDA for when CDA to FHIR conversions. 

This is not required in CDA - Grahame is going to make the proposal to make it required in CDA. 

Next steps - Question of should there be text and given/family names. Should text be mandatory? 

Next discussion on this is topic is with EHR. IPS would like another quarter with PC to continue the voting. 


Tues Q3

EHR WG - mega report - 12 attendees 

Stephen provided PCWG updates to EHRWG

HL7-WGM-Sydney-PCWG-updates_2020-02_v1.1_final.pdf

OO meeting

Michelle provided notes:

The OO chair (Lorraine) couldn’t speak to the status, so she said it would be covered as part of either Wed Q2 (more in depth) and Thurs Q2 (more of a summary)

OO Project Page has a Healthcare Product, which has a PPT attached with some of the working notes.

https://confluence.hl7.org/download/attachments/40739984/HealthCareProduct%20Landscape.pptx?api=v2

Tues Q4

Wed Q1

  • CIMI update:
    • CIMI issues: Because of the use of SNOMED it has to be labelled as US realm. This does not make sense in the eyes of CIMI. Would make more sense to call it the SNOMED realm. Topic to be discussed with the FMG.
    • Reference sets are created and included in the extension, because there is no central repository available. This will be an important issue to solve, because the amount of valuesets to be mainained will be great. More agility is required.
    • Wound Gradation: Different wounds are staged differently.
    • Wound qualitative amount special terms introduced.
    • How do you want to model? Qualifiers are currently now in extensions.
    • Stephen suggests to move them into Observations.
    • Conditions differ from observations in the sense that it does not have components.
    • Susan Matney presents a powerpoint slide about modelling, the process and Simpel.
    • Mark: the logical part from CIMI was too difficult for them. The step between modelling, IG and FHIR resources was not easy. They are using FHIR shorthand, which does not start from modelling.
    • Skin wound risk assessment (2010) is using LOINC and SNOMED coding. FMG would like verification of the model in a FHIR connectathon.
    • Discussion:
    • Stan wants Observation to be contained within the Condition so that you do not have to step over to Observation. Mark notes that the backbone element in Observations should allow recursiveness.       That would mean qualifier in qualifier.We do not want a reference. We want to be recursive.
    • Motion: Stephen Chu: Submit a Change Request to add a qualifier back bone element in Condition resource using a structure similar to Observation.component.   Susan seconds the motion.
    • Vote: 7 in favor of the motion. 0 abstentions, 0 against.
    • Action item: Stephen submits the change request in Jira and notify Michelle.
  • Vital Signs is being expanded. Vital Signs are observations
  • DisPrecondition; Temporal period something has happened before a certain event and could affect the measurement of the vital signs.
  • Action Item: Susan Matney to ask Michelle Miller to put the topic of Precondition in a conference call.


Wed Q2

Agenda Items

  • Patient Care Resource Review
    • Maturity levels of resources that could go normative
      • AllergyIntolerance 3
        • Implementations in 
          • Germany - Stefan
          • Netherlands - Alexander Henket - STU3
          • UK - David Barnet - STU 3, moving to R4
      • Condition 3 - Normative
        • UK - David Barnet
        • Germany
        • Netherlands
        • Noted by Stephen Chu - Trackers will be entered by CIMI for qualifier backbone elements
      • Procedure 3 - - Normative
        • Germany
        • Netherlands
      • CareTeam 3- Normative
        • UK - being implemented as part of Child Health - - David Barnet
        • Noted by Stephen Chu - Care team DAM may solicit some feedback
    • Per Grahame
      • Have the following procedural options
        •  can still take the resources and update with the changes.
        • can take the resource and hold off taking the added part normative.  
    • FamilyMemberHistory 2 → 3

Genomics groups using this resource - Michelle will reach out to them


CarePlan 2 → 3
Goal 2 → 3
Communication 2 → 3
CommunicationRequest 2 → 3
AdverseEvent 0 → 1?
ClinicalImpression 0 → 1
Linkage 0 → 1
Flag 1 → 3


R5 Timeline

May push for a draft ballot in the May cycle

Reasons for getting R5 moving forward

  • Subscription work by the EHR vendors
  • Work around care guidelines, planDefinition, activityDefinitions from Patient Care
  • Medication knowledge

International Patient Access - Grahame

Patient using an App can access information about the patient from a clinical record systems

In the US - US Core regulations

A lot of countries are approaching companies to bring this capability to their countries. 

Plan is to take US Core and take away all the US specific parts. Will be left with the International parts. Log in and can get to the same resources and search for the same information. 

Each country can sign up and use their own variances. 

The platform remains international. Each country can have their own set of rules. 

Affiliates can do their own or can ban together - e.g. Australia and New Zealand. 

IPA will be consistent with US core. If implemented US Core will automatically be conformant to IPA. 

On the other hand have learned 

  1. accessing data for a patient and find that the patient record have been merged with another patient record - what happens? Have added rules on how to handle this. This is specific to IPA.
  2. What about IPS? A set of content agreements on how to share data. IPA does not have many content agreements. IPS content accessed thru IPA is better. 
  3. Will produce a version of IPA that is bound to IPS. Used by countries that don't have national content standard can conform to the IPS standard. 
  4. Overview
    1. Artifact maps to US core - search parameters, conditions, must support with less stringent content rules. 
    2. If using IPS for a document will get back an IPS document. 
  5. Not clear who owns this project. IPS is owned by patient care. It's friends with IPS and in the same space with IPS. 
  6. Have both Medication Usage and Prescription
  7. Patient - can have one patient in context but may have multiple patient records. Patient have to have a name - in discussion with IPS about nameText. 

Questions:

What does it mean to adopt these profiles on the national level? 

IPA is about the access. No profiles will inherit from the IPA profile. Will use profile comparison tools. 

IPA is the simpliest; IPS as you agreed to; then your own business agreements in your systems. 

Most countries will have something like US Core. 

From a programming comparison, IPA is like an interface. 

IPA is a statement about how access is done and you provide the content to meet the rules. 

The hardest part would be the terminology aspects - not just applicable to IPA. 

Where would PC provide input? 

Take condition.category - will have contention. 

If international and the category is nailed down, will it not be pushed in the base spec?

Can be if we can nail down category. 

How will we navigate the FHIR versions? 

Technically it's R4. Strong interest in making it R4 base from implementers. 

Work groups

PA would be Interested party (for patient merge)

FHIR-I would be interested party

Patient Interest Work Group would be interested party

Patient Care would be the primary owner - Grahame will continue to be involved directly. Driven by Apple as primary interest in a formal specification. 

Human Name Issue - Grahame

FHIR-24932 - Getting issue details... STATUS

name have various parts

  • given
  • family
  • text 

Text is important 

WC3 recommendations  - don't need to collect name parts. 

There are a few countries that have name parts not called given or family but want it to appear in the text. 

CDA have a specified order provided by the author that need to go in the name text. 

In some counties the name order is presented based on the language being used. When writing international software have to take this into considerations. Populate the parts and also have a presented version of the name. 

Intention was not to do either/or. 

Tricky when don't know how to assign the parts. 

Have to have text and parts or text or parts. want to push people to have the part. Would never parse the text but will have the text to present. 

use should and must support and also that patient name without name parts are difficult to process. 

For IPA, this would be a requirement that is not in US Core - would be a requirement in IPA and IPS. Would need to know how US Core will deal with it. 

IPA decision is related to US Core. 

Staging human name.text is highly encouraged and leave the existing implementation in place. Might make it required in future versions. 

Vote

Grahame moved that IPS humanName.text be must support;  have narrative explaining the importance of humanName.text and make note that it must come in future version. 

Addendum to the motion  - make a comment about the importance of address.text

Rob second

No further comments/questions

Abstain 3; Against 0; For 14


Tracker backlog - deferred. 


Wed Q3

Presentations from Australia, the Netherlands, USA and UK NHS - child health record initiatives/projects

Australian presentation:

Child Health Project Overview-Australia_Feb 2020 HL7 Australia.pdf

The Netherlands and USA presentations:

PCWG_Child-Health-Records_2020-02-05_Q3_HL7-PCWG.pdf

Verbal presentation on child health records - NHS


Next step: HL7 Australia project to reach out to HL7 International PCWG for exchange of ideas and support.


Wed Q4

Negatives

Ballot Resolutions

CommentsDiscussionResolutionVote
17Using modal verb pair

Not persuasive with mod


Emma Motion: so moved for comment 17

Michael Second 

Abstain: 10

Against: 0

For: 14

34

Procedure not to be done

 - Procedure with Consent not given

Will table for now 

  • Discussion needed after the document is read. 

Deferred

68Examples need referencespersuasive with Mod

Michael moved

Emma Second

Abstain: 3

Oppose: 0

For:12

73Skipped
Deferred
86Skipped
Deferred
87Already combining 4&5 so section 6 will change. non persuasive

Michael moved

Emma Second

Abstain: 3

Oppose: 0

For:12

105agreement with the resolutionNot persuasive

Michael moved

Emma Second

Abstain: 3

Oppose: 0

For:12

109Skipped
Deferred




PSS - DeQM

Review and approval vote of Edits to DEQM PSS for Gaps in Care

Want to expand the scope of DeQM to include what is needed by DaVinci

Seeking co-sponsorship approval

Gaps-in-care - identification of issues that might impact patient's care negatively. represents a potential or mis-opportunity. 

Prospective approach rather than retrospective. gaps in care is like a Decision support

Considering it as extensions in the DeQM IG 

Bryn Rhodes  move to approve the extensions to the DEQM PSS for Gaps in Care

Stan Huff second the motion

Abstain: 0

Oppose: 0

For:23


CQI Trackers

FHIR-24014 - Getting issue details... STATUS

PA owns the encounter resource and not present - Deferred

FHIR-22786 - Getting issue details... STATUS

Already resolved. Per discussion - 

Value set owned by FHIR-I - not present

OO owns the serviceRequest resource - not present

JIRA need to be logged to OO about the valueset binding. 

Per Stan - OO decided that elective was not a priority. That part was resolved. The unresolved part was if there should be alignment of the value set with binding. 

Bryn - trying to establish pattern against the clinical data coming out of FHIR systems. 

CQI will take the action to create a JIRA to OO and Vocab (not patient care). 

Thurs Q1 - Patient Care to PA

Thurs Q2 - Patient Care to PA

Thurs Q3

Thurs Q4

Update on AdverseEvent profiles

  • Hugh has mechanics for a clinical research profile
  • BRR will resume reviewing definitions and propose specialization of the definitions to clarify for the clinical research profile
  • If any definitions truly fork off, then raise that as an issue against the base specification
  • Resume profile-related discussions on Thurs, Feb 27

Follow-ups from 2020-01-02 Patient Care FHIR Conference Call

Ran out of time and didn't discuss

  • seriousness
    • similar to criticality, except the event has occurred
    • criticality has low, high, unable-to-access
    • seriousness includes both physical harm as well as financial consequences
    • TO DO: value set in base resource
      • add unable-to-assess to value set with definition "Unable to access whether the event is considered to have the potential for persistent or costly injury or consequence."
        • Daniel said that Epic allows <blank> (not finished assessment), yes (serious), or no (no threshold for action), but doesn't have an explicit unable-to-access
        • George said that Allscripts allows selection of mild, moderate, severe or leave blank.  Client could customize to add other options, such as unable to assess.
        • If you can't access seriousness, is there value in documenting unable-to-access?
        • If <blank>, then assessment is uncertain whereas an explicit unable-to-access implies an interaction occurred, but conclusion was unable-to-access. 
    • TO DO:  definition in base resource
      • references clinical importance, but value set has costly / financial consequences, so definition needs to be updated to include other types of consequences (such as financial).
  • recorder
    • TO DO:  Should Device be added?  For example, Daniel said that their system does have devices (EMR) record near misses from bar code scanning (scanned wrong med / wrong patient).  

Follow-ups from 2020-01-16 Patient Care FHIR Conference Call

  • Consider whether AdverseEvent boundaries should include forms - mandatory reporting forms in scope of AdverseEvent vs intake forms before it is deemed to be an AdverseEvent.  Review a few forms in Europe, US, and Australia.   


Fri Q1

Care Plan Domain Analysis Model - progress and work-in-progress

HL7-WGM-Sydney-FridayQ1-CarePlan-v1.0-Final_2020-02-07.pdf


Care Plan DAM 2.0

Overview - Stephen Chu

Feedback for improvement

  • How does Assessment, SDoH, patient preferences, gaps in care, advance directives fit in the CP DAM
  • Have completed SDoH, Assessment
  • In-progress - orderset, care coordination, gaps-in-care

Assessment

  • Overview of the assessment and evaluation in the cycle of care planning and care

SDoH

  • Overview - identification of positive and negative factors with high level of SDoH factors and how they are input into the Care Plan design

Gaps in Care

  • Overview of how the care plan can identify gaps in care - anticipated (prospective) and actual (reactive) gaps

Care Activities - order sets and orders

  • Development in progress

Care Coordination

  • Pulling together the planning aspects
  • Discussion
    • Ken Ruben- HSPC/LogicHealth (Deliverable - IG)  - BPMN workshop - Looking at various pieces and how it fits together. Scope is looking at the care coordination, care management space from a PAN SDO. Conncethathon work has done specifically around FHIR. PAN is more than only FHIR. 
    • Lisa Nelson - Gravity is doing similar work
    • Russ - few concerns that DAM is grouping things together that aren't the same class. SDoH from the modeling perspective is not in the same class, same with gaps in care. Should not be treated all of these the same way. Same with care coordination 
    • Lisa Nelson - The DAM should flushes out what the variances are in things. How is the DAM helping adopt commonly definition of terms?
    • Jay Lyle - Gaps in care are logically all observations, what's different? The difference is how they are treated. What the different processes are. Question is if there is a box in the DAM, there is a reason the box was drawn based on clinical or business reasons. 
    • Lisa Nelson - these are similar to how Health Concern and Problem concern. Can we agree on when something rises to a level of concern it becomes a problem concern. Russ disagrees. 
    • Ken Rubin - sometimes it's difficult to get to understand where the pieces touch and getting clarity around the relationships between the boxes. There is value in the DAM even if there aren't full clarity of the boxes. 
  • MCC eCARE Plan - overview
  • Essential Information for Children with special healthcare Needs - FHIR IG
    • Engaged folks from Australia, netherlands, and Patient Care (Stephen will be their conduit)

IHE - Plug-a-thon in Brussels Next month


Gravity Project - Lisa Nelson

Overview

  • Gravity focus is around identifying data in a coded way. 
  • 3 domains - food security, housing and instability, 
  • Broadly defined use cases
    • First use case is documenting SDoH during the patient encounter
    • Second use case is the tracking for referrals
    • Third use case is aggregating the data for PH or research
  • Aiming for Sept 2020 ballot
  • Need a dedicated review session - will be ready to go to ballot in June. 
  • Have 800 registered participants - SMEs contributing to represent historical definitions
  • Community members can submit data elements
  • Framework for collecting this data grounded in the CP DAM
  • Food security data concepts overview - collections of coded concepts that work together. 
    • Differentiation in screening kinds of the questions 
  • Clinical finding is a judgement

Discussion

  • Russ - suggest calling the it health concern instead of a disgnosis
  • Jay - being able to represent the clinical process in a DAM
  • Lisa - there is not a DAM specific to SDoH. Following what is already in the DAM. 
  • Stephen - Need to align this work with the SDoH work. 

Personal Advance Care Plan

  • Uses the same approach to an agreed upon clinical findings

Survey Question to the Group

Referencing Care Team and Care Plan in FHIR 

  • Change request to have the CareTeam reference the carePlan - found non-persuasive. 
  • Request has challenge the disposition
  • How disruptive would it be to take the reference to CareTeam out of CarePlan
  • Russ - logic for doing this does not seem sound
  • 2 questions to answer - what is the clinical workflow? and what constitute the care team?
  • Suggestion to take this question to the Wed carePlan calls on Wed 5:00pm EST

Fri Q2 and Cont into Q3

Provenance Question

Michelle Miller: Where there is an author that is a device and have a corresponding organization. When mapping to CDA to FHIR, there is a who and an agent. Device have an owner org. 

John Moerke: Could have four agents each with their won agents and not use the on-behalf. If the device is the who and the organization is the authority that gives the device the ability to inherit something. there is not a specific way to go. Could pick a way. Have not seen much use of on-behalf of. 

Discussion:

May need to get rid of agent.onBehalOf. 

Michelle submitted this  JIRA J#25934

Collaborative Template Review Process Project (CDA Management)

Clinical Status (Lisa Nelson)

  • Problem Status
  • Allergy Status


Working with PC has gone well. 

Working with FM has not gone as well because they don't have the bandwidth with their Davinci work.

Working with pharmacy has not gone no where. 


Have been looking at how CCDA compares to IPS and finding major differences

Alignment Framework - IPS is more of a sibling of CCDA. 

Found structural differences and Vocabulary differences

How do we move forward with ensuring IPS is alligned? 

Maybe people were vision-izing something different. Or people are thinking about the same thing under different contexts or in a different way.

Rob Hausam - IPS update

Getting ready to have the FHIR IPS IG published. Have been talking to ONC because of their interest in updating the CDA version that have been published. IPS has an open ballot issue that need to be voted on. 

J#23740 - Condition.category should not be fixed to a particular code. 

Explanation of the need to slice codition.category to include proble-list-item. With the slicing can add other categories. 

IPS is representing information that need to communicate to another care settings. 

This decision merits that things that may be of interest to US realm may not be relevant to IPS.

Rob Hausam: Move to approve resolution as stated in tracker

Jay Lyle - second

Further Discussion: Lisa

Deferred voting until next quarter. 

The notion of categorization in condition is analogous to section categories rather than the problemType as used in CCDA (lisa hypothesis)

IPS chose the LOINC code for problem 75326-9

11450-4 is the LOINC code for problem list

IPS is limiting the problems to only problem list problems. US core supports problem list problems, health concerns, encounter diagnosis

Rob motion/propose removing the slice. Use the base standard value set and cardinality (0..*). Make condition.category must support.

Suggestion made to be clear by what is meant by must support (must preserve it and display to users)

Lisa second. No further discussion. Vote: abstain 1; oppose 0; For 8. 


Fri Q4