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

2018-05-16 PA WGM Minutes

From HL7Wiki
Revision as of 18:39, 27 November 2018 by Ajdeleon7 (talk | contribs) (→‎Minutes)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Return to: WGM Minutes > 2018 > May Cologne

Patient Administration Work Group Minutes - May 16, 2018

Wednesday Q1

HL7 Patient Administration Meeting Minutes

Location: HMaritime Hotel, Cologne, Salon 20 Fulda

Date: 2018-05-16
Time: Wednesday Q1
Facilitator Line Saele Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 Netherlands
X Alex de Leon Kaiser Permanente
X Line Saele
X Brian Postlethwaite HealthConnex, Australia
X Simone Heckmann HL7 Germany
X Andrew Tores Cerner, USA
X Michael Donnelly EPIC, USA
X Robert Dieterle Enablecare, USA
X Christian Hay GS1, Switzerland
X Cooper Thompson EPIC, USA
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics
Welcome/introductions

  1. FHIR Ballot Reconciliation – Provider Directory
Validated Healthcare Services Directory ballot comment review.
  • 9249 - Manage the Provenance of Practitioner (and Other Resources) using an Extension
  • 13264 - Organization, Location, and Practitioner need support for Merge/Link/Unmerge
  • 10234 - Locations should be able to include the shape (geocoded) of its physical boundry
  • 13391 - Should be able to identify a geographic area rather than a point for Location
  • 13563 - Location.type cardinality
  • 14216 - near-distance should be part of a composite search parameter

As time permits:

  • 12342 - endpoint-connection-type values don't capture XDS/XCA correctly
  • 14100 - Add imaging usecase to Endpoint summary
  • 14141 - Errors in R2 R3 Converson maps for HealthcareService.
  • 13495 - Location.address comment


Supporting Documents
  • 9249 - Manage the Provenance of Practitioner (and Other Resources) using an Extension
  • 13264 - Organization, Location, and Practitioner need support for Merge/Link/Unmerge
  • 10234 - Locations should be able to include the shape (geocoded) of its physical boundry
  • 13391 - Should be able to identify a geographic area rather than a point for Location
  • 13563 - Location.type cardinality
  • 14216 - near-distance should be part of a composite search parameter

As time permits:

  • 12342 - endpoint-connection-type values don't capture XDS/XCA correctly
  • 14100 - Add imaging usecase to Endpoint summary
  • 14141 - Errors in R2 R3 Converson maps for HealthcareService.
  • 13495 - Location.address comment

Minutes

Minutes/Conclusions Reached:
Introduction

  1. 13563 - Location.type cardinality

A single location could have multiple types of functions performed, such as a Women's Care Clinic with type = OB and GYN (using codes from the example value set to illustrate when 0..1 may not be sufficient)
Location
The WG discussed this and essentially agreed
Brian moves to disposition this as persuasive. Drew seconds.
Vote: 6/0/3

  1. 13264 - Organization, Location, and Practitioner need support for Merge/Link/Unmerge

Location
Practitioner
Organization

Much like the Patient resource needs merge/link/unmerge; the Resources of Location, Organization, and Practitioner also need this ability. IHE working on a Provider Directory (mCSD Profile) have uncovered the need when practicle operational deployment of distributed (aka National) directories. That is one custodian of directory entries learns of a merge/link/unmerge of an object that it has let others know about. There is a need to inform any future queries or bulk communications of the change.
THe PA wg considered whether this was indeed like patient. However EPIC noted that they are not exactly the same as merging patients is typically an erroneous creation of a patient record that need to be merged. Merging is typically a location that were actually different that change. Typically, they are not fixing of erroneously created data records.
The submitter’s example covers the use case where two organizations provide services in one location, thereby each have a record for that location. If these organizations were to merge, then what is to be done with the two records to retain the history of services, etc.
The WG noted that there is a linkage resource for this:
[http://build.fhir.org/linkage.html | Linkage resource}
However, this is not used to link patients, as there are elements in the Patient resource for this.
Brian moves to disposition this not persuasive. Irma seconded.
Vote: 9/0/0

  1. 10234 - Locations should be able to include the shape (geocoded) of its physical boundry

Location
Most locations have boundaries, and would like a standard way to share this shape information.
It can then be used to display on maps, and also perform contains checks. Such as you would do to check eligibiltiy that a patient is within their coverage area (a location property on healthcareservice).
This is probably not that common, but think common enough to warrant a standard extension.
The WG noted that this is the same as 13391
After some discussion, the feeling in the room is that it could and maybe should be part of the core specification on the location resource, but consideration must be done on how to represent this and support the various technical implementation possibilities. Deferred

  1. 14216 - near-distance should be part of a composite search parameter

Location
near-distance is not useful without a location. And if you're chaining, there's no way to make sure the location and distance match. So near-distance should be part of a composite parameter with location
Brian moves to disposition as persuasive.
Vote: 6/0/2

  1. 14100 - Add imaging usecase to Endpoint summary

In Scope and Usage, there's some great examples, but no mention at all for imaging. Maybe I'm a bit biased toward imaging, but do you think you could put something in there for imaging?

E.g., add bullet point to section 8.9.1:

  • DICOM/imaging: Location of where to query for imaging content and metadata (QIDO-RS, WADO-RS, or WADO-URI)

The wg agrees
Brian moves, Robert Dieterle seconds to disposition this as persuasive.
Vote: 7/0/1

  1. 13495 - Location.address comment

Location.address has a comment that says "This was kept as 0..1 as there is no use property on the address, so wouldn't be able to identify different address types"
Since Address.use does exist, this comment seems incorrect.
The WG reviewed this. It is not clear if the submitter wants merely to remove/correct the comment or whether this is a request to change the cardinality. The WG will defer this tracker item and get more information until it is clear what the scope of the question is.
The WG continued on with the Validate Healthcare Directory with Robert Dieterle
| Validate Healthcare Directory
THe WG reviewed the implementation guide and specifically discussed:

  • vhdir-location
  • vhdir-organization
  • vhdir-productPlan
  • vhdir-validation
  • vhdir-restriction


Meeting Outcomes

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

Wednesday Q2

HL7 Patient Administration Meeting Minutes

Location: Maritime Hotel, Cologne, Salon 20 Fulda

Date: 2018-05-16
Time: Wednesday Q2
Facilitator Brian Postlethwaite Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 Netherlands
X Alex de Leon Kaiser Permanente, USA
X Brian Postlethwaite Kaiser Permanente, USA
X Line Saele HL7 Norway
X Russell Leftwich Inter Systems, USA
X Dave Carlson Deparment of Veteran’s Affairs, USA
X Nick Radov Optum, USA
X Michael Tan NICTIZ, The Netherlands
X Drew Torres Cerner, USA
X Statin Long HL7 Germany,
X Cooper Thompson EPIC, USA
X Amit Popat EPIC, USA
X Michelle Miller Cerner, USA
X Simone Heckmann HL7 Germany,
Quorum Requirements Met (Chair +2 members): Yes

Agenda

Agenda Topics

  1. FHIR Ballot reconciliation (PC representative will join) - (Practitioner, PractitionerRole, CareTeam, EpisodeOfCare)
  • Clarify the scope and boundaries for HealthCareService
  • Organization Affiliation
  • Add Organization info back to Practitioner or perform more outreach to let WGs know to update their resources
  • Organization, Location, and Practitioner need support for Merge/Link/Unmerge

As time permits:

  • Restructure availability in HealthService resource
  • Clarify the scope and boundaries for HealthCareService


Supporting Documents
  • 12851 - Clarify the scope and boundaries for HealthCareService
  • 10304 - Organization Affiliation
  • 13682 - Add Organization info back to Practitioner or perform more outreach to let WGs know to update their resources
  • 13264 - Organization, Location, and Practitioner need support for Merge/Link/Unmerge

As time permits:

  • 9260 - Restructure availability in HealthService resource
  • 12851 - Clarify the scope and boundaries for HealthCareService

Minutes

Minutes/Conclusions Reached:

Patient Care representation.
Introductions
The PA WG hosting PC
Before going on to tracker PC wanted to know if someone coming Thurs Q4. Irma and Cooper.
Heads up. Change in pattern Practitioner -> on behalf of was removed. This will be discussed.
Patient care wants to know more about OrgazationRole resource especially in the context of CareTeam.

The WG discussed the concepts around Practitioner and PractitionerRole. The PractitionerRole was introduced to support multiple roles.
OrganizationRole is supposed to convey the relationship between two organizations.
THe WGs discussed the OrganizationRole. Simone noted that if there is a need to express the relationship between two orgs within the context of careteam, you can still query based on PractitionerRole
OrganizationRole changes:
Action Items: Remove Available times
Make from/to mandatory
Rename the resource
Guidance on telecom
Guidance on orgs providing services (as child organizations)

THe WG then moved on to address the tracker items with ballot items first.

  1. 12851 - Summary: Clarify the scope and boundaries for HealthCareService

Additional clarifying text will be added to the boundaries section of the HealthcareService resource to highlight the differences to:

  • Organization – thte org provides the services, the healthcareservice descibes the services
  • ServiceDefinition – This is a clinical deision support module not a healthcare service provision related resource.
  • ServiceRequest – The servie request can reques that a service ve proided by a specifiT
  • OrganizationAffiliation
  • Location


The WG looked at ServiceRequest reference to HealthcareService, which has the type of service included in it.
There was much discussion to clarify the interaction between the resources.
Irma moved to disposition this as persuasive. Cooper seconded. This will result in the addition of clarifying text.
Vote: 14/0/0

The WG discussed an earlier tracker that was referred to FHIR infrastructure that might be pertinent to Patient Care:

  1. 14154 - Searching a patient by Identifier Type

We discussed this as either a PA issue (which will also be relevant to Practitioner, and likely others) and considered that this should be covered at the search token level so can be used on other resources with the identifier.
Including the full identifier.system.type and code
Patient?ident-with-type=http://hl7.org/fhir/v2/0203#MR%7C1234
Patient?ident-with-type=http://hl7.org.au/dental#MR%7C1234
Not sure if we need the system, or if just the code is adequate
Patient?ident-with-type=MR|1234
This is the current search, which required:
Patient?ident=http..dept-A-mr|1234
Patient?ident=http..dept-B-mrn|1234
But we don't know which dept the MRN has come from (e.g. was in a lab message)
This should be moved to a FHIR Infrastructure problem to resolve.
Simone noted that she was in FHIRi covering this item. Drew also noted that he was remotely supporting this.

  1. 10304 - Organization Affiliation

Add an Organization.Affiliation to manage Organization relationships. This ticket is a result of an Argonaut Provider Directory Discussion
This is similar to Practitioner.PractitionerRole.
There is a new OrganizationRole resource that is planned to OrgAffiliation that covers this concept. Argonaut should review the updated definition.

  1. 13682 - Add Organization info back to Practitioner or perform more outreach to let WGs know to update their resources

Most workgroups are not aware that the relationship between a Practitioner and their Organization(s) was removed from Practitioner and put into PractitionerRole. Therefore, most resources no longer have the ability to record the Organization that is related to the Practitioner, since they only have a link to the Practitioner itself. This is a huge loss of valuable information, and should not have been done without more outreach.
Either add the Organization information back to Practitioner, or perform extensive outreach to all WGs that own resources that currently just point to Practitioner and have them add PractitionerRole as an option.
ALthogh Michelle feels that most of this will be covered through the workflow effort, however there are some that fall outside of workflow that should be covered. So she thinks it’s a good idea to cover those as well.
While the WG has covered the folliing tracker in the last quarter, the WG shared the results in this quarter.

  1. 13264 - Organization, Location, and Practitioner need support for Merge/Link/Unmerge

Michelle noted that their practice might add guidance in suggesting that Idenditifiers on Practitioners could also be used to detect these "duplicates" especially when merging datasets from multiple systems.
The WG then discussed continuing joint sessions for next WGMs. For now they will continue.
The PC WG asked for links to implementation guides that might be of interest to their group.
<<URL to IG>>

Meeting Outcomes

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

Wednesday Q3

HL7 Patient Administration Meeting Minutes

Location: Maritime Hotel, Cologne, Salon 20 Fulda

Date: 2018-05-16
Time: Wednesday Q3
Facilitator Irma Jongeneel Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 Netherlands
X Brian Postlethwaite TelstraHealth, Australia
X Alex de Leon Kaiser Permanente
X Isabel Gibaud HL7 France
X Drew Torres Cerner, USA
X Cooper Thompson EPIC, USA
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. FHIR ballot reconciliation (Patient)
  • How to diffentiate the administrative gender between the clinical sex? - 2018-Jan Core #218
  • Use the language value set from ISO-639-3 which is the most updated language codes. - 2018-Jan Core #217
  • Multiple birth order should be a positive integer (not an integer) - 2018-Jan Core #206
  • Allow localization of Patient.gender - 2018-Jan Core #108
  • Laboratories need a valid biological sex for the patient
  • Consolidate Patient.generalPractitioner and CareTeam - 2018-Jan Core #56
  • Patient.generalPractitioner seems "iffy" for normative status
  • Consider having a pattern for Patient and similar resources
  • Patient.animal needs a meaning when absent

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions

  1. 14768 - Allow localization of Patient.gender

Duplicate of 14767
Existing Wording: Tracking a patient's gender presents a number of challenges due to biological variations, differing cultural expectations and legal restrictions
Proposed Wording: Tracking a patient's gender presents a number of challenges due to biological variations, differing cultural expectations and legal restrictions therefore the Patient.gender may be localized and harmonized by individual jurisdictions.
Comment:
In the US, this value set needs to be harmonized with X12, NCPDP SCRIPT, HL7 V2, and HL7 V3. This issue was discussed by the VA/DoD IPT.
THe WG noted that this was discussed extensively in previous tracker itmes (e.g. 11930, 3070, 11037). For any added values needed for implementation, they can be added as an extension.
Concept maps have been developed for v2 and v3. Any further mappings to other values not in the realm of HL7 may change.
Motion was made by Drew, seconded by Cooper to disposition this non persuasive.
Vote: 5/0/0

  1. 14876 - Use the language value set from ISO-639-3 which is the most updated language codes. –

The WG endorses the idea of consistency but feels though FHIR infrastructure should decide and manage this item.
Brian moved to refer this to FHIRi. Drew seconded.
Vote: 5/0/0

  1. 14734 - Consolidate Patient.generalPractitioner and CareTeam

The Patient resource has an attribute called generalPractitioner. There also exists in FHIR a resource called CareTeam. I would recommend that FHIR take a consistent approach to representing any member of a care team providing care to or helping manage the care of a patient. I would also encourage the FHIR team to coordinate with the CIMI team on the approach in conjunction with the relevant working groups at HL7 working on this front.
The Patient.generalPractitioner element on patient has a different purpose than CareTeam, wich contains members specifically for the provision of care
Not Persuasive
Drew moves to make this not persuasive. Brian seconds to disposition this as non persuasive.
Discussion: None
Vote: 5/0/0

  1. 14442 - Patient.generalPractitioner seems "iffy" for normative status

It's listed as 0..*, but there's no guidance on what to do if there are multiple repetitions, nor how to distinguish the repetitions. The references aren't role-specific, so you can't tell what clinic the relationship is with. It's not clear that this part has been well exercised. If it has been well-exercised, the documentation is lacking.
The role aspect of this tracker is being addressed in 14224 which is still outstanding awaiting implementer’s comments on Zulip.
As for the guidance, the WG believes that guidance could be provided.
Brian moved to disposition this as persuasive, Cooper seconded.
Vote: 5/0/0

  1. 14866 – Multiple birth order should be a positive integer (not an integer)

Community needs to be consulted in Zulip. Cooper will assure this.
Action: Cooper to socialize this to consider changing the FMM=5 resource.
Drew moved to disposition this as Not persuasive. Cooper seconded.
Discussion: this is based on the broader impact of requiring a change in the name of the property from Patient.multipleBirthInteger to Patient.multipleBIrthPositiveInteger. Cooper seconded. This would also not likely happen in practice and needs to be coded to handle the optionality of the datatype anyway.
Vote: 5/0/0

  1. 16453 - How to diffentiate the administrative gender between the clinical sex?

Clarifying text for this has been included as a resolution of tracker # 14754
Considered – Question Answered

  1. 14441 - Consider having a pattern for Patient and similar resources

We are currently using patterns to good effect to document "equivalencies" across resources and to help identify places where resources are not as consistent as they might be and confirming that variances are intended. The intention is to leverage these pattern mappings into constructs that can be supported within the reference implementations. It seems like there would be a benefit to having a pattern that covered Patient, RelatedPerson, Practitioner and possibly Person, Organization and/or Device. Or perhaps a couple of patterns. Given that we're looking at locking Patient down, it would be good to get these patterns in place and this analysis done prior to lockdown rather than after (though given that only Patient is being locked down, it does mean that all other resources can be aligned with Patient if it does get locked down first.)

The WG considered this and agrees, but also, given the timelines, don’t believe this can be achieved before R4.
Brian moves to disposition this as Considered for future use, Cooper seconded
Vote: 5/0/0


  1. 14755 - Laboratories need a valid biological sex for the patient (which is most commonly determined based on anatomy and physiology or genetic [chromosome] analysis.) When appropriate, and as determined by the provider, this may be reported as an observation of the patient's birth sex, if different from the patient's "Administrative Gender". However, some states now allow state residents to change their birth sex on their birth certificate, thus "birth sex" may not be reliable for the lab to use as input to report laboratory result reference ranges. The provider may report Administrative Gender as "Other" and send the current clinically relevant sex as an observation. Suggest adding 'mapping' for LOINC code 76689-9 Sex assigned at birth (https://s.details.loinc.org/LOINC/76689-9.html?sections=Comprehensive) and 76691-5 Gender identity (https://s.details.loinc.org/LOINC/76691-5.html?sections=Comprehensive).

The WG discussed this and wasn’t sure what the submitter was requesting, however, we believe at least part of this has been addressed with a decision to clarify the Patient Gender section.
Refer to the other tracker: 14756 Relevant gender
The gender does not actually bind to those LOINC codes mentioned, standard extensions are available for those.
Brian Postlethwaite / Cooper seconds to disposition this as not persuasive with mod.
Vote: 5/1/0

The WG considered the next work done. The next priority was decided to be Patient trackers.

  1. 14424 –To relate the encounters/encounter of a mother and her baby?

To relate the encounter of a mother and her baby for a maternity encounter, ...
?encounters/encounter--->
To relate the encounters of a mother and her baby in a maternity encounter, ...
Clarifying of wording will be applied
Brian moved, Simone seconded, to disposition this as persuasive.
Vote: 6/0/0

  1. 14422 - Need clarification: Relationship between both "Where" clauses and "Need"

This includes cases where these related people are actually contributing to the record, and need to be referenced individually (e.g. CarePlan.Participant, Encounter, DocumentReference, Appointment) where the Patient.Contact component cannot be used.

Need clarification: Relationship between both the "Where" clauses and the "Need" clause.

The WG spent time with the description of the Patient.contact vs. RelatedPerson usage text. Irma noted that some systems only have contacts and would not or do not support RelatedPerson. This seems to say that if you only have contact, then these systems could be not compliant.
New text will read:
"The contact element on the Patient Resource should be used for storing the details of people to contact. This information always travels with the patient, and cannot be used as the target of a reference.

Where related people need to be referenced by other resources (e.g. CarePlan.Participant, Encounter, DocumentReference.auther, Appointment), the RelatedPerson must be used."
Brian moved to disposition this as persuasive Drew seconds.
Discussion: None
Vote: 6/0/0

Irma noted that Lloyd has just recently sent an email asking about the Ballot Spreadsheet migration to GForge of our FHIR Ballot items and who is doing it. Brian had already sent it but Brian already sent. Brian reforwarded the email.

  1. 14482 – May Patient.gender be used to represent other kinds of gender?



12895 - Suggest align discharge disposition valueset with v2...
The valuset for discharge disposition in FHIR doesn'r match the v2 table (0112) - suggest the 2 be aligned...

http://hl7-definition.caristix.com:9010/Default.aspx?version=HL7%20v2.5.1&table=0112)

The v2 definition of the discharge disposition is a user defined valueset, however it appears that the US set is expanded, and other references have more codes.
We considered using the v2 codesystem, however this is not appropriately defined for fhir, with reserved code ranges for state/jurisdictional use - which would just be localised ValueSets in FHIR, and some codes which should be hierarchical.
A partial mapping will need to be added between the v2 and fhir sets. There are many additional codes in v2 also, these should be considered for addition.

The v2 definition of the discharge disposition is a user defined valueset, however it appears that the US set is expanded, and other references have more codes.
We considered using the v2 codesystem, however this is not appropriately defined for fhir, with reserved code ranges for state/jurisdictional use - which would just be localised ValueSets in FHIR, and some codes which should be hierarchical. This valueset is an example and we feel that every jurisdiction will have their own requirements. The provided list is intended to be a suggestion on usage. Feel free to use any valueset needed.
Irma moves to disposition this as non-persuasive, Drew seconds.
Discussion:
Vote : 10/0/0

16594 - Suggested additional categories: TF or FT (define as Transgender originally Female and TM or MT define as Transgender originally Male and allow extensions to see what gets used and if it should be added as a category - 2018-May Core Norm Patient #10
The assignment or selection of gender raises a question as to whether these 4 categories are adequate. Should there be a category for transgender-Male to Female and Female to Male as these changes are a reality. As to preferred gender-I am not sure that clinically that outweighs the actual gender and should be covered in a social history comment/narrative used to inform caring for the individual patient. Suggested additional categories: TF or FT (define as Transgender originally Female and TM or MT define as Transgender originally Male and allow extensions to see what gets used and if it should be added as a category

This issue has been discussed and resolved in another tracker. Please see 16601 16617 (14482).
The following text will be added:
Please consult the ex
tensive explanation in section 8.1.7 as to how the various gender concepts are represented in FHIR. Systems generally support the simple concepts as defined by FHIR and are very interoperable. The additional extended values that you've included would go into an extension on the property, selecting the "other" value in the core element.
See the below example patient resource that demonstrates this usage.
http://hl7.org/fhir/2018May/patient-example-b.xml.html
(Patient 2 for linking pat-2)
Drew moves to disposition these also as not persuasive Iryna seconds to match the disposition of the others.

16596 - The full value set of 11 codes should be displayed on the linked page rather than just U-the subseququent link below contains the 11 value sets - 2018-May Core Norm Patient #12
This is a duplicate of 16516

16602 - The text at the beginning of the Patient page contains a link that is broken. - 2018-May Core Norm Patient #24
Existing Wording: This is the FHIR R4 Mixed Normative/Trial Use Ballot #1, and the version for the Cologne Connectathon in May 2018. The current version is R3. See the ballot introduction for details about the ballot. For a full list of available versions, see the Directory of published versions and Timelines for an explanation of STU and other statuses.
This will be regenerated in next technical version. Referring to FHIR tooling.

16603 - Please correct the typo in Resource Content section, columnn "Description and Constraints" for element Link->Other - 2018-May Core Norm Patient #25
Existing Wording: The other patient or related person resource that the link refers to replaced-by | replaces | refer | seealso - type of link LinkType (Required)

Proposed Wording: The other patient or related person resource that the link refers to replaced-by | replaces | refer | see also - type of link LinkType (Required)
The WG discussed this and decided for clarity remove the “-type of link”
seealso is a code. We will remove the extra text "- type of link" to avoid misunderstanding. Drew moves to disposition this as Not Persuasive with mod. Discussion: None
Vote: 7/0/0

16604 - Please correct the link on the Patient Resource - Content page that contains a link that is supposed to allow the user to provided feedback. However, when the user is navigated to the page, the user cannot provide feedback. - 2018-May Core Norm Patient #2
How can we handle this ongoing feedback, the link for STU3 will be incorrect, where should we create it (the STU3 link doesn't work either)

16605 - Please correct the typo in Resource Content section, columnn "Description and Constraints" for element Link->Other - 2018-May Core Norm Patient #25
The typo will be corrected.
Drew moves as persuasive, Brian seconds.
Vote: 7/0/0

16609 - Please fix the link below the Resource Patient - Extensions & Profiles text that does not appear to take the user to the correct page. - 2018-May Core Norm Patient #31
Not persuasive since the link accurately takes the user to the search of the FHIR profile of the registry.
Discussion: non3
Vote: 6/0/0

17186 - Marital codes identified do not clearly delineate current marital status.
The WG reviewed the valueset and determined that that element defines the current status. It could be that the issue is with the Patient.maritalStatus definition, which states “This field contains a patient's most recent marital (civil) status”

Therefore the WG feels it is fine as is.
Irma moved to disposition this is not persuasive, Alex seconds.
Vote: 6/0/0


12895 - Suggest align discharge disposition valueset with v2...
The valuset for discharge disposition in FHIR doesn'r match the v2 table (0112) - suggest the 2 be aligned...

http://hl7-definition.caristix.com:9010/Default.aspx?version=HL7%20v2.5.1&table=0112)

The v2 definition of the discharge disposition is a user defined valueset, however it appears that the US set is expanded, and other references have more codes.
We considered using the v2 codesystem, however this is not appropriately defined for fhir, with reserved code ranges for state/jurisdictional use - which would just be localised ValueSets in FHIR, and some codes which should be hierarchical.
A partial mapping will need to be added between the v2 and fhir sets. There are many additional codes in v2 also, these should be considered for addition.

The v2 definition of the discharge disposition is a user defined valueset, however it appears that the US set is expanded, and other references have more codes.
We considered using the v2 codesystem, however this is not appropriately defined for fhir, with reserved code ranges for state/jurisdictional use - which would just be localised ValueSets in FHIR, and some codes which should be hierarchical. This valueset is an example and we feel that every jurisdiction will have their own requirements. The provided list is intended to be a suggestion on usage. Feel free to use any valueset needed.
Irma moves to disposition this as non-persuasive, Drew seconds.
Discussion:
Vote : 10/0/0

16594 - Suggested additional categories: TF or FT (define as Transgender originally Female and TM or MT define as Transgender originally Male and allow extensions to see what gets used and if it should be added as a category - 2018-May Core Norm Patient #10
The assignment or selection of gender raises a question as to whether these 4 categories are adequate. Should there be a category for transgender-Male to Female and Female to Male as these changes are a reality. As to preferred gender-I am not sure that clinically that outweighs the actual gender and should be covered in a social history comment/narrative used to inform caring for the individual patient. Suggested additional categories: TF or FT (define as Transgender originally Female and TM or MT define as Transgender originally Male and allow extensions to see what gets used and if it should be added as a category

This issue has been discussed and resolved in another tracker. Please see 16601 16617 (14482).
The following text will be added:
Please consult the ex
tensive explanation in section 8.1.7 as to how the various gender concepts are represented in FHIR. Systems generally support the simple concepts as defined by FHIR and are very interoperable. The additional extended values that you've included would go into an extension on the property, selecting the "other" value in the core element.
See the below example patient resource that demonstrates this usage.
http://hl7.org/fhir/2018May/patient-example-b.xml.html
(Patient 2 for linking pat-2)
Drew moves to disposition these also as not persuasive Iryna seconds to match the disposition of the others.

16596 - The full value set of 11 codes should be displayed on the linked page rather than just U-the subseququent link below contains the 11 value sets - 2018-May Core Norm Patient #12
This is a duplicate of 16516

16602 - The text at the beginning of the Patient page contains a link that is broken. - 2018-May Core Norm Patient #24
Existing Wording: This is the FHIR R4 Mixed Normative/Trial Use Ballot #1, and the version for the Cologne Connectathon in May 2018. The current version is R3. See the ballot introduction for details about the ballot. For a full list of available versions, see the Directory of published versions and Timelines for an explanation of STU and other statuses.
This will be regenerated in next technical version. Referring to FHIR tooling.

16603 - Please correct the typo in Resource Content section, columnn "Description and Constraints" for element Link->Other - 2018-May Core Norm Patient #25
Existing Wording: The other patient or related person resource that the link refers to replaced-by | replaces | refer | seealso - type of link LinkType (Required)

Proposed Wording: The other patient or related person resource that the link refers to replaced-by | replaces | refer | see also - type of link LinkType (Required)
The WG discussed this and decided for clarity remove the “-type of link”
seealso is a code. We will remove the extra text "- type of link" to avoid misunderstanding. Drew moves to disposition this as Not Persuasive with mod. Discussion: None
Vote: 7/0/0

16604 - Please correct the link on the Patient Resource - Content page that contains a link that is supposed to allow the user to provided feedback. However, when the user is navigated to the page, the user cannot provide feedback. - 2018-May Core Norm Patient #2
How can we handle this ongoing feedback, the link for STU3 will be incorrect, where should we create it (the STU3 link doesn't work either)

16605 - Please correct the typo in Resource Content section, columnn "Description and Constraints" for element Link->Other - 2018-May Core Norm Patient #25
The typo will be corrected.
Drew moves as persuasive, Brian seconds.
Vote: 7/0/0

16609 - Please fix the link below the Resource Patient - Extensions & Profiles text that does not appear to take the user to the correct page. - 2018-May Core Norm Patient #31
Not persuasive since the link accurately takes the user to the search of the FHIR profile of the registry.
Discussion: non3
Vote: 6/0/0

17186 - Marital codes identified do not clearly delineate current marital status.
The WG reviewed the valueset and determined that that element defines the current status. It could be that the issue is with the Patient.maritalStatus definition, which states “This field contains a patient's most recent marital (civil) status”

Therefore the WG feels it is fine as is.
Irma moved to disposition this is not persuasive, Alex seconds.
Vote: 6/0/0

Meeting Outcomes

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

Wednesday Q4

HL7 Patient Administration Meeting Minutes

Location: Maritime Hotel, Cologne, Salon 20 Fulda

Date: 2018-05-16
Time: Wednesday Q4
Facilitator Irma Jongeneel Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 Netherlands
X Brian Postlethwaite HealthConnex, Australia
X Alexander de Leon Kaiser Permanente, USA
X Andrew Torres Cerner, USA
X Simone Heckmann HL7 Germany
X James Agnew Smile CDR, USA
X Cooper Thompson EPIC, USA
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  • Encounter type codes don't accomodate "long term stay"
  • Reorganize the elements of Encounter for better tracking ablitities
  • Encounter needs staus code "waiting"

As time permits:

  • Consider property name clarification for Encounter.class and Encounter.type
  • Remove reference to Procedure as an option in Encounter/diagnosis
  • Add a principalDiagnosis extension for use on Encounter
  • The name primaryDiagnosis is quite misleading, revise

If we are bored:

  • Encounter resource maps to HL7 V3 RIM PatientEncounter class
  • Encounter.location needs more detail
  • Suggest align discharge disposition valueset with v2...

Supporting Documents

  • 14230 - Encounter type codes don't accomodate "long term stay"
  • 14157 - Reorganize the elements of Encounter for better tracking ablitities
  • 13702 - Encounter needs staus code "waiting"

As time permits:

  • 14307 - Consider property name clarification for Encounter.class and Encounter.type
  • 13668 - Remove reference to Procedure as an option in Encounter/diagnosis
  • 13667 - Add a principalDiagnosis extension for use on Encounter
  • 13663 - The name primaryDiagnosis is quite misleading, revise

If we are bored:

  • 14153 - Encounter resource maps to HL7 V3 RIM PatientEncounter class
  • 13539 - Encounter.location needs more detail
  • 12895 - Suggest align discharge disposition valueset with v2...

Minutes

Minutes/Conclusions Reached:
Introductions

The WG considered and reviewed Cooper’s update to the Patient Gender and Sex
Patient Gender and Sex
Gender is a social property, which is heavily influenced by social and cultural context. Sex is a collection of biological properties which are testable and which can affect the clinical care a patient receives. However in practice, many systems and organizations only provide for a single property that aspires to represent all aspects of a patient’s gender and sex with a single value.
Administrative Gender - in order to interoperate with systems that use a single generic property, the basic Patient.gender property attempts to represent an administrative gender: the gender that the patient is considered to have for administration and record keeping purposes. This property is often used as an input to patient matching algorithms, for example.
In addition to this administrative gender, other kinds of gender or sex properties may be represented:
Gender Identity - an indication from the patient about what gender they consider themselves to be. This can influence how the patient prefers to be addressed by care providers and other individuals. The standard genderIdentity extension is available to communicate this property, which is associated with the LOINC code 76691-5 . This extension is appropriate when the gender identity is openly known.
Clinical Gender - an observation about the patient, often collected as part of social history documentation, and represented as an Observation, typically using the LOINC code 76691-5 ). These observations may use the same LOINC code as the genderIdentity extension. Clinical gender observations can provide both history and confidentiality, where the genderIdentity extension does not.
Sex assigned at Birth - the sex assigned at birth, as documented on the birth registration. Some countries allow variations such as not yet determined, unknown, or undifferentiated, while others do not. Some countries also allow birth registration information to be updated. The US realm defines a US Specific extension for this property.
Legal Sex - regional and national entities often categorize citizens using a single legal sex value. The legal sex of a patient can vary from region to region and country to country. A single patient may have multiple legal sex values at the same time in different jurisdictions. In case where the Patient.gender administrative property is not sufficient to communicate legal sex, realm specific extensions should be used.
Clinical Sex - a testable observation about a biological property of the patient. There are several different types of clinical sex, including karyotypic/genetic/chromosomal, gonadal, ductal, phenotypic, etc. Clinical sex observations should be represented using Observation, qualified with the appropriate clinical codes from LOINC and SNOMED.
For veterinary use, the animal extension also includes the genderStatus which indicates sterility information.
After some discussion, the above text seems to take too strong a stand on Gender definition. Cooper agreed to reword it to be less controversial and keep the focus on what Administrative gender is.

  1. 14423 - Meaning of Ductal

Ductal sex refers to the developed ductal systems (either wolffian or mullerian) within the individual
wolffian duct regression/mullerian duct development is common in females
wolffian duct development/mullerian duct regression is common in males
Disposition this as Considered Question

Meeting Outcomes

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

Navigation

© 2018 Health Level Seven® International. All rights reserved.

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