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

Difference between revisions of "2018-05-14 PA WGM Minutes"

From HL7Wiki
Jump to navigation Jump to search
m
 
(10 intermediate revisions by the same user not shown)
Line 96: Line 96:
 
'''Agenda Topics''' <br/>
 
'''Agenda Topics''' <br/>
 
<!-- ***** Delete instructions and fill in agenda items ON NEXT LINES  ****-->
 
<!-- ***** Delete instructions and fill in agenda items ON NEXT LINES  ****-->
−
Welcome/introductions<br/>
+
Welcome and introductions  
−
* Approve agenda<br/>
+
Joint meeting with Financial Management - FHIR
−
* Review PA mission & charter <br/>
+
<br/>
−
* Review PA decision making practice<br/>
+
* HL7 Plenary
−
* Review PA 3-year work plan<br/>
 
−
* Review SWOT Analysis<br/>
 
 
'''Supporting Documents'''<br/>
 
'''Supporting Documents'''<br/>
 
<!-- *****  Delete instructions and add document names/links ON NEXT LINES *****-->
 
<!-- *****  Delete instructions and add document names/links ON NEXT LINES *****-->
−
* [http://www.hl7.org/Special/committees/pafm/overview.cfm PA mission & charter]<br/>
+
<br/>
−
* [http://www.hl7.org/documentcenter/public/wg/pafm/2014-09_PA_DMPv4.docx PA decision making practice]
+
===Minutes===
−
* [http://www.hl7.org/documentcenter/public/wg/pafm/2018-09-11_PA_WGM_Work_Plan2018-2019.xlsx PA 3-year work plan]<br/>
 
−
* [[http://www.hl7.org/documentcenter/public/wg/pafm/2018-09-11%20PA%20SWOT.docx SWOT]<br/> ===Minutes===
 
 
<!---================================================================
 
<!---================================================================
 
|                                                                  |
 
|                                                                  |
Line 118: Line 114:
 
=================================================================--->
 
=================================================================--->
 
<!-- **** Delete instructions  and fill in minutes ON NEXT LINES  ******-->
 
<!-- **** Delete instructions  and fill in minutes ON NEXT LINES  ******-->
−
'''Minutes/Conclusions Reached:'''<br/>
+
HL7 Plenery
−
Introductions<br/>
+
 
−
Hans attended this session and asked for a few minutes of this quarter to discuss v2 items to be included into v2.9, as publishing has opened up the publication for substantive changes. Specifically, he wanted to discuss proposals 716 and 857. <br/>
 
−
<br/>
 
−
Proposal 857 covers incorrect table reference in the example for PV1-4 and change of fields NK1-40 and NK1-41 as repeatable for backwards compatibility. <br/>
 
−
Motion to accept Proposal 857 made by Hans, seconded by Alex. <br/>
 
−
Discussion: These should be simple changes to chapter 3. <br/>
 
−
Vote: 6/0/2<br/>
 
−
<br/>
 
−
Proposal 716 concerns inclusion of the PRT segment to optionally associate a person or an organization without a specific person identified.  This proposal outlines adding the PRT segment under both the AUT and RF1 segments to indicate who the person or organization is who is athorized or being referred to. This will also require addition of 4 new values in Table 0912 (Participation). <br/>
 
−
After discussion the group felt the need to update the ROL segment with the new PRT segment and start the deprecation process. <br/>
 
−
Hans moves to accept proposal 716 with the friendly amendment to also replace ROL where found in chapter 3, 8, and 11 with the PRT segment for next ballot round in May. Second by Alex. <br/>
 
−
Discussion: Hans will check with Frank Oemig and InM on how to include the PRT segment in the OBR when choices of following segments are involved. <br/>
 
−
Action: Need to follow up with who is editing for Chapter 11. <br/>
 
−
Vote: 6/0/4<br/>
 
−
<br/>
 
−
The WG reviewed the agenda for the week. <br/>
 
−
Moved Brian /Irma Approve Agenda<br/>
 
−
Vote: 9/0/0<br/>
 
−
The group reviewed the Mission and charter. All seems well with this<br/>
 
−
<br/>
 
−
THe group then reviewed the Decision Making Practices (DMP). The Line and Brian noted that HL7 has now changed the requirements for the DMP. Now HL7 Headquarters will provide a base, or default, DMP. If the group has something that adds or differs from the default, then the Work Group will provide an addendum. The group then reviewed and compared the default requirements in the DMP against what we currently have. Focus was especially on, quorum, and evoting.<br/>
 
−
<br/>
 
−
Motion: A motion for was made by Brian to accept the default DPM, Drew seconded.
 
−
Discussion: None<br/>
 
−
Vote: 9/0/0 <br/>
 
−
<br/>
 
−
Action: Line will send an email to the Steering Division that we accept the default DMP.<br/>
 
−
<br/>
 
−
The WG continued with the review of the 3 year work plan. The WG discovered that a new PSS needs to be created based on the last one for project 1102. The next one will define FHIR resources being normative and defining those.
 
−
Action Item: Alex to create a base FHIR PSS using the latest PSS template and the base information for the PSS for project 1102. <br/>
 
−
<br/>
 
−
Action Item: For the new resources Brian will coordinate the creation of new resource proposals.<br/>
 
−
<br/>
 
−
The WG discussed some of the upcoming resources. Some are in the domain of Financial Management. Irma commented that the work we do to create/enhance FM resources might take away from the resources within Patient Administration domain. The concerns are around people to update, the scope, and the differences in thought processes around resources in which both FM and PA have a stake.  This still leaves open the question of who does the work. This will still need to be discussed.  Brian also noted that Paul Knapp (co chair of FM) suggested that any joint sessions be done earlier in the WGM week so that joint subjects can be discussed before decisions are made within the meeting. <br/>
 
−
<br/>
 
−
SWOT was reviewed by the group. It is approved by the group.<br/>
 
−
<br/>
 
−
The WG then proceeded to discuss participation, telecons and efficiently doing the PA work.  THe group discussed perhaps using Zulip for many of the discussions and using telecons for contentionous or subjects that need the PA brain trust. This might allow for reduction of frequency of calls. THe WG decided to keep it on Tuesdays.<br/>
 
−
<br/>
 
−
Action: Brian will arrange for a Zulip channel.<br/>
 
−
<br/>
 
 
===Meeting Outcomes===
 
===Meeting Outcomes===
 
{|border="1" cellpadding="2" cellspacing="0"  
 
{|border="1" cellpadding="2" cellspacing="0"  
Line 204: Line 160:
 
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''HL7 Patient Administration Meeting Minutes''' <br/>
 
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''HL7 Patient Administration Meeting Minutes''' <br/>
 
<!-- ********  CHANGE conf call details or meeting room ON NEXT LINE*****-->
 
<!-- ********  CHANGE conf call details or meeting room ON NEXT LINE*****-->
−
'''Location: Hilton New Orleans Riverside, Durham Conference Room '''
+
'''Location: Hotel Maritim, Cologne, Germany, Salon 20 Fulda'''
 
<!-- ********  CHANGE Date and Time  ON NEXT LINE  **********************-->
 
<!-- ********  CHANGE Date and Time  ON NEXT LINE  **********************-->
−
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''Date: 2018-01-29'''<br/> '''Time: Monday Q2'''
+
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''Date: 2018-05-14'''<br/> '''Time: Monday Q2'''
 
|-
 
|-
 
<!-- ********  CHANGE chair and scribe ON NEXT LINES  *******************-->
 
<!-- ********  CHANGE chair and scribe ON NEXT LINES  *******************-->
Line 275: Line 231:
 
'''Agenda Topics''' <br/>
 
'''Agenda Topics''' <br/>
 
<!-- ***** Delete instructions and fill in agenda items ON NEXT LINES  ****-->
 
<!-- ***** Delete instructions and fill in agenda items ON NEXT LINES  ****-->
−
# FHIR New Proposals
+
# Welcome and introductions
−
# Feedback from Connectathon
+
# Joint meeting with Financial Management - FHIR
 +
# Invoice draft review
 +
# ChargeItemDefintion draft review
 +
# ProductPlan review
 +
# Payment/Adjustment resource?
 
'''Supporting Documents'''<br/>
 
'''Supporting Documents'''<br/>
 
<!-- *****  Delete instructions and add document names/links ON NEXT LINES *****-->
 
<!-- *****  Delete instructions and add document names/links ON NEXT LINES *****-->
−
*  
+
*
 +
 
 
===Minutes===
 
===Minutes===
 
<!---================================================================
 
<!---================================================================
Line 294: Line 255:
 
Introductions<br/>
 
Introductions<br/>
 
<br/>
 
<br/>
−
Brian asked if there were any proposals for new resources. <br/>
+
'''Minutes/Conclusions Reached:'''<br/>
 +
Introductions<br/>
 +
Joint session with FM.
 +
The WG began with the review of the Invoice resource.  <br/>
 +
Simone noted that in the last call, the WG was asked to build the invoice looking forward to the approval of this invoice. <br/>
 +
Mary Kay noted that there were no quantities involed.  Simone explained that the invoice is moer like a summary of the charge items. This would require a bundle to be included to actually use this resource. The operation would be a submit of the invoice that would create the bundle of charge items and paitient information. This would require approval by FM. <br/>
 +
http://build.fhir.org/invoice.html<br/>
 +
Irma asked if this should follow the workflow pattern. <br/>
 +
<br/>
 +
Irma moves to accept this resource proposal to move forward., Iryna seconds.<br/>
 +
Discussion: This is to move forward with the proposal.
 +
Vote (for/against/abstain): 12/0/0<br/>
 +
The WG looked generally at the charge item resource to gain approval to move forward with tis as well.<br/><br/>
 +
http://wiki.hl7.org/index.php?title=ChargeItemDefinition_FHIR_Resource_Proposal<br/>
 +
<br/>
 +
The pricing details or catalog also services available. <br/>
 
<br/>
 
<br/>
−
Simone spoke about continuing to define the ChargeItemDefinition resource as a new resource. She believes she can craft a proposal, but it will be very generic. This resource will be the place where the “rules” of how to process the ChargeItem for billing. May be part of the Catalog profile on Composition. <br/>
+
The WG reviewed the elements involved for the context of ChargeItem Definition<br/>
−
Brian asked whether PA should retain “ownership” of this (as we have with ChargeItem) or not.  The group decided it made no sense to separate the two since they essentially cover the same subject. <br/>
+
Patient, Encounter, <br/>
 
<br/>
 
<br/>
−
Invoice resource – Draft created for review this WGM<br/>
+
Simone reviewed some of the relevant elements within the proposed ChargeItemDefnition<br/>
−
ONC/CMS eLTSS Presentation for Thurs Q4 (from Evelyn  This is scheduled for joint meeting Thursday Q4. The WG reviewed the slide presentation sent by Evelyn Gallegos. May need to add EpisodeOfCare. ChargeItemDefinition and HealthcareService may be relevant. <br/>
 
 
<br/>
 
<br/>
−
Connectathon feedback. Brian as our FHIR facilitator reported back that he ran 2 tracks: Patient Match and Provider Directory. There was little participation in both, but EPIC (Cooper) implemented Patient Match. There was one other participant for Provider Directory. Brian noted that even though this other participant built a model for resource relationships and process, they came up with the same as the Australian model. Brian showed the model. <br/>
+
The Instance element was discussed. FM felt that the reference which currently included Medication, Substance and Device can be expanded. <br/>
 
<br/>
 
<br/>
−
Cooper reported back on the Scheduling track for the connectathon. While there were few actual connections, there were many discussions regarding scheduling. One discussion had to do with subscription style scheduling to reduce having to “pull down” entire schedule slots to determine scheduling. Subscription on schedule, then search for slots in update schedule (via operation). So only when changes are done will subscriber receive change. <br/>
+
The joing workgroups had a lively enough discussion on the elements within the ChargeItemDefinition as currently defined to merit moving forward with this proposal. <br/>
 +
There were value statements from Germany, Australia, and US for the use of this resource. Each had some use cases which would be supported by this resource.<br/>
 
<br/>
 
<br/>
−
Alex reported back that Kaiser Permanente is starting to “ramp up” their interest in FHIR. This WGM, Kaiser Permanente participated in the Patient Track, collaborating with QRiva on Saturday to run through the scenarios presented (Register, Read, Update and Delete a patient [CRUD]), then version read a patient and search. On Sunday, the creation of an patient ID as a client, then as a server was tested with QRiva through the HL7-sanctioned Aegis Touchstone FHIR server to validate compliance. All tests passed successfully. <br/>
+
Action: FM noted that there should be a way to indicate related definition. The Example rule is … there are 10 items that can be charged but only one can be charged. This is one thing that needs to be accounted for.
 +
<br/>
 +
MaryKay moves to accept the resource proposal for moving forward. Simone seconds. <br/>
 +
Discussion: None<br/>
 +
Vote: 10/0/1<br/>
 +
<br/>
 +
The WG moved on to review the ProdcutPlan. To be able to have an insurer express their basic product (a set of coverages) and plan where plans are the risk share. For one product, there could be many different ways you can handle risk. This is a structure that allows you to define this.<br/>
 +
http://build.fhir.org/productplan<br/>
 +
This is not doing billing, it’s doing coverage and risk sharing. Structure of the plan. <br/>
 +
<br/>
 +
Location was supposed to change from 0..1 to 0..*.<br/>
 +
<br/>
 +
The FM work group invited any interested parties to review this.<br/>
 +
<br/>
 +
Brian noted that there is another FM joint session on Thursday Q2.
 
<br/>
 
<br/>
 
===Meeting Outcomes===
 
===Meeting Outcomes===
Line 336: Line 326:
 
*.
 
*.
 
|}
 
|}
 +
 
==Monday Q3==
 
==Monday Q3==
 
{|border="1" cellpadding="2" cellspacing="0"  
 
{|border="1" cellpadding="2" cellspacing="0"  
Line 350: Line 341:
 
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''HL7 Patient Administration Meeting Minutes''' <br/>
 
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''HL7 Patient Administration Meeting Minutes''' <br/>
 
<!-- ********  CHANGE conf call details or meeting room ON NEXT LINE*****-->
 
<!-- ********  CHANGE conf call details or meeting room ON NEXT LINE*****-->
−
'''Location: Hilton New Orleans Riverside, Durham Conference Room '''
+
'''Location: Hotel Maritim, Cologne, Germany, Salon 20 Fulda '''
 
<!-- ********  CHANGE Date and Time  ON NEXT LINE  **********************-->
 
<!-- ********  CHANGE Date and Time  ON NEXT LINE  **********************-->
−
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''Date: 2018-01-29'''<br/> '''Time: Monday Q3'''
+
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''Date: 2018-05-14'''<br/> '''Time: Monday Q3'''
 
|-
 
|-
 
<!-- ********  CHANGE chair and scribe ON NEXT LINES  *******************-->
 
<!-- ********  CHANGE chair and scribe ON NEXT LINES  *******************-->
Line 441: Line 432:
 
Introductions<br/>
 
Introductions<br/>
 
<br/>
 
<br/>
−
14866  - Multiple birth order should be a positive integer (not an integer) - 2018-Jan Core #206<br/>
+
Introductions<br/>
−
The WGreviewed the tacker item and considered this reasonable. <br/>
 
−
#14719 - Patient Gender representation is lacking<br/>
 
−
Existing Wording: In addition, to this gender, other kinds of gender may be represented<br/>
 
−
Proposed Wording: Add link to US Core Birth Sex extension, and develop guidance for sending Clinical Gender<br/>
 
−
---
 
−
The current description notes "other types of Patient Gender may be represented but gives no guidance" Add link to US birth Sex extension, Add link to Observation resource or create specific profile. <br/>
 
 
<br/>
 
<br/>
−
The WG was a little confused about the need for this. After discussion, it seems the submitter wanted hyperlinks to Observation. When reviewing the Patient Gender section, it appears all information is clear there. <br/>
+
The WG decided to review the agenda for the week. Included V2.9 ballot reconciliation Thursday Q3. Also included v2.9 proposal 716 included with Patient care joint session.
 +
 
 +
The WG also noted that FHIR ballot reconciliation for Patient should take presendence so changed Monday, Q4 and Tuesday Q1, Q2 and 3, to include 3 ½ quarters to get through .<br/>
 +
Motion was made by Brian to approve the new agenda, seconded by Irma.
 +
Discussion: None
 +
Vote (for/against/abstain): 6/0/0
 
<br/>
 
<br/>
−
In an attempt to clarify, the reference to “Meaningful Use” will be removed. The last sentence in that paragraph will now say “The US realm defines the US specific extension for this for concept,” <br/>
+
Reviewed the mission and charter. No changes.<br/>
−
An example will be created for the clinical Gender and referenced<br/>
 
 
<br/>
 
<br/>
−
The new Gender Identity standard extension will be included in the bulleted items tracker #13843<br/>
+
Work group help. Although there was an email sent that the PAWG would accept the outcome, HL7 headquarters did not record this. Line will follow up with Anne as it was stated that it would be taken care of. Given this, the PAWG shold get a star for 2018 May.<br/>
−
Moved Brian, second Cooper. <br/>
+
The WG reviewed the 3 year work plan. Updated by adding the ChargeItemDefinition. The WG noted that the project ID did not need to change as <br/>
−
Vote: 7/0/2<br/>
 
−
# 14754 - Gender can't drive clinical processes if it's administrative - 2018-Jan Core #91<br/>
 
−
Administrative Gender - the gender that the patient is considered to have for administration and record keeping purposes. <br/>
 
 
<br/>
 
<br/>
−
Needed for identification of the individual, in combination with (at least) name and birth date. Gender of individual drives many clinical processes. <br/>
+
The WG continued to review the SWOT .<br/>
−
<br/>
 
−
The gender might not match the biological sex as determined by genetics, or the individual's preferred identification. Note that for both humans and particularly animals, there are other legitimate possibilities than M and F, though the vast majority of systems and contexts only support M and F. Systems providing decision support or enforcing business rules should ideally do this on the basis of Observations dealing with the specific gender aspect of interest (anatomical, chromosonal, social, etc.) However, because these observations are infrequently recorded, defaulting to the administrative gender is common practice. Where such defaulting occurs, rule enforcement should allow for the variation between administrative and biological, chromosonal and other gender aspects. For example, an alert about a hysterectomy on a male should be handled as a warning or overrideable error, not a "hard" error. <br/>
 
−
Proposed Wording: Requirements <br/>
 
−
Needed for identification of the individual, in combination with (at least) name and birth date. <br/>
 
 
<br/>
 
<br/>
−
Suggest you remove the statement "Gender of individual drives many clinical processes." since this contradicts your comments on "Administrative Gender", e.g. (The basic gender included in Patient.gender has a limited use, that of the administrative gender: the gender that the patient is considered to have for administration and record keeping purposes.) <br/>
+
Block vote motion by Irma to accept PA Mission and Charter, 3 year work plan and SWOT, Brian seconded.<br/>
−
<br/>
+
Discussion: None<br/>
−
To support your statement "Systems providing decision support or enforcing business rules should ideally do this on the basis of Observations dealing with the specific gender aspect of interest (anatomical, chromosomal, social, etc.)." suggest referring to LOINC codes for Sex assigned at birth (768909) since it may be different from the current Administrative Gender.  Also suggest adding reference to LOINC code for Gender Identity in this section.<br/>
+
Vote (For/against/abstain): 6/0/0<br/>
 
<br/>
 
<br/>
−
Cooper moves to disposition this persuasive with mod, Brian seconded. <br/>
+
The WG continued with the FHIR tracker items.<br/>
−
Discussion: None<br/>
 
−
Vote: 5/1/3<br/>
 
 
<br/>
 
<br/>
−
14756# - Provide LOINC code for sex assigned at birth - 2018-Jan Core #93 <br/>
+
16319 Marital Status Code System Missing Values <br/>
 +
The Marital Status Code code system referenced from the FHIR home page for the Patient normative material only lists one concept and also states "This Code system is not currently used".  The value set used is fully loaded and references the HL7 V3 Code System.  The latter is valid.  But including  the former with just one value is at least confusing.  Suggest to remove that code system, or include a reasonable set of concepts.<br/>
 
<br/>
 
<br/>
−
Submitted by: Freida Hall  (Quest Diagnostics) <br/>
+
16516 - Marital Status Code System Missing Values
−
On behalf of: Freida Hall (freida.x.hall@questdiagnostics.com) <br/>
+
The normative ballot includes CodeSystem Marital status, with the canonical URL defined as "http://hl7.org/fhir/marital-status".<br/>
−
Existing Wording: Tracking a patient's gender presents a number of challenges due to biological variations, differing cultural expectations and legal restrictions, and the availability of various kinds of gender re-assignment. The basic gender included in Patient.gender has a limited use, that of the administrative gender: the gender that the patient is considered to have for administration and record keeping purposes. In addition, to this gender, other kinds of gender may be represented: <br/>
+
However, the page says "This Code system is not currently used.<br/>
−
•Birth Sex - the sex assigned at birth / on the birth registration. Some countries allow variations such as not yet determined, unknown, or undifferentiated, while others do not. The US realm defines a US Specific extension for this for Meaningful Use<br/>
+
This is verified by the ValueSet for Marital status (http://hl7.org/fhir/2018May/valueset-marital-status.html) which does not include the above code system URL, instead it includes all the codes in "http://hl7.org/fhir/v3/MaritalStatus" and a single code from "http://hl7.org/fhir/v3/NullFlavor".<br/>
−
•Clinical Gender - an observation about the patient, typically using the LOINC code 76691-5 ). LOINC also provides a set of possible codes , or SNOMED CT has the descendents of 285116001 : Gender identity finding<br/>
+
Why ballot something that is not used as Normative?<br/>
 
<br/>
 
<br/>
−
Since you provide a LOINC code for Clinical Gender in the 2nd bulleted section, suggest also providing the LOINC code for "Sex assigned at birth" (76689-9) in the 1st bulleted section text description. <br/>
+
16616 - Add codes for missing Marital Status' - 2018-May Core Norm Patient #42<br/>
 +
Codes for married, separated, divorced, and widowed are missing.<br/>
 
<br/>
 
<br/>
−
Provide LOINC code for sex assigned at birth<br/>
+
16597 - 4.3.1.29 Value Set http://hl7.org/fhir/ValueSet/marital-status - 2018-May Core Norm Patient #13 <br/>
−
Michelle moved seconded by Brian to accept this with additional wording “Alternatively, if you were reepresentint this concept with an observation you could use the LOINC code 76689-9.” <br/>
+
4.3.1.29 Value Set http://hl7.org/fhir/ValueSet/marital-status<br/>
−
Vote: 8/1/0<br/>
 
 
<br/>
 
<br/>
−
#14099 - Guidance on how to request a new identifier (e.g. MRN) <br/>
+
Block move as persuasive. Codes system is not used anywhere in the FHIR specification. The marital status value set references the v3 code system, hence is leftover from where FHIR defined it’s own codes. This redundant Codeset will be removed. By Brian. Seconded by Drew.<br/>
−
See https://chat.fhir.org/#narrow/stream/implementers/topic/Create.20Identifier.20(MRN) <br/>
+
Discussion: None.
−
Need consistent guidance in the spec on how to request a new identifier be created (e.g. MRN).  Brainstorming ranged from: <br/>
+
Vote (for/against/abstain): 6/0/0
−
* An operation
 
−
* Use data absent reason extension to convey Identifier.value is "not yet assigned, so please assign it"
 
−
* An Identifier.assigner populated without Identifier.value populated
 
−
After discussion, An Identifier.assigner populated without Identifier.value populated<br/>
 
−
To be continued<br/>
 
 
<br/>
 
<br/>
 
===Meeting Outcomes===
 
===Meeting Outcomes===
Line 527: Line 503:
 
*.
 
*.
 
|}
 
|}
 +
 
==Monday Q4==
 
==Monday Q4==
 
{|border="1" cellpadding="2" cellspacing="0"  
 
{|border="1" cellpadding="2" cellspacing="0"  
Line 541: Line 518:
 
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''HL7 Patient Administration Meeting Minutes''' <br/>
 
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''HL7 Patient Administration Meeting Minutes''' <br/>
 
<!-- ********  CHANGE conf call details or meeting room ON NEXT LINE*****-->
 
<!-- ********  CHANGE conf call details or meeting room ON NEXT LINE*****-->
−
'''Location: Hilton New Orleans Riverside, Durham Conference Room '''
+
'''Location: Hotel Maritim, Cologne, Germany, Salon 20 Fulda '''
 
<!-- ********  CHANGE Date and Time  ON NEXT LINE  **********************-->
 
<!-- ********  CHANGE Date and Time  ON NEXT LINE  **********************-->
 
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''Date: 2018-01-29'''<br/> '''Time: Monday Q4'''
 
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''Date: 2018-01-29'''<br/> '''Time: Monday Q4'''
Line 631: Line 608:
 
'''Minutes/Conclusions Reached:'''<br/>
 
'''Minutes/Conclusions Reached:'''<br/>
 
Introductions<br/>
 
Introductions<br/>
−
#14099 - Summary: Guidance on how to request a new identifier (e.g. MRN) (cont.) <br/>
 
 
<br/>
 
<br/>
−
Guidance will be provided in the section “8.1.3 Patient Id’s and Patient resource id’s”. Where there is a need to implement an automated MRN Identifier creation for a patient record, this could be achieved by providing an identifier in the patient with the MRN type, an appropriate assigner and no value assigned. Internal business rules can then detect this and replace/populate this id with 1 or more ids (as required). <br/>
+
16615 - Split Marital Status code = 'U' into two codes - 2018-May Core Norm Patient #41 <br/>
−
Drew moves/Brian<br/>
+
The existing valueset (from v3) that is bound to patient.maritalStatus already has these concepts separately defined>
−
Persuasive<br/>
+
Brian moves as not persuasive, Alex seconds.<br/>
−
Vote: 8/0/2<br/>
+
Discussion: none<br/>
−
# 14823 Add search for Encounter.account – <br/>
+
Vote: 7/0/0<br/>
−
Brian moves/Drew seconds to accept as persuasive. <br/>
 
−
Vote: 9/0/1<br/>
 
 
<br/>
 
<br/>
−
# 14824 - Encounter.class should be 1..1<br/>
+
16155 - Inconsistency between "Patient.managingOrganization" and Search Parameter "organization" <br/>
−
Class cardinality should be 1..1 as mentioned in section 8.11.4 Notes<br/>
+
The description of the search parameter will be updated to be consistent with the property.<br/>
−
The class element describes the setting (in/outpatient etc.) in which the Encounter took place. Since this is important for interpreting the context of the encounter, choosing the appropriate business rules to enforce and for the management of the process, this element is required. Moreover in class history it is marked as 1..1, so unless it is mandatory in current encounter, there won't be way to have it mandated in history<br/>
+
Motion made by Brian to find this prrsuasive. Seconded by Alex.<br/>
 +
Discussion: None<br/>
 +
Vote (for/against/abstain): 5/0/2<br/>
 
<br/>
 
<br/>
−
Encounter.class should be 1..1<br/>
+
16128 - General Grammar Review <br/>
−
This seems reasonable to the WG. <br/>
+
Brian moved to disposition this as persuasive. Alex seconded<br/>
−
Alex/Simone second<br/>
+
Discussion: None. <br/>
−
Vote: 9/0/1<br/>
+
Vote (for/against/abstain): 8/0/0<br/>
 
<br/>
 
<br/>
−
# 14499 - Encounter.class description/definition contains duplicates (not in value set) <br/>
+
16129 - The definition of Patient.active is "Whether this patient's record is in active use". This definition seems to imply that the Patient resource represents the patient record rather than a reference to the patient entity or role. Would this attribute not below on the patient record (e.g. Composition) rather than on the patient resource? FHIR needs to provide explicit guidance on how the patient resource is used and how a patient record is formed using FHIR.
−
Description/definition says "inpatient | outpatient | ambulatory | emergency +"<br/>
+
Waiting for input from submitter.<br/>
−
The format of that description/definition usually implies those are specific codes in the value set, but the value set doesn't differentiate between outpatient and ambulatory.  There is a single code for ambulatory, so it seems a bit misleading to imply there are codes for both. <br/>
 
−
The WG discussed this and decided upon a different description. <br/>
 
−
“Concepts representing classifciatin of patient encounter such as ambulatory (outpatient), inpatient<br/>
 
−
Simone moves/Line seconds <br/>
 
−
Vote: 9/0/0<br/>
 
 
<br/>
 
<br/>
−
# 14758  - Summary: Add example to Encounter.diagnosis.rol to address principal diagnosis for an Encounter as noted in the comment provided (or add an additional role of principalDiagnosis). - 2018-Jan Core #95 <br/>
+
16130 - birth/death attributes should be structures - Recommend that birth and death be structures rather than simple types since a number of other attributes will be added pertaining to each. A structure provides a place to add these additional attributes. For instance, birth/deathAddress, birthPlurality, birthOrder, birth/deathCertificateNumber, etc...
−
Clinical quality measures need to address the concept of a Principal Diagnosis defined by statute as the coded diagnosis/problem established after study to be chiefly responsible for occasioning the admission of the patient to the hospital for care. The roles provided do not directly address principal diagnosis. FHIR tracker (https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10544) suggest that encounter-primaryDiagnosis and encounter-relatedCondition extensions will be removed as they are redundant with the core resource (using Encounter,diagnosis.role and Encounter.diagnosis.rank.  However, the extension remains. And the example in Encounter.diagnosis.role does not address principal diagnosis.  Encounter.diagnosis.role should include an example for definiing Principal diagnosis (e.g., role = billing diagnosis AND rank = 1, or role = discharge diagnosis AND rank = 1.  Alternatively, add a role of "principalDiagnosis" to enable clinical quality measures and clinical decision support. <br/>
+
Extending primitives is really not the way to go. Adding sibling attributes would not make it clear that these attributes are related the birth/death data for this patient. For instance, we would propose a birthData attribute of type BackboneElement with two attributes in FHIR core: birthDate and multipleBirth. The would provide a cleaner future extension path for Patient.<br/>
 
<br/>
 
<br/>
−
Add example to Encounter.diagnosis.role to address principal diagnosis for an Encounter as noted in the comment provided (or add an additional role of principalDiagnosis). <br/>
+
Brian moves this as not persuasive, Drew seconds<br/>
−
The encounter-primaryDiagnosis and encounter-relatedCondition will be removed as being redundant to Encounter.diagnosis.role and Encounter.diagnosis.rank. <br/>
+
Discussion: the WG discussed the “in person” request. The WG decided to vote and reopen it if the submitter wants to discuss during the Cologne WGM.<br/>
−
As for the example reference, Simone suggested to make this an example binding. THe WG determined to update example <br/>
+
Vote (for/against/abstain):7/0/1<br/>
−
The redundant extension will be removed. <br/>
 
−
Example f202 will be updated to remove the extension and clarify the usage. <br/>
 
−
Cooper Thompson moves and  Tricia Chitwood seconds to make this persuasive with mod<br/>
 
−
Vote: 8/0/2<br/>
 
 
<br/>
 
<br/>
−
# 14477 - Encounter.serviceType needs binding to value set <br/>
+
15935 - The Patient $match and $everything operations should not be normative in R4
−
Encounter.serviceType needs a binding to a value set. <br/>
+
The operations on the Patient resource were not intended to be marked as normative (I believe).
−
After some research, it seems the binding is there, but the references from the Encounter.type does not point to the existing binding set which is an example set. <br/>
+
$match certiantly isn't ready, and $everything probably isn't either.
−
Brian moves, Alex seconds to move this persuasive. <br/>
+
The WG considered this persuasive, as it is not normative. The 2 patient operations ($match and $everything) will be removed fom the normative status to STU.<br/>
−
Vote: 8/0/1<br/>
+
Discussion: This is what the WG intends to do. The WG decided to vote now and validate with FHIRI tomorrow Q1.<br/>
 +
Action: This will be referred to FHIRI<br/>
 +
Moved as persuasive by Brian, seconded by Line.<br/>  
 +
Vote (for/against/abstain): 7/0/01<br/>
 
<br/>
 
<br/>
−
# 14451 - PA resources do not have a clean Workflow report<br/>
+
16422 - Patient: Remove animal from "scope and usage" description <br/>
−
The workflow project has put together a report identifying places where resources don't align with patterns, as well as a mechanism for work groups to mark as "ignored" if they don't feel alignment is appropriate/necessary.  Your work group has resources that are still showing up on the report - meaning that an alignment review has not been completed (or there are issues with the suppression process - in which case please let me know). Alignment is most critical for normative resources, but should be completed for all resources that are FMM3 or higher (and should be considered for resources with lower FMM levels) <br/>
+
Drew  moved as non-persuasive, Brian seconded.<br/>
−
After discussion our FHIR SMEs decided to “divide and conquer” the work based on the specific resources defined in the tracker item: <br/>
+
Discussion: None<br/>
−
* ChargeItem - Simone
+
Vote (for/against/abstain): 7/0/1
−
* Encounter - Drew
 
−
* EpisodeOfCare - Cooper
 
−
* AppointmentResponse – Brian
 
−
* Appointment - Brian
 
 
<br/>
 
<br/>
 +
16429 –  Inclusion of STU comments on Normative content <br/>
 +
Should a normative section of the standard still referencing feedback via an STU Note?
 +
The patient Merge section is not intended to be a normative section, as it has not been tested or completed and requires further work when the community is ready to advance it.<br/>
 +
THe WG discussed and decided to move the “STU” portion of the “STU Note:” as this would be a more general description. It was noted that the section in question is not substantive and contains no operations. The submitter being in the room, he was satisfied wit this.<br/>
 +
Drew moved to disposition this as persuasive, Iryna seconds.<br/>
 +
Vote: 7/0/1<br/>
 +
<br/>
 +
16592 - Patient Contact needs a date associated with it as patient contacts change. - 2018-May Core Norm Patient #7 <br/>
 +
The patient contact element has a period associated with it which indicates the dates that the contact i applicable for use.
 +
The patient resource as a whole has the meta.lastUpdated which indicates when the resource was updated. Checking in history you could determine when the specific change occurred.<br/>
 +
There is no special date which shows when the backbone element/property was changed.<br/>
 +
Iryna moves this as non persuasive with mod, Brett Esler seconds.<br/>
 +
Vote (for/against/abstain): 7/0/1<br/>
 +
<br/>
 +
 
===Meeting Outcomes===
 
===Meeting Outcomes===
 
{|border="1" cellpadding="2" cellspacing="0"  
 
{|border="1" cellpadding="2" cellspacing="0"  

Latest revision as of 17:46, 3 July 2018


Return to: WGM Minutes > 2018 > May Cologne

Patient Administration Work Group Minutes - May 14, 2018

Monday Q1

HL7 Patient Administration Meeting Minutes

Location: Maritime Hotel, Cologne, Salon 20 Fulda

Date: 2018-01-29
Time: Monday Q1
Facilitator Line Saele Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 Netherlands
X Alex de Leon Kaiser Permanente, USA
X Line Saele HL7 Norway
X Brian Postlethwaite Telstra Health, Australia
X Cooper Thompson EPIC, USA
X Christian Hay GS1, Switzerland
X Bidyut Parruck Interface ED, USA
X Simone Heckmann HL7 Germany
X Hans Buitendyjk Cerner, USA
X Andrew Torres Cerner, USA
X Kathy Pickering Cerner
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics
Welcome and introductions Joint meeting with Financial Management - FHIR

  • HL7 Plenary

Supporting Documents

Minutes

HL7 Plenery

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • Action:


Next Meeting/Preliminary Agenda Items
  • .

Monday Q2

HL7 Patient Administration Meeting Minutes

Location: Hotel Maritim, Cologne, Germany, Salon 20 Fulda

Date: 2018-05-14
Time: Monday Q2
Facilitator Brian Postlethwaite Scribe Alex de Leon
Attendee Name Affiliation
X Brian Postlethwaite Telstra Health, Australia
X Irma Jongeneel HL7 Netherlands
X Alex de Leon Kaiser Permanente, USA
X Line Saele HL7 Norway
X Cooper Thompson EPIC, USA
X Kathy Pickering Cerner, USA
X Christian Hay GS1, Switzerland
X Simone Heckmann HL7 Germany
X Bidyut Parruck Interface ED, USA
Quorum Requirements Met (Chair +2 members): Yes

Agenda

Agenda Topics

  1. Welcome and introductions
  2. Joint meeting with Financial Management - FHIR
  3. Invoice draft review
  4. ChargeItemDefintion draft review
  5. ProductPlan review
  6. Payment/Adjustment resource?

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions

Minutes/Conclusions Reached:
Introductions
Joint session with FM. The WG began with the review of the Invoice resource.
Simone noted that in the last call, the WG was asked to build the invoice looking forward to the approval of this invoice.
Mary Kay noted that there were no quantities involed. Simone explained that the invoice is moer like a summary of the charge items. This would require a bundle to be included to actually use this resource. The operation would be a submit of the invoice that would create the bundle of charge items and paitient information. This would require approval by FM.
http://build.fhir.org/invoice.html
Irma asked if this should follow the workflow pattern.

Irma moves to accept this resource proposal to move forward., Iryna seconds.
Discussion: This is to move forward with the proposal. Vote (for/against/abstain): 12/0/0
The WG looked generally at the charge item resource to gain approval to move forward with tis as well.

http://wiki.hl7.org/index.php?title=ChargeItemDefinition_FHIR_Resource_Proposal

The pricing details or catalog also services available.

The WG reviewed the elements involved for the context of ChargeItem Definition
Patient, Encounter,

Simone reviewed some of the relevant elements within the proposed ChargeItemDefnition

The Instance element was discussed. FM felt that the reference which currently included Medication, Substance and Device can be expanded.

The joing workgroups had a lively enough discussion on the elements within the ChargeItemDefinition as currently defined to merit moving forward with this proposal.
There were value statements from Germany, Australia, and US for the use of this resource. Each had some use cases which would be supported by this resource.

Action: FM noted that there should be a way to indicate related definition. The Example rule is … there are 10 items that can be charged but only one can be charged. This is one thing that needs to be accounted for.
MaryKay moves to accept the resource proposal for moving forward. Simone seconds.
Discussion: None
Vote: 10/0/1

The WG moved on to review the ProdcutPlan. To be able to have an insurer express their basic product (a set of coverages) and plan where plans are the risk share. For one product, there could be many different ways you can handle risk. This is a structure that allows you to define this.
http://build.fhir.org/productplan
This is not doing billing, it’s doing coverage and risk sharing. Structure of the plan.

Location was supposed to change from 0..1 to 0..*.

The FM work group invited any interested parties to review this.

Brian noted that there is another FM joint session on Thursday Q2.

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • None
Next Meeting/Preliminary Agenda Items
  • .

Monday Q3

HL7 Patient Administration Meeting Minutes

Location: Hotel Maritim, Cologne, Germany, Salon 20 Fulda

Date: 2018-05-14
Time: Monday Q3
Facilitator Line Saele Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 Netherlands
X Line Saele HL7 Norway
X Brian Postlethwaite Telstra Health, Australia
X Alex de Leon Kaiser Permanente, USA
X Toril Reite HL7 Norway
X Cooper Thompson EPIC, USA
X Oyvind Aassve HL7 Norway
X Michelle Miller Cerner
X Tricia Chitwood Cerner, USA
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. FHIR Ballot Reconciliation

Supporting Documents

  • 14333 - Provide more clarity between administrativeGender, sex, and gender identity
  • 14154 - Searching a patient by Identifier Type
  • 14099 - Guidance on how to request a new identifier (e.g. MRN)
  • 14341 - Replace "hermaphrodite" with "intersex"
  • 14174 - herd should be able to reference the owner

Minutes

Minutes/Conclusions Reached:
Introductions

Introductions

The WG decided to review the agenda for the week. Included V2.9 ballot reconciliation Thursday Q3. Also included v2.9 proposal 716 included with Patient care joint session.

The WG also noted that FHIR ballot reconciliation for Patient should take presendence so changed Monday, Q4 and Tuesday Q1, Q2 and 3, to include 3 ½ quarters to get through .
Motion was made by Brian to approve the new agenda, seconded by Irma. Discussion: None Vote (for/against/abstain): 6/0/0
Reviewed the mission and charter. No changes.

Work group help. Although there was an email sent that the PAWG would accept the outcome, HL7 headquarters did not record this. Line will follow up with Anne as it was stated that it would be taken care of. Given this, the PAWG shold get a star for 2018 May.
The WG reviewed the 3 year work plan. Updated by adding the ChargeItemDefinition. The WG noted that the project ID did not need to change as

The WG continued to review the SWOT .

Block vote motion by Irma to accept PA Mission and Charter, 3 year work plan and SWOT, Brian seconded.
Discussion: None
Vote (For/against/abstain): 6/0/0

The WG continued with the FHIR tracker items.

16319 Marital Status Code System Missing Values
The Marital Status Code code system referenced from the FHIR home page for the Patient normative material only lists one concept and also states "This Code system is not currently used". The value set used is fully loaded and references the HL7 V3 Code System. The latter is valid. But including the former with just one value is at least confusing. Suggest to remove that code system, or include a reasonable set of concepts.

16516 - Marital Status Code System Missing Values The normative ballot includes CodeSystem Marital status, with the canonical URL defined as "http://hl7.org/fhir/marital-status".
However, the page says "This Code system is not currently used.
This is verified by the ValueSet for Marital status (http://hl7.org/fhir/2018May/valueset-marital-status.html) which does not include the above code system URL, instead it includes all the codes in "http://hl7.org/fhir/v3/MaritalStatus" and a single code from "http://hl7.org/fhir/v3/NullFlavor".
Why ballot something that is not used as Normative?

16616 - Add codes for missing Marital Status' - 2018-May Core Norm Patient #42
Codes for married, separated, divorced, and widowed are missing.

16597 - 4.3.1.29 Value Set http://hl7.org/fhir/ValueSet/marital-status - 2018-May Core Norm Patient #13
4.3.1.29 Value Set http://hl7.org/fhir/ValueSet/marital-status

Block move as persuasive. Codes system is not used anywhere in the FHIR specification. The marital status value set references the v3 code system, hence is leftover from where FHIR defined it’s own codes. This redundant Codeset will be removed. By Brian. Seconded by Drew.
Discussion: None. Vote (for/against/abstain): 6/0/0

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • Action:
  • Action:
Next Meeting/Preliminary Agenda Items
  • .

Monday Q4

HL7 Patient Administration Meeting Minutes

Location: Hotel Maritim, Cologne, Germany, Salon 20 Fulda

Date: 2018-01-29
Time: Monday Q4
Facilitator Irma Jongeneel Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 Netherlands
X Line Saele HL7 Norway
X Brian Postlethwaite Telstra Health, Australia
X Alex de Leon Kaiser Permanente, USA
X Christian Hay GS1, Switzerland
X Cooper Thompson EPIC, USA
X Hanhong Lu EPIC, USA
X Simone Heckman HL7 Germany
X Drew Torres Cerner, USA
X Isabel Gibaud HL7 France
X Tricia Chitwood Cerner, USA
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. FHIR Ballot Reconciliation - Encounter

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions

16615 - Split Marital Status code = 'U' into two codes - 2018-May Core Norm Patient #41
The existing valueset (from v3) that is bound to patient.maritalStatus already has these concepts separately defined> Brian moves as not persuasive, Alex seconds.
Discussion: none
Vote: 7/0/0

16155 - Inconsistency between "Patient.managingOrganization" and Search Parameter "organization"
The description of the search parameter will be updated to be consistent with the property.
Motion made by Brian to find this prrsuasive. Seconded by Alex.
Discussion: None
Vote (for/against/abstain): 5/0/2

16128 - General Grammar Review
Brian moved to disposition this as persuasive. Alex seconded
Discussion: None.
Vote (for/against/abstain): 8/0/0

16129 - The definition of Patient.active is "Whether this patient's record is in active use". This definition seems to imply that the Patient resource represents the patient record rather than a reference to the patient entity or role. Would this attribute not below on the patient record (e.g. Composition) rather than on the patient resource? FHIR needs to provide explicit guidance on how the patient resource is used and how a patient record is formed using FHIR. Waiting for input from submitter.

16130 - birth/death attributes should be structures - Recommend that birth and death be structures rather than simple types since a number of other attributes will be added pertaining to each. A structure provides a place to add these additional attributes. For instance, birth/deathAddress, birthPlurality, birthOrder, birth/deathCertificateNumber, etc... Extending primitives is really not the way to go. Adding sibling attributes would not make it clear that these attributes are related the birth/death data for this patient. For instance, we would propose a birthData attribute of type BackboneElement with two attributes in FHIR core: birthDate and multipleBirth. The would provide a cleaner future extension path for Patient.

Brian moves this as not persuasive, Drew seconds
Discussion: the WG discussed the “in person” request. The WG decided to vote and reopen it if the submitter wants to discuss during the Cologne WGM.
Vote (for/against/abstain):7/0/1

15935 - The Patient $match and $everything operations should not be normative in R4 The operations on the Patient resource were not intended to be marked as normative (I believe). $match certiantly isn't ready, and $everything probably isn't either. The WG considered this persuasive, as it is not normative. The 2 patient operations ($match and $everything) will be removed fom the normative status to STU.
Discussion: This is what the WG intends to do. The WG decided to vote now and validate with FHIRI tomorrow Q1.
Action: This will be referred to FHIRI
Moved as persuasive by Brian, seconded by Line.
Vote (for/against/abstain): 7/0/01

16422 - Patient: Remove animal from "scope and usage" description
Drew moved as non-persuasive, Brian seconded.
Discussion: None
Vote (for/against/abstain): 7/0/1
16429 – Inclusion of STU comments on Normative content
Should a normative section of the standard still referencing feedback via an STU Note? The patient Merge section is not intended to be a normative section, as it has not been tested or completed and requires further work when the community is ready to advance it.
THe WG discussed and decided to move the “STU” portion of the “STU Note:” as this would be a more general description. It was noted that the section in question is not substantive and contains no operations. The submitter being in the room, he was satisfied wit this.
Drew moved to disposition this as persuasive, Iryna seconds.
Vote: 7/0/1

16592 - Patient Contact needs a date associated with it as patient contacts change. - 2018-May Core Norm Patient #7
The patient contact element has a period associated with it which indicates the dates that the contact i applicable for use. The patient resource as a whole has the meta.lastUpdated which indicates when the resource was updated. Checking in history you could determine when the specific change occurred.
There is no special date which shows when the backbone element/property was changed.
Iryna moves this as non persuasive with mod, Brett Esler seconds.
Vote (for/against/abstain): 7/0/1

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)

Next Meeting/Preliminary Agenda Items
  • .

Navigation

© 2018 Health Level Seven® International. All rights reserved. [[Category:2018_PA_WGM_Minutes]

Retrieved from "https://wiki.hl7.org/w/index.php?title=2018-05-14_PA_WGM_Minutes&oldid=158764"