Skip to end of metadata
Go to start of metadata


January 2019 HL7 WGM Minutes 


Monday

Monday Q1

Attendees 

2019 Jan WGM Attendance

Minutes 

FHIR planning was moved to Q1, on request by Grahame. If needed, 

Motion to accept the agenda was moved by Irma and seconded by Brian. Accepted 9/0/0

Grahame asked PA to consider to Practitioner, Organization, Practitioner_role and encounter to get  towards normative. Encounter is the resource that hasn't have much feedback, so that one will be hard. Especially the part of historic encounters is needed. Cerner is planning to use encounter and the ran into a lot of issues about the relationship between encounter, account and coverage. That will help to improve maturity. Also location and patient merge need attention. Patient merge maybe as an implementation guide, cause it may be hard to make it more than a best practice. 

PA will provide a sentence to Grahame that states the planned resources to make normative

Grahame introduced the way OpenEHR gets feedback on their architypes and would like to use a similar approach on/with FHIR as well. Brian suggested that the new VerificationResult resource that is used in the Validated Healthcare Directory Implementation Guide might be appropriate for this. Grahame wants to know if PA is an interested party or a co-sponsor for this, Brian indicated that we will start as an interested party. Grahame will prepare a PSS and get back to PA.

Grahame asked if PA have any resources that are not progressing and may go away. PA don't think that they have any resources that will go away but are struggling a bit with getting progress with the overlapped resources with FM. Some resource proposals are still not approved.

Reviewing the Mission and charter.

  • Line Saele Notify EST to update the PA mission and charter based on the change that was approved in Baltimore.

Reviewing the 3 year workplan and updating to reflect the planning to move the resources Provider, Provider_Role, Location, Organization, Encounter and Endpoint and also the provider directory IG to normative in Sept 2020.

SWAT: add a threat to state the dependency with priorities with co-owned content other workgroups to get our work completed.

Motion to approve Mission and Charter, 3 years workplan and SWAT was moved by Irma, seconded by Dan was approved 10/0/0

Vocab: 14341 was accepted to update the definition for AdministrativeGender value Undifferentiated to replace hermaphrodite with intersex since the term hermaphrodite is no longer used as the clinical term for that. Nancy will check with Ted to see if this needs to go to harmonization or not, since it s not changing any codes but only the definition.

  • Nancy Orvis  to check with Ted if this needs to be a harmonization proposal. 


Monday Q2 

Attendees 

2019 Jan WGM Attendance

Minutes 

Reviewing the security category for the FHIR resources. This is a new category that was added to the Resource definituons. Catories are: anonymous, business, individual, patient, not classified, not applicable. See this link for clarifications: https://hl7.org/fhir/security.html#SecPrivConsiderations. SuggestedSecurity to change the name Not classified to something else to not imply unclassified. Suggestions: Conditional, Special handling

  • Cooper Thompson to create a tracker (20002) with the comments/feedback on the Security categories.

Question: can resources be in multiple categories? Discussion about the usefulness of defining this on a global level, since business rules and/or local legislation will most likely overrule this on implementation level anyway.  It may even be risky if this is going to be interpreted as the source of truth, overruling local rules and laws.

  • Brian Postlethwaite to check with FMG is this was really thought through and identifying the risks.

 The levels do not define a hierarchy, maybe that would be a good idea. General rule of thumb: if the resource references an individual, the security category should always be at least Individual. If it references a patient, at least Patient category is applicable. If FMG agrees, this should be applied to all the resources.

If more than 1 category is checked, it s conditional. We need room to define the conditions.


AnonymousBusinessIndividualPatientConditionalNot Applicable
Account  2
?
Y?
Appointment  3
?
Y?
AppointmentResponse  3
?
Y?
ChargeItem  0


Y

ChargeItemDefinition  0?Y

?
Encounter  2


Y

Endpoint  2
Y



EpisodeOfCare  2


Y

HealthcareService  2?Y

?
InsurancePlan  0





Location  3





Organization  3?Y

?
OrganizationAffiliation  0?Y

?
Patient N


Y

Person  2
?Y
?
Practitioner  3??Y
?
PractitionerRole  2?Y?
?
RelatedPerson  2

?Y?
Schedule  3
Y
??
Slot  3
Y
??
VerificationResult  0
Y?
?







Not ours





CareTeam
Y
Y?


Maturity levels

Reviewing the maturity levels and define the goal for the next ballot for each resource.

Account  2

3


Appointment  3

3

increasing breadth

AppointmentResponse  3

3

increasing breadth

ChargeItem  0

2


ChargeItemDefinition  0

2


Encounter  2

5 (N)


Endpoint  2

5


EpisodeOfCare  2

3


HealthcareService  2

3


InsurancePlan  0

2


Location  3

5 (N)


Organization  3

5 (N)


OrganizationAffiliation  0

2


Patient N

N


Person  2

3


Practitioner  3

5 (N)


PractitionerRole  2

5 (N)


RelatedPerson  2

3


Schedule  3

3

increasing breadth

Slot  3

3

increasing breadth

VerificationResult  0

2



Resource Proposals

Invoice: status: PA approved. The proposal was updated.

ChargeItemDefinition

VerificationResult

  • Brian Postlethwaite to check with Lloyd what needs to be done to move this forward and get approval.

Reviewed the QA results.

Monday Q3 

Attendees 

2019 Jan WGM Attendance

Minutes 

tracker 13702 - Summary: Encounter needs status code "waiting" 

The workgroup continued with this tracker. Simone asked to look at the last update which reads:

"According to them, the reason why the Encounter status ValueSet seems off is that we’re mixing two things here:

1. the status of the Encounter itself ( planned, in-progress, cancelled, entered-in-error)

2. the status of the Patient in regards to the Encounter ( arrived, on-leave, triaged)

I think this statement nails it and propose the following change:

a) reduce the Encounter.status values to values in 1.

b) add Encounter.patientStatus (CodeableConcept) with extensible Binding to values in 2."

Brian noted that that there were other elements that had dual statuses, such as appointment status versus appointment cancel status.

The Workgroup discussed how there could be various statuses for the encounter that may differ from the "patient" status, (e.g. encounter could be "in progress" while patient is "triaged", "on leave", etc.). The workgroup considered what the naming convention would be for the "patient status" concept. Workflow status was considered but then the element would have to follow the workflow pattern.  Brian asked abut the value set. The workgroup discussed and decided whatever the name, it should be extensible.

The workgoup discussed separating out the patient status into a movement status. Brian noted also that in the updates to the tracker there was a task resource that had a business status. This element could be included to split the status concepts. However, some in the workgroup didn't feel comfortable to describe the presence of the patient (e.g. arrived, on leave, etc.) as business status.

The workgroup agreed that the 2 statuses are needed, and since this will be reviewed by the community, the group reluctantly decided on "subject status" (as distinct from the Encounter status), to include for community feedback.


Encounter statuses

Planned

In Progress,

Completed, 

Cancelled

Entered in Error

On-Hold

Unknown


Business/Subject Status

Arrived

Triaged

On Leave

Departed


Cooper suggested that we review any items referring to the (patient/subject) "movement" concept.

Simone noted that there was a tracker item to address the "movement" concept, (14157) but it does not have any update that would help move this discussion forward at this time. If this is resolved before the above changes, then subject/business status may not be needed within the encounter resource.

There was some discussion on whether "stopped" should be included based on use cases where encounter is started but interrupted for some reason (e.g. surgery interrupted because patient has a cold).  The general idea was that it would not be included to allow extensibilty for different types of "wait" scenarios.

At this point the quarter ended. This will be taken up again after the break.

Monday Q4

Attendees 

2019 Jan WGM Attendance

Minutes

The WG began with introductions. 

There was an open stage.

Suggestions: Patient Merge & Link, review Vhir Guide - publishing.

The WG started discussing Patient Merge & Link

Drew wondered if this should be a priority for R5. It was noted that the PAWG merely declares the challenges involved with merge/link however it does not define expectations of what clients should do. Irma asked if we could merely described what a client should do with what is already in the spec rather than fully describe interactions and use cases.

Brian wondered if the other issues (e.g. coverage, account, etc) that might be considered more of a priority, are done on the wrong account due to the inconsistencies with link/merge, then it's more of a foundational issue. Drew countered that he agrees that it is an issue and is important but link/merge have work-arounds whereas with the other noted issues, there is a gap that disables moving forward with implementations.

Brian offered whether there should be a sub group created within our PAWG to explore and analyze the merge/link issue to address. Brian asked who would like to participate. Drew (Cerner), Cooper (EPIC) and Charles Ye.

Each can describe what their specific merge/link process is and propose any good solutions..

Brian created a project on the confluence page. Alex noted that PSSs need to be approved soon. 

See Projects for Patient Administration - Merge and Link project in confluence for scope and more information.


Connectathon report - 

Directory  - documented on confluence. Reviewed by Brian.

Validated Healthcare Directories

The WG reviewed the participations. There was interest from Medicare/Medicaid (US) and Canada HealthInfoway which might be able to implement.

Based on the results of the connectathon, resulted changes will be included in the next version. These changes do not substantially change the content, so the path to publishing can continue. Can't publish now but close. Expected timeline is approximately a month or two.

With the remaining time, the WG continued to look at the tracker count: 80. These have essentially been deferred to R5.

Irma suggested we review these tracker items to see what they cover.


The WG continued with 13702 which was left open last quarter.

Brian reviewed the work down last quarter. 

The WG continued with the development of the Encounter status and Subject status. 

"stopped" was not included in Encounter.status value set and "waiting" (the subject of this tracker) was not included in the Subect.status.

Drew noted that "arrived" on encounter makes no sense. However, the group noted that this is needed for emergency workflows.

After these changes, a full QA review will be done on the encounter and value sets.

The definition of arrival will include verbiage on how arrived is used for emergency scenarios.

Within the status management, the second paragraph will be updated to differentiate the two statuses as it currently attempts to explain the one patient status.

The 3rd paragraph describing leave will be updated to consider both status properties and how local systems may have multiple types of leave/hold reasons.

This does not address the status history as this subject will be addressed in another tracker item: 14157.

Simone moves to disposition this persuasive with mod, Brian seconds.

Discussion: None

Vote: 12/0/2

Tuesday

Tuesday Q1 

Attendees 

2019 Jan WGM Attendance

Minutes 

Joint session with FHIR infrastructure.

Josh Mandell is here representing where Ewout normally attends. 

The WG began by discussing the CareTeam in VhDidr Guide. Brian noted that the search parameter for name was extended to include aliases. This was declared to be sure it does not violate any FHIR infrastructure.  Brian showed the search parameter in their extension with the canonical URL.

Eric Haas logged a tracker 

20012 Summary: add 'name' search parameterc 

add search parameter 'name'  to CareTeam 

add alias element as element or standard extension and include this in the search parameter definition for name so search will look at both the name and alias elements.

See definition in VHDIR:  http://build.fhir.org/ig/HL7/VhDir/SearchParameter-searchparameter-careteam-name.html

Next the WG reviewed Security Categorization 

20002 - There were a few observations PA made when reviewing the security categories for our resources:

"* It would be useful to have a link from the security category tab of https://www.hl7.org/fhir/resourcelist.html to the page that describes what the security categories are https://www.hl7.org/fhir/security.html#SecPrivConsiderations

* For resources that have different categories depending on context, should those be in multiple categories, or in Not Classified?  E.g. Slot can be a patient slot or a practitioner slot, and thus either in Business or Patient contexts.

* Not Classified seems like a mis-nomer.  That category really seems to mean "Context-specific Classification" or "Conditional Classification" or "Special Handling", where the classification can vary based on context and content.

* The description of Individual is confusing as it references CareTeam, which is Patient context not Individual.  I think the intent was that CareTeam.participant members would be Individual context, but that is really saying that any resource that references Practitioner or PractitionerRole resources should be Individual context.  Also, anything that references Patient would be Patient context.  (which make sense if a specific resource can have multiple contexts).

* One suggestion we had was to allow WGs to tag each resoruce with multiple contexts, rather than use the "Not Classified" category.  For example, Slot would be tagged as both Patient and Business context.

* If we support multiple classifications, can we have a spot to indicate under which conditions the resource would be under the specified classifications.

* Also, it seems like we could just identify a few set of foundational resources, and the context of those resources (e.g Patient is classified in the Patient category, Person/Practitioner in Individual, etc).  Then we can derive the context of everything else based on references."

The WG reviewed the table that attempts to categorize the resources for access control. Because the context is very implementation specific, the WG questioned the value of the table if too many categorization boxes are checked. The WG reviewed the FMM for the resources that PA is steward for.

The question was asked about what more FHIR work was on our plate. Brian noted that the PAWG has created a project for Merge and Link and operations and what the expectations there are for endpoints.

The WG reviewed what might yet to be pushed to normative. This includes patient match operations and search parameters. 


Josh noted that there was no name search parameter on care team. This means that the alias extension can be added more easily.

The WG reviewed the Encounter resource. Irma noted that there is an effort to include a "movement" concept. This is to express the movement of the patient through the business of providing care (e.g. ED to triage, to inpatient, to discharge. The WG is still hashing out which elements would be grouped together in this "movement" resource. 

The WG also noted that the status was "split" into 2... one for the encounter and one for the patient.

The group then discussed a bit around movement and how it would be expressed. 

The WG continued with the trackers.

Irma noted that we need to ask about changes to normative portions of patient..

Patient has 11 items (trackers) opened against it. Since doing a deeper dive into these, the WGwanted to know what can be worked on. Operations, since it is not normative, can be updated but what about changes to normative. Josh noted that there a set of rules guiding updates. You can add things but not change things that are already there. The main idea is this should remain forward compatible. Future systems should be able to use the resources. The WG began to look at the patient tracker items (post normative):

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.)

This does not change the Patient resource

15841 -  Summary: Patient.contact lists guardian as a use case, but code system for Patient.contact.relationship does not include a code for guardian. 

Patient.contact lists guardian as a use case, but code system for Patient.contact.relationship does not include a code for guardian. 

http://build.fhir.org/v2/0131/index.html

Suggest creating a value set that is complete for the use case, or at a minimum creating a guardian example so implementers know the recommended code and system to use. Suggest GUARD from RoleClass: 2.16.840.1.113883.11.11555 to align with CDA). 

Since this expands the set, and does not prevent future systems from implementing (forward compatible) this could probably be done. 

20003 -  Summary: Definition of Patient:name search parameter has a type and is overall unclear 

Alexander Henket moved to disposition this persuasive with mod.

Update the typo and remove the duplicate suffix.

Discussion: None

Vote: 17/0/0

19672 - Summary: Create Patient example for patient sex and gender 

We have a decent narrative section about sex and gender, however I'd like to add a good example as well.  Attached is my proposal.

Outstanding questions:

* Can I include the us-core-birth-sex extension in an HL7 example?  I'd like to...

* Are there copyright considerations for using Nia Nal as the exampe patient

TODO:

* Add a text element that describes the patient's transition history.  I.e. born male, now transgender female, legal gender updated in CA, but not yet in NV.  KS doesn't allow non-correction legal gender updates so that still aligns with birth sex.

* Update the to-be-determined.org URLs

* Potentially add an extension to patient.gender to add a sub-code for other

patient sex and gender example.xml

The proposal is to include the attached as an example.



Tuesday Q2 

Attendees 

2019 Jan WGM Attendance

Minutes 

Introductions

The WG began with the review of the Provider directory. This is now in confluence.

Validated Healthcare Directory

The path to publication was updated to connectathon. This connectathon resulted in tracker items which will now be addressed.

First the WG showed an overview of the Implementation Guide.

Brian reviewed that there was one capability statement. Security was basic guidance and examples.

There was consideration to add Example to include (HL7) github VhDir examples

https://github.com/HL7/VhDir/tree/master/notes_and_tools/example-generation/examples/20181206-large

There should be a reference to this without including it.

There was some discussion on how to reference this.

The decision was to include references to github and confluence

The group reviewed the implementation guide and solicited feedback.

Brian noted that there were discussions around provenance versus verification results. There was an example of a violin and legal evidence that conveyed that provenance is about history and ownership while verification results are essentially like an appraisal to validate the authenticity of the item/data.

18808 Summary: The VH Dir Restriction needs to expanded/clarified. - VHD #16 

emails merely result in the following update:

"Careteam-status parameter

add modifier to Careteam-status parameters"

More research is needed to discern any needed changes to the CareTeam profile.

19752  Summary: Search parameters from the core specification have been recoded and re-uri'd 

Brian moved to disposition this as persuasive. Michael Donnely seconded.

The core search parameters that have been incorrectly given new URIs will be corrected simply use the core search parameter definition.

Discussion: None

Vote: 13/0/3

19757 Summary: Should be either coding, or required binding 

http://build.fhir.org/ig/HL7/VhDir/StructureDefinition-identifier-status.html

Brian noted that the Australian individual healthcare identifier statuses differ from the ones here.

So a motion was made by Eric Haas to disposition this as persuasive with mod. This means to make these as required.  Dan Chaput seconded 

Discussion:

Included in this is a "issued in error" should have hyphens. Typo from "inctive" to "inactive".

The WG noted that similar status values were conveyed differently. Irma noted that his could cause confusion since it will be unclear if the meanings are the same. 

The group considered that making this required would help keep things consistent and "tease out" the edge cases.

Vote: 14/0/2

19758 Most VhDir locally defined search parameters have redundant resource name prefix 


Most of the VhDir locally defined search parameters have a prefix of the resource type, which is redundant and makes usage less intuitive and different to how the core defines them.


Remove these prefix values.


e.g. [base]/Practitioner?pracitioner-identifier-status=active
change this to
[base]/Practitioner?identifier-status=active


(And also update the resource narratives that describe the search parameter usage too)


Michael Donnely moved to fix this as suggested/ Eric Haas seconded.

Discussion: None

Vote: 15/0/1

19759 Summary: rename InsurancePlan serach parameters 


http://build.fhir.org/ig/HL7/VhDir/SearchParameter-searchparameter-insuranceplan-plan-coverage-area.xml.html


Rename the search parameters on InsurancePlan product-coverage-area and product-network to remove the product prefix (and also the resource name prefix before that too)


The properties aren't from the product, and I think the naming is from an earlier resource definition.

After taking a look into the search parameters, it was determined that product and plan used to exist separate elements but it was merged into InsurancePlan. 

Eric moves to disposition this as persuasive, Benoit Schoeffler seconds.

"prodiuct-coverage-area" to "coverage-area"

"product-network" to network

"product-identifier" to "identifier"

"product-type" to "type"

Discussion: None

Vote: 14/0/2

19760 Summary: Remove the target-location search parameter 

http://build.fhir.org/ig/HL7/VhDir/SearchParameter-searchparameter-verificationresult-target-location.xml.html


I don't believe that searching on this property is practical given that this is a fhirpath expression, and not something that I can imagine wanting to do.


The target property is the one that you're going to use, and then check across all verificationresults that apply.

Eric makes a motion to find this persuasive. Benoit Schoffler
Remove the search parameters on the fhirpath expression as requested.

Vote: 12/0/4

19761 - Duplicate

19771 - Summary: VhDir Location should include the core near search parameter 

Eric moved to find this persuasive, Dan seconded.

Discussion: None

Vote: 14/0/1

Tuesday Q3 

Attendees 

2019 Jan WGM Attendance

Minutes 

19761 - This was determined to be a duplicate in the previous quarter, however, it is slightly different. These search parameters will be update to use the core definitions for given and family.

Brian moves this as persuasive, Iryna seconds.

Discussion: The previous issues were around prefix and incorrect URIs. The search parameters should use the standard for "given" and "family".

Vote: 8/0/0

19768 - Summary: add summary view to CodeSystem pages ( just like Valueset pages) 

Brian moves as persuasive. Iryna seconds

Discussion: None

Vote: 8/0/ 

Table will be added to the CodeSystem page as requested.

Brian noted that there was only one item for validated directory, but otherwise it should be good to go.

  • Brian Postlethwaite  to check what the deadline is for the publication of the VhDir IG STU.

THe WG moved on to address the Patient tracker items

13601 - Summary: Common "patient" searchparam has non-patient target 

We  have found that the common search parameter "clinical-patient" (http://hl7.org/fhir/searchparameter-registry.html#clinical-patient) has two targets: both Patient and Group. This is surprising, since the methodology around "patient" parameters (in contrast to "subject") dictates that it has only the sole target "Patient".

I propose the Target for this search parameter needs to be limited to Patient.

The WG found that the description of the search parameter for Patient includes group. Irma had a concern of whether there is support for group patients. Brian showed that there is a search parameter "subject" which lends support for patient and/or group.

The work here would be to correct the descriptions of the patient search parameters in Encounter and ClinicalImpression to accurately note for patient, not group. THis will be addressed during the joint session with Patient Care Wednesday (Q2).

 14441 Summary: 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 rviewed Patient resource against RelatedPerson, Practitioner, Person. These will have the order of the equivalent elements updated to remain consistent with the Patient resource. In additional resources are added that match this "pattern" we may consider creating a formal pattern for an individual.

The WG developed a grid to assure that the ordering was correct based on patient. This was compared in a more detail level to Person, Practitioner and RelatedPerson. moves of elements were noted.

These will be updated.

A motion was made by Alexander Henket to disposition this as not persuasive with mod. Cooper seconds.

Discussion: None

Vote: 8/0/0

16040 Summary: Link to example Profiles is empty list 8/0/0


"...but may be found in profiles defined for specific jurisdictions "


The profiles link takes you to this page (http://hl7.org/fhir/2018May/patient-profiles.html) which states "No Profiles defined for this resource". 


Add profiles to that page, or update link to reference different location.

In the future we may expect to find some standard profile(s) appear under patient, so this link would still be correct, and as normative content, wouldn't want to have to come back and update again with this content.

The WG considerd this 

Alexander Henket moved to disposition this as non persuasive with mod. Cooper Thompson seconded. 

Discussion: None

Vote: 8/0/0

17487 Summary: Add issue about patient compartment to patient merge STU consideration 

In reviewing https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=15837, FHIR-I would like the STU note on Patient Merge to include the considerations of linking on Patient Compartment membership.

This text was updated in the closing states of R4 release and contains details requested.

Brian moved to disposition as persuasive, Alexander Henket seconded.

Discussion: None

Vote: 7/0/1

17536 - Summary: Extend Patient to add Race 

Brian moves this as not persuasive. Alexander Henket seconds.

Discussion: None

Vote: 8/0/0

Tuesday Q4

Attendees 

2019 Jan WGM Attendance

Minutes 

Introductions

FHIR tracking items.

Brian noted that there was an item that came up in Zoolip having to do with Common Law for patient.valueSet. 

Benoit moves to create a harmonization request to add the "common law" concept to v3 marriage value set. Alex de leon seconds.

Discussion: None

Vote: 6/0/0

FHIR Trackers

16230 Summary: Remove _type from Patient Operation Everything 

Including the _type parameter seems unnecessary given that this is an operation on the Patient resource. There is no need to specify _type, and the description could confuse implementers who may conflate them with the _include and _revInclude parameters (not that, I believe, those are used in the $everything operation either).

As noted below, this parameter is very useful for filtering to only the types that you are interested in.

[base]/Patient/42/$everything?_type=DiagnosticEvent,ReferralRequest,Appointment

The results then don't include any observations that I'm not interested in for this request.

Therefore we will keep the parameter

Alex de León moves to disposition this as not persuasive, Irma seconds

Discussion: None

Vote: 5/0/0

17362 Summary: Date filtering on $everything operation 

Clarification needed if the  start and end date parameters allowed on the $everything operation(https://www.hl7.org/fhir/patient-operations.html#everything) and (http://build.fhir.org/patient-operation-everything.html) can also follow the same behavior described in the date search including the use of prefixes (eq,gt,ge etc.) (http://hl7.org/fhir/DSTU2/search.html#date). It is a little confusing since in the regular date search, the same "date" parameter is used to specify the lower and upper bounds whereas here two separate parameter values "start" and "end" seem to indicate the bounds. Also, it would be great to identify which of the dates in resources in the Patient compartment qualify as 'care date'.

This was discussed, and taken to zulip for further discussions, and input from FHIR Infrastructure.
https://chat.fhir.org/#narrow/stream/179280-fhir.2Finfrastructure-wg/topic/.24everything.20or.20.5Bcompartment.5D.2F*

17627 Summary: Family and given names reversed in Patient-example-a.json 

"name" for this patient example reads:

"name": [ { "use": "official", "family": "Donald", "given": [ "Duck" ] } ],


However, it should be:  "name": [ { "use": "official", "family": "Duck", "given": [ "Donald" ] } ],

Cooper moves to disposition this as persuasive,Benoit Schoefller seconds

Discussion: None

Vote: 5/0/0

19687 Summary: Query for data on a Patient when that Patient has been linked 

This item will be deferred for work from the Merge and Link project team.

15841  Summary: Patient.contact lists guardian as a use case, but code system for Patient.contact.relationship does not include a code for guardian. 

Patient.contact lists guardian as a use case, but code system for Patient.contact.relationship does not include a code for guardian. 

http://build.fhir.org/v2/0131/index.html


Suggest creating a value set that is complete for the use case, or at a minimum creating a guardian example so implementers know the recommended code and system to use. Suggest GUARD from RoleClass: 2.16.840.1.113883.11.11555 to align with CDA).

Irma proposed that we find out the options for referencing the tables. Today, this refers to v2 tables but is the WG able to reference another value set (v3 for example). Brian proposed inviting Lloyd to attend the PAWG sometime this week to give us the direction.

Adjourn

Wednesday

Wednesday Q1 

Attendees 

2019 Jan WGM Attendance

Minutes 

Introductions

FHIR work/trackers

The WG reviewed the trackers that will be covered jointly with patient care to be sure the group is prepared.

  • GF#14199 - Summary: Open up Task.context to reference other resources. An  ambulance dispatch central (organization) would like create a task for each ambulance (location) that is to drive to a crash site (currently the basic resource as there is nothing that really models an accident). Currently, Task.context can only point to Encounter/Episode of Care. Could Task.context be opened up to point to other resources - in my case I guess 'Any' would do ;)

It appears that there was further discussion within the tracker that diverted the issue to EpisodeOfCare being tightly bound to Patient and a potential need to open this up to include Group. However, after reviewing the tracker, it is clear that the request was to allow task to point to other resources. 


PA San Antonio WGM 16 Jan 2019:


Re-looking at this issue the episode of care doesn't appear to be appropriate as Jens has highlighted, before the patient arrives. We think that the Task.focus for the dispatch of the ambulance would be the incident/accident (basic) resource, and Task.for would be the ambulance (location) - we assume that your incident model would have the details on where the incident is taking place (so the ambulance can get there).


PA would also request to review your incident basic profile for consideration/inspiration to create a new resource to potentially include in R5.

  • GF#15177 - Summary: Does CareTeamCategory: Episode need to be linked to another Category for context? - 2018-Jan VHD #8 . Does CareTeamCategory: Episode need to be linked to another Category for context? The WG further investigated whether this was necessary to review with Patient Care. 

    The Implemantation Guide should define a specific extensible valueset for its usage of CareTeams, that excludes patient specific concepts.

    This could be a restriction on the existing valueset, but we anticipate there will be other concepts included.

  • GF#13601 - Summary: Common "patient" searchparam has non-patient target.

    We  have found that the common search parameter "clinical-patient" (http://hl7.org/fhir/searchparameter-registry.html#clinical-patient) has two targets: both Patient and Group. This is surprising, since the methodology around "patient" parameters (in contrast to "subject") dictates that it has only the sole target "Patient".

    I propose the Target for this search parameter needs to be limited to Patient.

The WG continued to look at trackers regarding the Encounter resource that we might want to discuss in the joint session. Irma noted that we might want to socialize the idea of restructuring the Encounter resource to support patient movement through care flow. (tracker items 14157/14230).

Brian wondered if 14307 (- Summary: Consider property name clarification for Encounter.class and Encounter.type ) should be discussed with patient care. It was added to the agenda to discuss with them.

16148 Summary: Encounter.reason and Encounter.diagnosis 

Recommend further updating and clarifying Encounter.reason and Encounter.diagnosis.  It seems the intent is to represent reasons for the encounter that can be either diagnoses or procedures in these two attributes, with one being a code and one being a structure. However, the approach is confusing, as is the name (e.g., why is a procedure called a diagnosis?).  Also, the Encounter.diagnosis.role (DiagnosisRole) is insufficiently expressive as a 0..1 attribute.  For example, the approach does allow saying -- facility billing discharge diagnosis.  Recommend making this attribute 0..* and adding notions of facility vs. professional billing.  Also, recommend clarifying how to rank diagnoses and procedures expressed by the reason attribute. Suggest also reviewing CIMI modeling for this concept for potential synergy.

17304 Summary: Encounter needs a outcome element 


There is a need for an outcome of the Encounter as a CodeableConcept 


Cloned from 16238, as that was improperly included in ballot comment against FHIR Infrastructure and must be closed as not-related. This will be included in the agenda to discuss with Patient Care.

17519 - Summary: Extend Encounter to add an Encounter Name 

The BR&R Team would like to extend Encounter to include a name.  In Clinical Research, encounters (visits) are given names to reflect either their sequence or purpose (e.g. Pre-screening Visit, Visit 1, Follow-up Visit).  

We would like to add a name attribute (string) to the Encounter resource. 

PA San Antonio WGM 16 Jan 2019:

https://chat.fhir.org/#narrow/stream/179254-patient-administration.20WG/topic/Follow-up.20on.20.2317519

After further discussion and reviewing the notes on Zulip, the Encounter.type property being used as described there could be appropriate.

19285 - Summary: Move ranked billing diagnosis and procedures from Encounter to Account 

During discussion of GF#18829, we opted to leave Procedure as an allowed reference from Encounter.diagnosis.condition, however we weren't really super comfortable with that.

The thing that we want to communicate is the ranking of diagnoses and procedures for the purpose of billing.  I think this might make more sense to move into Account, rather than Encounter (this merits discussion though).

 My tentative suggestion is to:

* Remove Procedure as an allowed reference from Encounter.diagnosis.

* Remove Billing from the Diagnosis Role valueset: http://build.fhir.org/valueset-diagnosis-role.html

* Add two backbone elements to Account:   Acount.diagnosis and Account.procedures:

Account.diagnosis  0..*  BackboneElement

     condition  Reference(Condition)

     type       CodeableConcept

     rank     positiveInt

Account.procedure  0..* BackboneElement

      procedure  Reference(Procedure)

      type       CodeableConcept

      rank    positiveInt


This moves the ranked procedure and diagnosis info into Account, which I think is where it belongs.  It also makes the Encounter.diagnosis property very clearly only for diagnoses.

Wednesday Q2

Attendees 

2019 Jan WGM Attendance

Minutes 

Joint with patient care.

Michelle noted that Patient Care is proposing to make CareTeam normative in R5. Irma noted that Patient Administration is targeting Encounter/Location/Organization/Practitioner/PractitionerRole to be normative in R5.

16148 - Summary: Encounter.reason and Encounter.diagnosis 

Recommend further updating and clarifying Encounter.reason and Encounter.diagnosis.  It seems the intent is to represent reasons for the encounter that can be either diagnoses or procedures in these two attributes, with one being a code and one being a structure. However, the approach is confusing, as is the name (e.g., why is a procedure called a diagnosis?).  Also, the Encounter.diagnosis.role (DiagnosisRole) is insufficiently expressive as a 0..1 attribute.  For example, the approach does allow saying -- facility billing discharge diagnosis.  Recommend making this attribute 0..* and adding notions of facility vs. professional billing.  Also, recommend clarifying how to rank diagnoses and procedures expressed by the reason attribute. Suggest also reviewing CIMI modeling for this concept for potential synergy.

Although this appeared to be addressed, Michelle noted that this was actually deferred.

Brian noted that there are two efforts to take condition/use/ranking elements under diagnosis into either Encounter, Account and Condition resources.

The WGs discussed the use of condition and the use/role of that condition. Rank and Role elements are needed for the condition, but it is unclear where it should go, which resource. There are billing processes and considerations that are distinct from clinical processes and considerations. EHR has rank and role that might differ from ranks and roles in other systems (that might not be clinical).

  1. Put the diagnosis rank and role on Condition
  2. Put the diagnosis rank and role on Account
  3. Put the diagnosis rank and role on Encounter

The WGs discussed that this is becoming more urgent as both have resources that the groups are trying to push to normative. Therefore both WGs have decided to address this in a joint telecon in the next few weeks. Target date/time January 30 3pm eastern time.

14199 – Open up Task.context to reference other resources 

Case is the following:

An  ambulance dispatch central (organization) would like create a task for each ambulance (location) that is to drive to a crash site (currently the basic resource as there is nothing that really models an accident). Currently, Task.context can only point to Encounter/Episode of Care. Could Task.context be opened up to point to other resources - in my case I guess 'Any' would do ;)

PA San Antonio WGM 16 Jan 2019:

Re-looking at this issue the episode of care doesn't appear to be appropriate as Jens has highlighted, before the patient arrives. We think that the Task.focus for the dispatch of the ambulance would be the incident/accident (basic) resource, and Task.for would be the ambulance (location) - we assume that your incident model would have the details on where the incident is taking place (so the ambulance can get there).

PA would also request to review your incident basic profile for consideration/inspiration to create a new resource to potentially include in R5.

The Patient Care work group noted that there is an AdverseEvent resource that might be related or might add value for connecting the task in the submitter's case.

The Patient Care work group will be discussing the AdvesseEvent today at Q4 This tracker will be left open for more input.

The concept of an "Incident/Accident" was discussed, and if such a resource was created then this would need to be differentiated from AdverseEvent, and how this would be interacted with the new resource.

15177 - Summary: Does CareTeamCategory: Episode need to be linked to another Category for context? - 2018-Jan VHD #8 

the IG needs to be updated for specifica value set. So, there are patient specific ones which is why it was broought to the joint work group session.

13601-Summary: Common "patient" searchparam has non-patient target 

Brian offered to update the search parameters to include only patient.

Brian moved to disposition this as pursuasive/ Michelle seconded.

Discussion: 

Vote: 14/0/0

17304 - The Encounter needs an outcome element

The WG considered encounter outcomes being handled by other operations that support either creations of other events or conditions. The PAWG updated this tracker for more information from the submitter since it is unclear what the actual need is. The tracker was updated. 


The WG moved to discuss the VerificationResult resource.

VerificationResult - Michelle wanted to bring to the group that Care plan reviews are being done that might need this convention. So, it might mean that PA, who is the proposed steward of this new resource, will be asked to broaden the original scope of this resource. 

Irma asked if we will have the same timeslot for joint meeting at the next WGM.

  • Line Saele Schedule a joint meeting for the May WGM 2019  


Wednesday Q3

Attendees 

2019 Jan WGM Attendance

Minutes 

The WG reviewed the agenda and decided to take some time for the v3 ballot reaffirmation:

  • Patient
  • Personnel Management
  • Scheduling

Although the WG had seen one negative, Andrew Statler withdrew his negative. Reaffirmation has been complete.

19688 Summary: Search for Practitioners linked via PractitionerRole 

Before PractitionerRole was created it was easy to search for the practitioner associated with a particular resource. For example, /Procedure?performer=Practitioner/123. This would return all procedures where that practitioner was the performer.

With PractitionerRole added, I cannot think of a single query that would guarantee the same result, since some practitioners will be referenced directly from the resource, while others will be referenced indirectly via PractitionerRole.

We should consider:

* Providing expressions for all Practitioner search parameters that return direct and indirect results (preferred option); or

* Provide guidance on "standard" queries in these cases. For example "To find all Procedures performed by a particular practitioner, a client should combine the results of [direct query] with the results of [query via PractitionerRole]".

--

The indirect linking of Practitioners via PractitionerRole also raises questions about what should be included in the Practitioner compartment. Currently, a Procedure where the practitioner is performer would be included, and a PractitionerRole referencing the practioner would be included, but a Procedure referencing a PractitionerRole referencing the practitioner would not be included.

--

Several resources have elements that support direct references to Organization and indirect references via PractitionerRole. This causes a similar problem for finding all of a particular resource involving an Organization.

--

Procedure has been used as an example here. The issues arise with any resource that has an element that can reference either a Practitioner or PractitionerRole, or reference an Organization or PractitionerRole.

Similar issues may arise with other resources that introduce indirect linkages. For example, a DiagnosticReport may record the performer as a Practitioner or as a CareTeam; a Practitioner may be a member of a CareTeam; searching for reports performed by the practitioner will miss those where they were part of the care team. Both the PractitionerRole and CareTeam examples are related to Practitioner, but we should look for other places subject to the same challenges, e.g. resources that can reference a Patient, or a Group of which the patient is a part, and so on. This is a good candidate to submit to FHIR-I. 

  • Brian Postlethwaite will submit to FHIR-I for further direction. Subsequent to that there may be a need to meet with the FMG.  

19961 Summary: Practitioner Qualification description should include the word licensure

Practitioner qualification is often thought of as licensure designation.  It would be good to add this to the element in the description

From Quality representatives at FHIR Connectathon

The WG considered this and decided to update the description from "For example, a medical license issued by a medical board authorizing the practitioner to practice medicine within a certian locality" to "

For example, a medical license issued by a medical board of licensure authorizing the practitioner to practice medicine within a certain locality"


Also on the short description of the property, include qualification:


"Certificationsqualifications, licenses, or training pertaining to the provision of care"


Irma moves to disposition this as persuasive with mod. Brian seconded.

Discussion: None

Vote: 4/0/0

17634 -Summary: Add deceased attribute to Practitioner resource

The payer and pharmacy perspective would like the indication of deceased status be added to the Practitioner resource.  The added data element would mimic the same structure as what is found on the Patient resource. This deceased element would be most beneficial in verifying the validity of a prescription being properly issued.  Prescription fraud very often occurs post-humously of prescribers as systems catch up to the event.

The proposed data element would look like this:

deceased[x]  0..1  -> deceasedBoolean(boolean) | deceasedDateTime(dateTime)

"Indicates if the individual is deceased or not."

The WG understands the use case and potential value of this and continued to discuss how prevalent this is and whether systems across domains would make use of this. After some discussion, it was decided to make this a standard extension, not part of the core specification.

Irma moved to disposition this as persuasive and make it a standard extension on the practitioner resource. Alex seconded 

Vote: 4/0/0

17414 Summary: PractitionerRole extension for FHIR STU3 

Since Practitioner was split into PractitionerRole and Practitioner in R3 without a review of the full impact, I'm suggesting we create a global extension on Practitioner pointing to either Organization or PractitionerRole that is usable in any context that contains just a Practitioner (Condition.asserter, Composition.author, etc.) such that the Organization info can be preserved. 

  • Brian Postlethwaite to work with FMG on how to create an extension to a previous version of the specification  

14415Summary: HealtcareService & Practitioner does not support a contact with specific purpose 


In most scenarious it is required to define the purpose of a contact point (telephone, email, etc) such as Emergency Number, After Hours. 


Within the Organisation resource, the attribute Organisation.contact was introduced to support this requirement. However this is not possible within FHIR 3.0.1 at this time within HealthcareService & Practitioner.


The recommendation is to apply the same concept for "contact purpose" as defined in Organisation to HealthcareService & Practitioner.


eg. HealthcareService.contact & Practitioner.contact. 


This approach would align the mechanism to define contacts with specific purposes across most FHIR Resources.


Another approach would be to add support for "purpose" (not the "use") to "ContactPoint" & "Address".


eg. ContactPoint.purpose & Address.purpose

THe WG reviewed this request and can see the value of including this in HealthcareService and Practitioner. THe decision was made not to change the telecom but to add the structure of contact similar to Organization.contact around 

Brian moves to disposition this as persuasive with mod, making the above changes. Alex seconded.

Wednesday Q4

Attendees 

2019 Jan WGM Attendance

Minutes 

Although the agenda shows our work on Scheduling, the WG decided to focus on resources we want to move to R5

14141 Summary: Errors in R2 <---> R3 Converson maps for HealthcareService. 


The mapping to convert HealthcareService resources from R2 to R3 provided by the FHIR specification specifies that HealthcareService.serviceType.type from R2 is converted to HealthcareService.type in R3. (http://hl7.org/fhir/stu3/healthcareservice-version-maps.html)


 From FHIR Release 3 and the associated value sets, the understanding is that  the HealthcareService.specialty from R3 is the equivalent of HealthcareService.serviceType.type from R2, and HealthcareService.type in R3 has a different meaning. The mapping scripts should be modified to the correct meaning of HealthcareService.specialty from R3.

Brian researched and the mappings are correct.

Live moves to disposition this as not persuasive, Iryna seconded.

17250 Summary: "name | alias" are not valid FHIRPath search parameter expressions 


The "name" search parameter lists "name | alias" as the FHIRPath expression.


This should be changed to:


"ProductPlan.name | ProductPlan.alias"

Brian moved to disposition as persuasive. Iryan seconded.

Discussion: None

Vote: 5/0/1

15787 Summary: Add 'qualification' to Organization 

Would like to add the ‘qualification’ subclass at the Organization resource level.  This is the same as ‘qualification’ that currently resides in the Practitioner resource. 

This seemed a reasonable request to the WG. The structure will be added to the resource. However, there was discussion around the term "Qualification". Also there was discussion as to whether this should be "pulled out" as a separate resource unto itself.

For now the decision was to add the certification structure to organization, however, it will be named "Organization.certification" to mimic the "Practitioner.qualification".

The description will read "The official certifications, training and licenses that authorize or otherwise pertain to the provisions of care by the organization. Fore example a medical license issued by a medical board authorizing the practitioner to practice medicine within a certain locality.

Brian moves to disposition this as persuasive, with mod, Dan seconded.

Discussion: None

Vote: 6/0/0

15792 Summary: Description of Patient Trackers is strange 


"Patient Registers
Track people involved in receiving healthcare, the basics nearly everything else references back to"


I guess, we could do better...

Patient/Person Registries

"Track people involved in receiving healthcare, the basics nearly everything else references back to"

to

"Resources that contain details of people and animals that are either receiving care, or are associated with these subjects. Many other resources refer back to these as either the subject of care, or are somehow involved in that patient's record" 

Brian moves to disposition as persuasive, iryna seconds.

Discussion: None

Vote: 6/0/0

The WG decided at this point to draft of the project work that Patient Administration will engage in for R5.


During the development of FHIR R5, the Patient administration will be focusing on:


  • Moving the Encounter and several Service Provider Directory resources to normative status
  • Increase the maturity levels of many of our resources
  • Completing the VhDir IG
  • Patient Merge/Link directives/best practices
  • Better linkages between FM and PA resources (Coverage, Account, ChargeItem, Invoice, ChargeItemDefinition)
  • Many other changes/enhancements/new resources as needed/requested by the community


"Increasing the FMM status of many of our resources, including moving the Encounter and several service provider directory resources to normative status, improve the linkage between the administrative and financial domains, along with defining the patient merge/link functionality and completing the VhDir Implementation Guide."

Thursday

Thursday Q1 

Attendees 

2019 Jan WGM Attendance

Minutes 

  • Introductions

The WG began with an update with Hans concerning V2 to FHIR mapping. Hans presenting the 2-To-FHIR project, as this is definitely an overlap in our work.

Hans noted that vocabulary is mostly out of scope, mainly because vocabulary is being handled already, however, there are some who are already are identifying areas wehre vocab is not addressing.

Hans also informed the group that there will be participation in the May connectathon to develop v2-to-FHIR mapping tools.

In reviewing some of the difficulties, Hans gave an example the data types which seemed easy enough but it turns out that the v2 data types (at different levels) map to new constructs in FHIR (e.g. unique resources, datatypes, etc.). 

The WG determined that we should have a joint quarter in the next WGM during this same period (Thursday Q1).

  • Line Saeleto include joint session with OO for update Thursday Q1 

The WG reviewed the minutes from Baltimore

Motion Irma moved to accept the minutes, Christian seconded.

Discussion: None

Vote: 8/0/1

The WG continued with the ballot reconciliation of v2.9.

The WG blockvoted 

Irma moved to block vote on the dispositions as noted in the spreadsheet, Craig Newman seconded.

Discussion: None

Vote: 5/0/2


Thursday Q2 

Attendees 

2019 Jan WGM Attendance

Minutes 

The WG began with introductions in this joint session with Financial Management. 

Discussion began around some resource proposals. Brian noted that the resource proposal is still in the FMG for approval. Invoice was one that is joint with FM.

Invoice

The WG reviewed and discussed the Invoice resource proposal.

The WG worked on better clarifying the Scope of coverage section in the proposal, which currently reads:

"The existing Claim resource is constricted to use cases where Claims are sent to insurances for reimbursement, in a message-like style. It neither references ChargeItems nor Accounts

It doesn't not cover use cases where existing ChargeItems in an Account are used to create an Invoice to be sent out to Individuals or Organizations in a document-style.

Unlike the Claim resource it reflect the perspective of the (healthcare) service providing organization.

An invoice is a financial document issued by a Healthcare provider to a patient or a payer indicating the goods and services (ChargeItems) performed with their quantities and prices. The invoice is the hospital’s view, whereas the Claim is the payer’s view on the performed services."

See the current link for the updated verbiage as this was being done during the meeting.

The WG then worked on the Resource appropriateness section currently written as:

"Tracking Financial information is vital in Patient Administration and Finance systems in most Healthcare Organizations. This resource provides the individual items to track.

Competing invoicing standards such as EDIFACT or X12 are aiming at inter-organisational exchange and do not offer human readable representations or traceable links to services rendered which is a requirement for invoicing towards patients."

The Expected implementations was also reviewed and updated:

  • Any solution that tracks billing information and needs to issue invoices
  • Private Insurance Providers who want to deliver structured information to patients to increase cost transparency
  • Patient apps that want to include information on the amount and reason of the charged costs for the healthcare services a patient received
  • Interested parties: SAP, IBM, Association of Private Insurers in Germany
  • more interested parties: https://chat.fhir.org/#narrow/stream/4-implementers/topic/Invoices

Content Source

"Existing normative V3 and V2 specifications"

Example Scenarios was reviewed and updated

  • Invoicing between systems that primarily interact using FHIR API
  • Patient Apps

Patient apps may chose to not only give patients access to their health data but also to the charges assoicated with them (e.g. provide insight into the cost for medications, treatments and immunizations). Such apps will require structured invoices to allow association between the charges and the services rendered.

Apps can provide abilities to trace and compare costs or deliver additional information as to the meaning of specific billing codes.

It is convenient for both patientes and implementers to be able to exchange billing information through the same app based on the same standard as other information a patiant may want to take home from a doctor's visit or an inpatient tratment such as medication plans or lab results.

These internally created and processed FHIR based invoices may be mapped to other standards such as X12 for posting in external systems.

WG reviewed Timelines

"The aim is to have a draft (Maturity 0) ready for 4.0 timeline."

A motion was made by Paul Knapp to approve the update to the resource proposal. Brian seconded.

Discussion: None.

Vote: 10/0/0

The WG moved on to look at the ChargeItemDefinition resource proposal.

The WGs discussed this proposal and who ownership should be. This will be further discussed as the quarter has ended. At this point it is not clear whether it should be further developed, but which group should further the effort. 

FM and PA will have the same quarter next WGM.

Other Business

The announcement was made that Irma was reelected as co-chair. All congratulated her.

Thursday Q3 

Attendees 

2019 Jan WGM Attendance

Minutes 

Introductions

The WG discussed items having to do with FHIR management with Lloyd. Specifically, there were questions about changes to Patient (e.g. gender), what can be done? 

Patient can have multiple genders. Changing non-repeating element to repeating is permitted. However, Lloyd, noted the practical implications of this... of how unworkable this can be in practice. Adding a new resource to a reference is ok. Group is an example of this. Lloyed used this opportunity to ask if the PAWG would want to own this resource. 

Lloyd moves that PAWG agrees to assume responsibilities of the Group resource. Seconded by Irma.

Discussion: None

Vote: 4/0/0

Back to FHIR abilities for changes. Deprecation is allowed. 

Brian asked if it was permitted to change to those things that don't directly change "inside" the resource itself. Not allowed to change that which changes the content or usage. It is permitted to expand the scope. Essentially anything can be changed that will not effect the usage of the resource or it's content.

Merge and Link

Brian reviewed the area in confluence that will note the work done fore link and mege. 

The WG reviewed the action items with Lloyd as representative for FMG.

Lloyd was asked his view on the search operation for Practitioner versus PractitionerRole. He suggested more implementers be solicited involved before moving forward with a solution.

VhDir was discussed and it was determined to have no deadline

VerificationResult was discussed as distinct from Provenance. Lloyd had no objections to this distinction and prosposal.


Cooper reviewed some of the efforts he was involved in outside of the PAWG meetings.

Vocabulary - Around gender. There has been a X element added to the vocabulary for gender in V2 

Security - Categorization of resources. Security received a lot of feedback by groups around the names of the categories and appreciated the structures on where PAWG provided feedbak.

  • Line Saeleto find FHIR PSS and validate it is broad enough in scope and timeline to encompass the further work and R5.

VhDir

18808 Summary: The VH Dir Restriction needs to expanded/clarified. - VHD #16

Eric Haas suggested we address this since we had the group present.

The status search parameters modifiers are not needed.

Eric moves this as non persuasive. Alex seconded.

Discussion: None

Vote: 3/0/1

Wrap up

For the next ballots the following deadlines were assigned for the PSS's.

Planning to ballot an artifact in the May 2019 cycle? Email the Work Group Approved PSS to the PMO by January 27th.

Planning to ballot an artifact in the September 2019 cycle? Get TSC approval of the PSS by April 7th.

PA isnt planning on balloting new projects in the May ballot and  


Thursday Q4 

Attendees 

2019 Jan WGM Attendance

Minutes 

v2.9 reconcilliation


  • Irma Jongeneel Schedule calls to address v2.9 ballot 
  • Line Saele Schedule the regular (every other week) PAWG calls 




  • No labels