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

Difference between revisions of "2015-05-13 PA WGM Minutes"

From HL7Wiki
Jump to navigation Jump to search
m (Line moved page 2014-05-13 PA WGM Minutes to 2015-05-13 PA WGM Minutes: Not 2014)
m
 
(One intermediate revision by the same user not shown)
Line 524: Line 524:
 
[[Category:2015_PA_Minutes]]
 
[[Category:2015_PA_Minutes]]
 
==Navigation==
 
==Navigation==
* [[2015_05_11_PA_WGM_Minutes|Go To Monday Minutes]]
+
* [[2015_05-11_PA_WGM_Minutes|Go To Monday Minutes]]
* [[2015_05_12_PA_WGM_Minutes|Go To Tuesday Minutes]]
+
* [[2015_05-12_PA WGM Minutes|Go To Tuesday Minutes]]
* [[2015_05_13_PA_WGM_Minutes|Go To Wednesday Minutes]]
+
* [[2015_05-13 PA WGM Minutes|Go To Wednesday Minutes]]
* [[2015_05_14_PA_WGM_Minutes|Go To Thursday Minutes]]
+
* [[2015_05-14 PA WGM Minutes|Go To Thursday Minutes]]
 
* [[2015_05_PA_WGM|Return to PA May 2015 WGM]]
 
* [[2015_05_PA_WGM|Return to PA May 2015 WGM]]
 
© 2007-2015 Health Level Seven® International.  All rights reserved.
 
© 2007-2015 Health Level Seven® International.  All rights reserved.
 
[[Category:PA_Minutes]]
 
[[Category:PA_Minutes]]
 +
[[Category:2015 PA Minutes]]
 
[[Category:2015_PA_Minutes]]
 
[[Category:2015_PA_Minutes]]

Latest revision as of 07:18, 2 September 2015

Patient Administration Work Group Minutes - Wednesday May 13, 2015

Wednesday Q1

HL7 Patient Administration Meeting Minutes

Location: Hyatt, Paris, France, Guest Room #2331

Date: 2015-05-13
Time: Wednesday Q1
Facilitator Line Saele Note taker Alex de Leon
Attendee Name Affiliation
X Line Saele Helse Vest IKT Norway
X << update attendees >>
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. << update agenda topics>>

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions
The WG reviewed the minutes from the last WGM (San Antonio). The following action items were considered still open from the last WGM.
Action: Follow up with Brian and or OnO about encounter and relationships of orders and encounters. Responsible: Alex, Due:
Action: Get clear direction of what goes on the HL7 website and what goes on the wiki. There should be a clear link on the workgroup website. Steering division should be asked for clear direction on working group assets to eliminate redundancy. Talk to Pat. Responsible: Alex, Due:
Action Item: Project insight clean up. Responsible: Alex, Due:
Action Item: Follow up with Karen about MOU in place for joint copyrights with OASIS and HL7. Also follow up with Elysa to get a recent copy of the PSS with the updated template. Responsible: Alex, Due:
Action Item: Make an official request to create of the FHIR facilitator role for the recognition of the work done by Brian. Responsible: Line, Due: June 2015.
Action: Update the milestones for projects in Project Insight. Responsible: Line Due: March 2015
Action: Follow up on the status of: 978 – CMET alignment with DMIM (Person and Patient) - Still shows for publication. 1029 – Patient Encounter MessagingReady for normative edition publication since Aug12 shows approval TSC. Responsible: Line, Due:
Action: Ask Brian if 1101 – Services Directory rel 2 and 1121- Healthcare and Community services provider Directory (ServD) are these the same? Alex
Iryna moved to approve the meeting minutes from San Antonio, Irma seconded.
Discussion: None
Vote(for/against/abstain): 3/0/0
The WG reviewed the Mission, charter and the DMP, 3 year work plan and SWOT.
No changes were determined to be needed.
Action: Communicate to the SD that the above items have been reviewed by the WG.

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • <<consolidate action items>>
Next Meeting/Preliminary Agenda Items
  • .

Wednesday Q2

HL7 Patient Administration Meeting Minutes

Location: Hyatt, Paris, France, Guest Room #2331

Date: 2015-05-13
Time: Wednesday Q2
Facilitator Line Saele Note taker Alex de Leon
Attendee Name Affiliation
X Line Saele Helse Vest IKT Norway
X << Update Attendees >>
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. << update agenda topics >>

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions

  1. 7906 – Encounter condition relationship

Add the ability to represent which conditions (diagnosis) were related to the encounter in addition to a role code specifying which condition was the principal diagnosis and which are working, preliminary, confirmed, final, etc. Similar to the QICore Encounter profile extensions
The WG discussed the way that the Condition, Encounter and EpisodeOfCare should be related and how that relates to condition. The Patient Care WG. Within the encounter resource, “reason” and “indication” were discussed as a way to link Patient Care concerns and Patient Administration concerns.
The WG discussed EpisodeOf Care and what that might mean. Patient Care displayed a use case of the evolution of a health concern (Hernia)
The two work groups discussed further the relationships of the concept of EpisodeOfCare, Encounter and HealthIssue. The ISO model was displayed for clarity.
The WG then followed through ad hoc use case about pregnancy of a diabetic patient who happens to then have a urinary tract infection (UTI). Diabetes would be an episode of care that occurred before the pregnancy, which would now be in parallel to the new pregnancy episode of care and the UTI could be simply an encounter.
It became clear after discussion that the sequencing of the conditions make a difference; essentially what the patient presents should be the primary concern.
In discussing the various resources involved, the WG focused on the Encounter.indication, the text of which constrains on Condition or Procedure. “Reason the encounter takes place, as specified using information from another resource. For admissions, this is the admission diagnosis. The indication will typically be a Condition (with other resources referenced in the evidence.detail), or a Procedure.”
This helped the first part of the commenter’s problem. However the ballot commenter (Michelle) who was present expressed again the concern about the “role” that the indication is playing (e.g. primary, secondary, etc.)
Brian procedded to remodel the Encounter.indication and Encounter.reason to meet the needs of Patient Care. The final model seems to separate the Encounter.reason (procedure/role) and Encounter.reason (condition/role).

  1. 7858 – Patient Cause of Death is related to the above # 7906
  2. 7865 – Hospitalization component removed from Encounter resource in DSTU2.


Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • <<consolidate action items>>
Next Meeting/Preliminary Agenda Items
  • .

Wednesday Q3

HL7 Patient Administration Meeting Minutes

Location: Hyatt, Paris, France, Guest Room #2331

Date: 2015-05-13
Time: Wednesday Q3
Facilitator Irma Jongeneel Note taker Alex de Leon
Attendee Name Affiliation
X Line Saele Helse Vest IKT Norway
X << Update Attendees list >>
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. << update agenda topics >>

Supporting Documents

Minutes

Minutes/Conclusions Reached:

  1. 7865 – Encounter. Hospitalization period was removed.

Michelle (submitter) wanted to know why the period was removed hospitalization period was removed. Removed the accommodation component and removed the period on hospitalization component. IN order to meet her needs, she can make use of the location component to record the movement.
During this discussion, Brian explained the usage of location period for the patient move during a hospitalization. She seemed to think this might meet her needs and will check with her implementor. Meanwhile, the disposition now contains the following text in the tracker
“There is no period on the hospitalilzation as only the encounter with the hospitalization component has this information. To find this information for the other encounters that occur during the hospitalization, the information can be found on the part of encounter.
As discussed the location component has period to assist tracking within the encounter. If your system does not want to create additional encounters during the admission, it could use this component. We would recommend that you have at least 2 encounters, one that covers the admission/hospitalization, then another (or more ) that cover the interactions.
If you could provide some assistance with additional clarification on the guidance provided in section 5.18.1 we would happily assist .”
This will be marked as awaiting input from submitter.
Alexander H., now asked about the EncounterLocation.Status. After some discussion, the WG moved on to the next tracker item. He will create a tracker item for his concerns about values of this element.

  1. 7086 – Should communication also include a preferred method such as sign language, braille, etc
    .

On further examincation of this issue, were you referring to the telecom property to choose which contact point for the patient is preferred? This could be considered as a standard extension.
This will be marked as awaiting input from submitter.

  1. 7299 – Duplicate of # 6928. See the resolution there.
  2. 6930 – Duplicate concept of # 6928. Brian moves to not change the person resource referencing the explicit exclusion of race and ethnicity. Alexander H.

Discussion:
Vote (for/against/abstain): 9/0/3

  1. 7300 – gender should be renamed to administrative gender to distinguish it from a possible meaning of biological gender which for more in depth clinical uses could be a much greater set of potential value. This is done for other HL7 specifications.

The WG discussed this and did not find it persuasive since there is a lot of administrative gender text to define this well. Brian moves that there be no change. Alexander H. seconds.
Discussion:
Vote(for /against/abstain): 11/0/1

  1. 7301 – birth date should be dateTime.

The birth time component is defined as a standard extension which contains the date and time as requested. This has been done intentionally, in an attempt to prevent known issues caused by applying timezones inadvertently/incorrectly to birthdates given their importance in many systems for identification and cross references.
Brian moved to add notes into the description of the birthdate property to indicate that the standard extension should be used in your use case. Line seconds.
Discussion: None
Vote: 11/0/1

  1. 7558 – militaryService - This definition does not satisfy any specific requirements. It is insufficient for VA use and we no record of VA having been consulted. Research is needed on required content for this extension

The WG will remove the standard extension regarding military service from the standard extension as without having a shared meaningful valueset to interoperate with, this, as you point out, is meaningless. We do encourage a realm specific extension created in one of the appropriate profiles with a defined set.

Brian moved to remove the standard extension regarding military service from the standard extension as without having a shared meaningful valueset to interoperate with, it is meaningless. Alex d. seconded

Discussion
Vote (for/against/abstain): 10/0/2

  1. 7882 add coverage to patient

Some from FM might like to add. The WG will refer this to them.

  1. 7605 Allow birth date

Duplicate of 7301.

  1. 7302 – There needs to be a way to express reason for death via a condition resource.

After discussion we agree that this is not part of the core (via 80/20) patient resource and would fit within extensions. The group noted that there is a PDA segment in v2 which contains this type of information.
Brian moves that is not persuasive and will include the following text in the disposition. Aleander H. seconded.
After discussion we agree that this is not part of the core (via 80/20) patient resource and would fit within extensions. The group noted that there is a PDA segment in v2 which contains this type of information.
Discussion:
Vote (for/against/abstain): 8/0/0

Meeting Outcomes

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

Wednesday Q4

HL7 Patient Administration Meeting Minutes

Location: Hyatt, Paris, France, Guest Room #2331

Date: 2015-05-13
Time: Wednesday Q4
Facilitator Line Saele Note taker Alex de Leon
Attendee Name Affiliation
X Line Saele Helse Vest IKT Norway
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. <<update agenda topics>>

Supporting Documents

Minutes

Minutes/Conclusions Reached:

  1. 7858 – Cause of death

This has two parts to the request.
Add cause of death on the patient resource (allowing for multiple observations)
Add outcome (death) on the condition similar to the outcome on the Family History outcome.
Part 1 is a duplicate of # 7302.
The second part will be referred to patient care.

  1. 7559 – disability extension isn’t useful

Patient.Disability within the standard extensions.
The WG discussed the fact that there was no clear reference to the value set for disability. After some brief research, the v3 value set of http://hl7.org/fhir/2015May/v3/PersonDisabilityType/index.html which might be appropriate for administrative use. There is a local US defined valueset also from SNOMED http://hl7.org/fhir/2015May/valueset-qicore-patient-disability.html. The WG included this in the disposition along with an invitation to attend future work group meetings or conference calls to clarify their requirements.

  1. 6248 - add "unkown" to Value Set http://hl7.org/fhir/vs/animal-genderstatus and make required. In veterinary medicine you don't alway know. e.g. Is a young stray dog spayed? This is clinically useful information. (Could that abdominal mass be a puppy?) Also this VS is pretty complete and I would make required and change to code or at least extensible.

The value “unknown” will be added to the AnimalGender status valueset. The cardinality will remain as optional.
Nat moves to add the value of “unknown” to the AnimalGender status valueset and have the cardinality as optional until it is identified that this valueset has complete coverage of all values of the concept. The property will also be added to the recommended values. As this is only an example set, we should not set it as a required property. Brian seconds.
Discussion: The property will also be added to the recommended values. As this is only an example set, we should not set it as a required property.
Vote (for/against/abstain): 8/0/0

  1. 7609 The definition is ambiguous. What does "nominated care provider" mean? Is it the primary care provider?

The intent of this property is to provide the patient’s selected/nominated/chosen care providers.
This can be the primary care provider (in a GP context). This could also be a patient nominated care manager in a community/disability setting or even organization. The wording in the definition and detailed description will be updated to clarify this.
Brian moves to update the wording and detailed decription to clarify. Nat seconded.
Discussion: None
Vote (for/against/abstain): 8/0/0

  1. 7610 - Make managing organization 0..*? Can there only be one managing organization? How does this address a continuum of care use case? Should this be left to provenance and not be directly in the patient resource?

This is the custodian of the patient record. Peter moves to reject the change in cardinality and to add clarifying text to better descrive the usage of this property. Nat seconds.
Discussion: None
Vote (for/against/abstain): 8/0/0

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • <<consolidate action items>>
Next Meeting/Preliminary Agenda Items
  • .

Navigation

© 2007-2015 Health Level Seven® International. All rights reserved.