Skip to end of metadata
Go to start of metadata

May 2019 HL7 WGM Minutes 


Monday Q1


2019 May WGM Attendance



The WG discusssed the Agenda for the week.

Brian moved to approve the agenda Drew seconded.

Vote 7/0/0

The WG moved on to discuss the mission and charter. 

There were no changes to the mission and/or charter.

The WG continued to review the 3 year work plan. 

V2 was added and columns for 2020 were added. It appears to be up-to-date with the group's work.


The SWOT was updated.

Drew moved to accept the updates to the SWOT. Brian seconded

Vote: 8/0/0

Electronic service and tools liaison. The WG suggests that Alexander Henket be the liaison, with his presence and approval, with the condition that if V2 publishing is a topic, Alexander de Leon will attend any necessary meetings. There was discussion as to how this would work and whether it was acceptable to HL7.

  • Irma Jongeneel Irma volunteered to draft a response to the email request recieved by the co-chairs for this and make this suggestion.  

Irma moves to appoint Alexander Henket as the this liaison, with Alexander as a secondary resource, if this is allowed. Brian seconds. 

Vote: 8/0/0

The WG reviewed the QA status at  

Brian noted that Mary Kay had asked for an update to the agenda:

"Bob Dieterle would like to discuss the VhDir FHIR IG that is being proposed for the Da Vinci Project.

It is coming out of PSS 1489

There will be 3 IGs, PDex, Drug Formulary and a Payer network/directory."

  • Brian to check with FMG who owns ChargeItemDefinition  

The WG continued on to tracker status. 87 trackers still open

The WG continued with the review PA Resource Maturity Levels.

Brian asked about the efforts in The Netherlands around FHIR resources. 

Line noted that it is the responsibility of all (in the room) to report to Brian any FHIR resources are in production.

Alexander suggested that a matrix that shows the requested information that is needed to report these FHIR resources in production.

  • Brian to draft a matrix of necessary information for FHIR resources in production.  

Irma suggested that we review the  action items. which were reviewed one by one.

There was an item having to do with making search parameters normative as an action item. 

Brian moved to propose making search parameters normative, Drew seconded. This will be taken to the FMG.

Discussion: There was a question about address parameters that might be missing. Some can be added later by submitting a tracker item.

Vote: 8/0/0

  • Brian Postlethwaite Brian to take these search parameters to FMG to ask about the process to make these normative.  

Monday Q2 


2019 May WGM Attendance



The WG reviewed the path to publication of STU1 for the validated healthcare directory. As of now, the path looks like this:

Path to Publication of STU1

The WG reviewed this. The idea is that this work will be done for R4 before September. There seems to be a lot of work to move this forward, including a workshop in Washington DC   for any implementors.

 Irma suggested that because of this timeframe, we may consider a request for publication sometimes this week. Brian agreed that this could be done. The WG will need to review, vote and send a request to publish.

  • Line will investigate how to create a proposal for publication.   

Brian recommended that we create the proposal Tuesday Q2 when this subject will be covered. Irma will add this to the agenda.

FHIR trackers

Brian asked if there were any specific areas of question. The representative from google asked about how EMPI has been implemented. The WG discussed references as either from the Person resource as google has done to reference to other Patient resources in other systems which may have different demographics, or from Patient out to persons or patients. Brian noted that FHIR is flexible enough to do either. 

Tracker # 17362 Summary: Date filtering on $everything operation 

Clarification needed if the start and end date parameters allowed on the $everything operation( and ( can also follow the same behavior described in the date search including the use of prefixes (eq,gt,ge etc.) ( 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 also discussed in the FHIR chat on Zulip:*

The WG discussed and defined both the "*" and the "$everything" operations.

"*" will give you all the compartments associated with the resource. 

$everything - returns all the information related to one or more patients described in the resource or context on which this operation is invoked. (

PA San Antonio WGM 15 Jan 2018:

This was discussed, and taken to zulip for further discussions, and input from FHIR Infrastructure.*

An update was made by Brian to the above zulip 

A suggestion on how to define the "care dates" for each resource type would be to modify the CompartmentDefinition to include which search parameter would be applicable for care dates in the $everything date filters (start/end parameters) and describe how ranges would handled.

The WG moved on the FHIR QA tracking spreadsheet. Brian opened the FHIR QA Conformance Tracker

  • Brian Postlethwaite Brian to connect with other tech reviewers (Cooper, Drew, Simone) to complete qA on allocated resources and give a timeline..  

Monday Q3 


2019 May WGM Attendance



Tracker # 20511 - Summary: Encounter with a machine 

The introduction of AI into healthcare is creating a variety of patient/machine interactions that look a lot like traditional in-person or telehealth encounters.  Today, Encounter participants are limited to Practitioners and RelatedPersons.  Modeling a machine as a Practitioner seems most appropriate to the setting, but not well aligned with the definition or attributes of Practitioner today.

Mostly, looking for discussion, but would suggest that Encounter.participant.individual include references to Devices OR modification of Practitioner to include machines acting in an (semi)autonomous role.

The WG discussed this against the appointment.participant element as it has a similar construct. 


The WG noted that the Healthcare service might be covered by encounter.type encounter.service type that 

Review the Appointment.serviceCategory and appointment.serviceType to cover healthcare services so might be considered to be removed from Appointment.participant.

A new tracker was created 21634 to review the above, potential removal of healthcare service participant from appointment.

Irma moves to find this persuasive with mod with the changes. Alex seconded.

Discussion:  None.

Vote 6/0/0

Tracker # 20479 - Summary: Clarification about subject in Encounter 

A group of practioneers have a meeting about how to treat a patient. The patient is not a participant in the meeting. The encounter specification clearly states that the subject is present but Brian Postlethwaite thought a slight change of the Encounter type was in order:

"I think that the Encounter resource is the correct one, and does follow on from an appointment that would be the planning stage which covers this also.
Can you please log a tracker to request for clarification in the specification on how this should work."

Full chat:

The WG discussed this and offered to update the zulip chat with the following:

The new Encounter.SubjectStatus property could be used for this (with the addition of a value covering "not-directly-involved"), but some are very tentative on the idea and think that a new property would better serve, and are struggling to come up with a suitable property name - "DirectlyInvolved"?.

This new property will need to cover that the patient isn't directly involved in the encounter, it's about them, rather than with them.
If we add it this way, then most encounters will need this property set, and the exceptional cases will have it set to false (a bi-product of the no-defaults change in R4)
These comments have been posted to Zulip for further feedback from the community.

Tracker # 14153 - Summary: Encounter resource maps to HL7 V3 RIM PatientEncounter class 

The mapping from the FHIR Encounter resource to the HL7 V3 RIM Encounter class is incorrect. The actual RIM class name is "PatientEncounter". There is no RIM "Encounter" class.

The WG did some investigation on this but agreed to allow our v3 facilitator to look into it. Brian Postlethwaite Brian contacted Alexander Henket to review. Alexander replied that it has never been called "Encounter"... always "Patient Encounter."

Irma moved to find this tracker persuasive and change the this to patient encounter. Alex seconded to make it reference correctly.


Vote: 3/0/2

Tracker # 13668 was discovered as a patient care item and added to the joint session later this week.

Tracker # 14230 - Summary: Encounter type codes don't accomodate "long term stay" 

The notion of inpatient non-acute encounters covers too much space - it could include hospitalizations, residency in a rehab facility or a 10+ year stay at an aged care or skilled nursing facility.  There should be some level of differentiation to at least allow ordering/recommending such types of encounters even if the events don't necessarily get represented as "Encounter" instances in the responsible systems.

This seemed like a bigger issue than can be addressed in the 2 minutes that are left in this quarter so this will be continued after the break.

Monday Q4


2019 May WGM Attendance



Since Graham was here, the WG could update him on where we are with FHIR and Patient Merge/Link.

The WG continued with the agenda item off Patient Merge/link.

Reviewing the confluence project page, 

The WG discussed the merge and unmerge and how destructive these operations are. Especially unmerge, which is very difficult to resolve. These unmerges seem to happen in about 5% of the merges. Brian updated the project page.

The WG discussed and link behaviors. 

Brian documented this as a subsection of the Patient / Projects for Patient Administration / Patient Merge and Link called Existing Behavior.

The WG updated Graham on FHIR status. There didn't seem to be any issues. 

Graham asked about mother/baby record references. There does seem some work to be done here.

When discussing VIP or record access, Graham asked if there were any things we should do. 

  • Action Item: To follow up on the restriction or security items that need to be scoped.Brian Postlethwaite 

Irma then presented on a new project that she's been made aware of in The Netherlands having to do with a DBC that might be similar to the DRG usage in the US. The question was to what resource it may map to. She asked the US participants if this was still relevant in the US and if the efforts could be joined to produce a solution that would add value to both situations. Drew from Cerner noted that it could map to claim, some clinical resources, etc. So this is an issue. This could be an effort wherein the similarities between DBC and DRG could be analyzed to come up with joint mapping efforts.

Brian also noted that CMS (US) asked for direction for mapping the Encounter resource to hamonize the their CMS efforts which defines a patient encounter.


Tuesday Q1 


2019 May WGM Attendance


We've updated the list of resources that will go normative in the last WGM.  We are working on getting connectathon tracks, and finding implementers of the resources we want to go normative.

Question:  Do we need production usage of the R4 version to go normative?  Is STU3 production usage sufficient?

  • Josh Mandel will take the question on whether we need R4 production use of a resource to move it to normative in R5.
    → Initial answer from FMG is that we don't specify version in these requirements. We'll discuss this with Brian in a subsequent FMG session.

Need to document across all scopes, since it needs to be tested across all scopes
QA tracking spreadsheet is updated

IG authoring:
Looking for folks to help out with IG publishing. May want to pull folks from PA if there is interest.

Plan is to develop a course for IG publishers.
Want to encourage new folks to become IG publishers.


The question is how can we support date filtering on $everything operation.
Need to decide what property on each resource is the care date for the purposes of exports.

May need to update Encounter/EpisodeOfCare $everything operations to include similar paramters to patient.

It could make sense to look at the when properties in the W5.

Would want a new property in the CompartmentDefinition to define the care date.

Could we have a cross-resource search parameter.  Similar to the patient parameter, create a careDate parameter that apples to all resources that are candidates for $everything.

When there are multiple relevant care dates, what to do?  Is the meaning of "start date" that a Condition started prior to the date?  Or that it started within the specified date range.

How to handle resources with null dates.  Should we include resources that have null dates?

One option: have each resource define a FHIRPath expression that defines the careDate compartment parameter.

  • Cooper Thompson Create a tracker to add a $everything operation for EpisodeOfCare.

Update:  looks like Brian already created one:  GF#22115

Another option is to have a two-option solution

  • Resource owners can create an OR'ed list of existing search parameters for simple cases
  • Resource owners can create a net-new search parameter if there are complicated resource-specific logic that should be applied for determining the care dates.

Still not sure how to handle the two "missing" date resources:

  • Resources that do not define date properties at all.
  • Resources that do define date properties, but where the instance of the resources do not have them set.

Initial guidance is that resources with null/unknown dates should be returned.  Josh was unsure about this approach, as it somewhat devalues the utility (for some uses cases) of $everything date filtering.

GF#17362 Motion: Add a new property to CompartmentDefinition with the name of the search parameters that will apply when using start/end dates in $everything.  

Josh Mandel / Corey Spears: 13-0-0

Bulk Data Deletion

This was discussed in the connectathon.  This won't land in the first version of Bulk Data, but it should land in the master branch soon.

Wanted to enable the process of grabbing a full directory initially, but then get "diffs" on subsequent queries.  In order to support that, you need to track additions, changes and deletions.  Additions and changes are already handled well.  Deletions are not. 


  • Include an extra file that includes the list of IDs, or Bundles of ID (exact format TBD) of deleted resources
  • Include a CSV of the resource type and ID of deleted resources
  • Query on status of a list of resources (Bulk Data and Directories). Client maintains a set of IDs they care about, and ask for the current data for all those IDs.

In general, for directory resources you should be using active properties or end dates, but over time you may eventually want to actually delete content.

Some discussion about deletion use cases.  Including: GDPR, pop health mapping changes driving inclusion/exclusion changes, etc.

There are issues with using the List option because we don't do paging within a single resource, however there are operations to add/remove entries to a list without needing to process the entire list.

Bulk Data Data-Subsets

Currently bulk data relies on out-of-band communication to identify the set of data that should be communicated.  

Search parameters with local definitions

For search parameters that are defined in the base spec (STU3), but are being update in R4, can IGs re-define the STU3 search parameter in the base spec to behave as R4 will?

The intent is to allow an IG to loosen the behavior of the base spec.

If we do need a new IG-specific search parameter in R4, can it use the canonical URL from R5?

This is a good topic for FMG.

Tuesday Q2 


2019 May WGM Attendance



The WG began with FHIR tracker item resolutions as per the agenda.

GF # 20188 -  Summary: Add description to endpoint resource. 

Add a description or notes field where a description of the the endpoint can be captured.

e.g., This is the endpoint used by the XYZ subsystem to access ABC resources for the DEF component that provides GHI functionality.

Enable search on description text so that people can find endpoints by what they do instead of the managing organization or url, because users often know feature/function, but not the technical details of the endpoints.

Add a new property to the Endpoint resource

description string 0..1

Micheal Donnelley moves to add the above to the Endpoint resource, David Hay seconds. This results as a persuasive with mod, as the searches can be performed using other elements for usage.

Discussion: none

Vote: 8/0/0

GF # 20530 - Summary: Endpoint valueset for payload type duplicates codes rather than importing 

The valueset endpoint payload type improperly duplicates the IHE Format Codes. These codes are available in a valueset that should be pulled from.

This was noticed because the endpoint valueset has two entries for xphr.

The WG feels this is a reasonable request. The IHE value set will be imported

Micheal Donnelly moves, Brian seconds. 

Discussion: None

Vote: 8/0/0

GF# 21242 - Summary: Make the wide scope of Practitioner more clear 

It is often unclear for specifiers and implementers of FHIR, that the Practitioner resource covers not only healthcare professionals/professionals in a healthcare organization, but also any kind of person acting in their profession that needs to be represented in FHIR. Therefor people often tend to look at Person as a resource to use for the latter purpose.

So this should be made more clear on the Practitioner spec page.


A) Extend the first sentence of the section as follows:

"Practitioner covers all individuals who are engaged in the healthcare process, healthcare-related services and generally every process relevant for healthcare and healthcare organizations as part of their formal responsibilities [...]"

and B) add examples to the bullet list like:

- a cab driver
- a lawyer acting for a hospital or a patient
- a person working for a supplier of a healthcare organization"

The WG discussed the concept of the cab driver and how this needs to be less general and potentially connected to an organization providing service in the care provision. Therefore t

e bus driver for a community organization. 

The WG spent some time refining Practitioner 

David moves the above (persuasive with mod). Brian seconds.

Discussion: 7/0/2

GF # 9249 - Summary: Manage the Provenance of Practitioner (and Other Resources) using an Extension 

Within the context of a discussion about the Practitioner resource during a PA meeting in Orlando, we debated how to declare the curation of data, or a subset of data, within a particular resource. The particular use case was to define a curating organization (such as an HIE or RLS service) of Role, specialty, contact information, etc, of a particular practitioner, as distinct from thr organization(s) to which the practitioner is associated.

We debated several options but came to the conclusion that an extension within the specification would:

- Allow us to assign a curating entity to a subset of a resource or to different content contained within the same resource.

- Apply to additional resources.

Remove the implementer burden on non-provider directory use cases to support and/or understand this field and concept.

We propose:

- An extension which defines the  curating entity, which references an Organization.

This might have been set to status "Waiting for input" It should have been closed as it has been voted on and dispositioned.

GF# 13682 - Summary: 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. 

This was addressed as part of the closing stages of r4 with all work groups using practitioner addressed.

Brian moves this as non persuasive with mod. Alex seconds. 

Discussion: None

Vote: 7/0/3

GF# 20750 - Summary: Codes for Practitioner.qualification.code are too narrow 

All of the codes are related to education.  There are no examples of other types of credentials (e.g. licenses, certification, etc.  The set of codes don't need to be exhaustive, but we do need examples that show the other types of things that can go here - because I've had implementers tell me that they can't use 'qualification' for licenses and pointed at the list of codes as the basis for that statement.

The WG could not easily find non-educational licenses or certifications to add as examples of licenses and certifications to be added. The V3 list is being explored. Irma to reach out to Alexander Henket to get this list.

The WG decided to disposition this as waiting for input.

The WG moved on to address the publication request form for the ValidatedDirectory. Irma accessed and created a form in confluence. The WG walked through the form.

The WG was not able to complete. This will be saved and continued later.

Tuesday Q3 


2019 May WGM Attendance



Patient Merge and Links

The group discussed query/search behavior. Searching by patient demographics on the patient resource - should the old demographics be returned.

For merge cases, in theory one patient resource is returned with active identifiers, and inactive identifiers for "old" merged records.

The WG discussed the various system merge behaviors

Record A + Record B = Record C

Record A + Record B = Record B'

It should be clear that these references are patient identifiers, not, although this is a consideration as, from a technical perspective, this is used (in observations references) to search for Patient.

Brian showed an example of a search to the group.

The question came up regarding old Question came up of what error would return 404 (not exist) or 301 (moved permanently; redirect).

The WG continued to discuss linking which might give insight into merges.

Tuesday Q4


2019 May WGM Attendance


Continue the discussion on the merge/link discussions.

Most of this discussion details can be found in Patient Merge and Links.

Additionally, the WG covered and updated the above with unmerege


Wednesday Q1 


2019 May WGM Attendance


GF#14963 - Create a "lifecycle" status for Account

The proposed valueset was offered by Epic (Cooper).

We aren't sure if "Discharge/Not Billed" (DNB) is an Epic term, a US-specific term, or a common international term.  We opted to name the status "Care Complete / Not Billed" so that if DNB is actually an international term, reviewers would be more likely to submit a comment to that effect.

We determined that Zero Balance and Archived were internal implementation statuses, and not appropriate for inclusion in the FHIR valueset.

We revisited whether we should fold the billingStatus back into the main status property, but to be consistent with other resources, we again concluded to keep them separate (reinforcing Tuesday Q2 Jan 2018 discussion).

Discussion around whether we should change Account.status to included completed in addition to inactive.  

We wandered into some discussion with service dates and service periods.  However we believe that the current structure allows the different jurisdictions to do what they need, so no changes are likely needed.

What happens when Account.status is entered-in-error, but Account.billingStatus is open?  Do we need a bunch of invariants (but billingStatus is an extensible binding).  

We ended up with a mostly complete proposal, but had a few items to resolve, so did not get to a motion.

Line gave everyone gold stars!

Wednesday Q2



Joint with Patient Care


GF # 20650 - Summary: CareTeam.participant.timing - replace timing with data type period 

CareTeam.participant.period supports the specification of the time period for which the participant was, is, or to be involved in the care team.

There are more complex use cases that require the data type to be changed to Timing.

Use case examples:
A cardiologist is nominated as a care team member/participant from May 2019 to November 2019, but will only be available for providing care on Monday, Tuesday, and Friday each week
A community nurse is required to provde home nursing care to a patient from April 2019 to March 2020, and will do home visits once every week. The day of the week is to be arranged with the patient

The latest update to Gforge documents a zulip chat:

Patient Care FHIR Conference Call April 18, 2019

Reviewed feedback so far on Zulip:

Discussed the possibility:
* using CarePlan.activity.detail.scheduled -- the requested timing of the activity
* using CarePlan.activity.outcomeReference -- the actual occurrence timing (actual Appointment, Encounter, Procedure.occurrence)

Rob advocates that the member is always participating in the care team (within the effective period) regardless of schedule availability.

Joint PC/PA Wed Q2 at WGM (Rob will be there)

The PC WG considered this as part of PA scope due to the potential impact or involvement of scheduling concepts/elements.

In care team participant, there is a period. There might be a proposal to change it to timing. 

After discussion of CarePlan related to the CareTeam and how these are responsibility roles versus planning of activities. After much discussion it was decided that there could be a paragraph description of how to represent:

  1. The general availability of practitioner, activity or related person... essentially all care givers (outside context of CarePlan/CareTeam/Anyting).
  2. The requested schedule of when ac actiity will occur (from a CarePlan - through the request resource referenced).
  3. Knowing when the actual activity occurred (referencing the Event resource).

There may be a need for PA to revisit the scheduling resources to, perhaps, relate the schedule to the care plan. Brian noted that the CarePlan has a reference element that can reference the Appointment resource.

The joint work groups decided that getting the use cases. This will turn into guidance text which we can revisit to see if there are any gaps. Thursday Q4 is a potential, however there was a risk that people will not be around. Michelle suggested that we can draft something via email then maybe have a joint conference call to coordinate the scope efforts.

GF # 11173Summary: CarePlan needs support for reviews - 2016-09 core #327 

Tracking of reviews and plans for reviews is something that applies to many resources, not just CarePlan (e.g. protocols, standing orders, long term care admissions, etc.).  This is something probably best handled by "Task" but will require a fair bit of analysis and discussion with other work groups to agree on approach.  Defer to R4.

Patient Care Discussion on Aug 22, 2018

Care Plan DAM 1.0 has some requirements around reviews at the component level and overall level. We need to pull together documentation around who is involved in review, timing of reviews.

Laura suggested that we utilize Clinicians on FHIR for feedback - especially if there is a CarePlan track and this review topic is a use case for the CarePlan track.  Create (draft) care plan > review > respond > etc.  Laura volunteered to draft the use case for the CarePlan track. 

The PC WG considered using these for the review:

  • VerificationResult
  • Task
  • Provenance

The WG brought this up to PA as the VerificationResult is part of the PA WG.

The reviews here have to do from a clinical perspective . The PAWG does not think VerificationResult is a good fit, since this is more about validating the accuracy of data content, rather than reviewing elements involved in the care of a patient (e.g. medications, care plan, blood draws, etc.) as it stands. However, Lloyd considers this as a candidate to expand to perhaps cover reviews.

The task is for the PC WG to finalize their use cases and requirements to see if VerificationResult (or any other resource) could cover it.

GF # 16148Summary: 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.

GF # 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:

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

In reviewing the number of GF items:

The WGs decided that these disucssions around ranking may have impacts the following resources:

  • Encounter
  • Account,
  • Condition,
  • Procedure,
  • ChargeItem,
  • Claim,
  • ExplanationOfBenefits,
  • EpisodeOfCare

Encounter will show the ranking. The other resources will reference back to Encounter for the ranking.

Encounter, Procedure and Condition are slated to go normative for R5.

A project page was created to support this: Encounter, Condition, Procedure, Diagnosis...

The WGs discussed joint sessions. Although it seems that they should continue, the WGs considered using 2 quarters. Proposal to use Wed Q1 and Q2 for next WGM.

Wednesday Q3




The Gender Harmony project

Rob McClure was present and gave an overview of the project with the goal of asking the group for co sponsorship.

The workgroup covered the context definition and PSS. After review of the materials, Rob summarized that vocab would like PA to co-sponsor this along with Patient Care.

Irma asked what the final product would be. The answer was an informative white paper. The question was asked then where it would live. Since it will not need ANSI approval process, it will most likely be published in the HL7 website. Irma suggested that then one outcome, or deliverable, should be to reference this from the confluence pages.

Cooper moves to co sponsor the gender Harmony project PSS. Irma seconds.

Discussion: None

Vote: 4/0/0

Reviewing GF items:

  • GF#17519: Adding name to encounter
    The workgroup discussed if Encounter.Type would fit their usecases. The description is entered manually according to their usecases. This seems to be out of the 80% usage and therefoor the WG suggests to use an extension for that.
    Irma moved to be nn persuasive, Cooper seconds.
    Discussion: none
    Vote 3/0/0

Wednesday Q4




FHIR Work/Trackers

    • Scheduling
    • Review of Argonaut Scheduling IG statusFHIR Work/Trackers
        • Scheduling
        • Review of Argonaut Scheduling IG status

The WG would start with trackers.

GF # 15023 - Summary: Cleanup / Improve doctor-to-doctor appointment w/o patient present 

During discussion of tracker 14804, we noted that we want to improve our existing example for doctor-to-doctor appointments (which are about a patient, but does not have the patient present).

After following the link, this seems a reasonable request. The example will be improved.

Brian moves as persuasive, Drew seconds.

Discussion: None

Vote: 7/0/0

GF # - 18827 Summary: Add discontinued to Appointment.status valueset - STU #25 

There should be a way to indicate that the appointment that was started, but was not completed, but rather discontinued. This will avoid confusion that a "completed" status for an appointment that did not reach its conclusion, particularly if there are several indications for a single appointment)

The WG reviewed the Appointment.status, Encounter.status and Resource.status value sets to compare. There was quite a lively discussion around what it means when an appointment ends and when an encounter begins and where the tracking of status might be done. Today the model is that an appointment essentially ends when it has been fulfilled (or cancelled, etc.), so any status tracking should be done on the encounter. 

There was a lively discussion on workflow of 'fulfiling' an appointment then tracking all subsequent actions (for status purposes) on Encounter.status.

Brian moves to find this non persuasive and Drew seconds. 

Discussion: None

Vote: 6/0/2

The WG noted that we might want to update the two entries to


The process described/requested in the resource could not be completed, and no further action is planned

completecompleteThe process described/requested in the resource has been completed, and no further action is planned

so that the "... and no further action is planned" might be removed. This was tabled.

The WG continued on to the next item: 

  • Review of Argonaut Scheduling IG status

The WG discussed the scheduling workflow.  Cerner asked for the "requested period" not to be required. Currently it is 1...1 

The Argonaut representative appreciated this feedback and well take it back to their leadership.

GF # 19521 - Summary: Change cardinality and data type of comment for appointment 

Change cardinality and data type of comment for appointment. We would like the cardinality of comment to be 0..* and the datatype should probbaly be annotation to allow for documenting the author of the comment.

Change the comment field from a string to  

note 0..* Annotation

Drew moves, to disposition this as persuasive with mode, seconded by Kathy Pickering.

DIscussion: None 
Vote: 7/0/1


Thursday Q1 




Ballot reconciliation v2.9

247 - Persuasive - Lori Fourquet/Irma Jongeneel 6-0-0

251 - Persuasive - Lori Fourquet/Irma Jongeneel 6-0-0

252 - Referred and tracked - Lori Fourquet/Irma Jongeneel 4-0-2

254 - Referred and tracked - Lori Fourquet/Irma Jongeneel 4-0-2

253 - Persuasive - Lori Fourquet/Irma Jongeneel 6-0-0

255- Persuasive - Lori Fourquet/Irma Jongeneel 4-0-2

Block-vote for style-related-comments - 107-108 - 109 -110- 112 - 117 - 114 - 115 - 116 - 118 - 119 - Persuasive - Lori Fourquet/Irma Jongeneel - 6-0-0 

Block-vote for typos and removal of comments in text - 246 - 113 - 111 - 248 - 249 - 250 - Lori Fourquet/Irma Jongeneel  - 6- 0 -0

242 - Persuasive - Irma Jongeneel/Alex de Leon - 3-0-4

243 - Persuasive - Irma Jongeneel/Alex de Leon - 3-0-4

120 - Persuasive - Irma Jongeneel/Alex de Leon - 7-0-0

  • 121 - Alex de Leon to check with publishing about whether this apply also to the ARV segment - Persuasive - 5-0-2

Admin Work

Approve San Antonio Minutes - Motion to accept the minutes from Irma Jongeneel/Andrew Torres - 6-0-0

Approve next ballot - more general work on FHIR - R5 possible in May next year. Possible a VHDir ballot again in May,

Address PBX matrix - PA is now in all green. 

Line Saeleto check if we need publication request on the Reaffirmation ballot

Work Group Health - all green.

3 year work plan  - the WG updated the FMM for all our resources and added the missing resources that our group is responsible for.

Plan next meeting Draft Agenda. Line had already made a draft of our next agenda. Monday Q1 and Q2 are plenary meetings. 

Line Saeleto fix dates and small typos

Updates from the Steering Division - SD is using e-votes. Line is responsible for all e-votes in the SD.

Publishing updates (Alex) - We can have both a publishing liaison - and a tooling liaison. Electronic Tooling and Publishing WG.

Webpublishing - not in Word-documents.

v2+ - all v2 online.

Harmonization proposals - Nothing here...

Conference Call - Weekly conference calls on Wednesday .

  • Line Saeleto set up conference calls - starting not next week, but after that. 

Thursday Q2 




Brian asked Bob Dieterle to present the DA VINCI Project overview and talk about related implementation guides and PPS. The scope is potential PA involvement in IGs an sponsors of PSSes.

After review of the materials involved in the effort and the timeline, the request was made as to whether PA would be the lead work group sponsor or co-sponsor.

The 2 requests are to vote on being a sponsor on the PSS and to be lead sponsor on the IGs. 

Irma moves to include PA as co sponsor on the Paired Data Exchange PSS, Bob Deiterle seconded. 


Vote: 15/0/3

There was some discussion around the actual participation of PA within this effort. After discussion, it was decided that PA would have limited time/effort to lend to this effort. Bob requested that we document that they did approach PA with being an active participant but the group declined to be actively involved to assure it is known that they did approach PA.

The WG continued on with FHIR work relevant to both WGs.


The discussion began with the relation of the ChargeItemDefinition is related to Catalog.

After much discussion of the relatioship between the concepts above, the CatalogEntry.referenceditem needs items added to support the accurate relationships between the needed resources.

  • CatalogEntry.referencedItem will have the following items added: ChargItemDefinition Brian Postlethwaite 
  • ChargeItemDefinition to support instance of MedicationKnowledge   and devices.Hans Buitendijk

ChargeItemDefinition is where cost should be modelled.

FM will do the modeling of the fee schedule modeling which seems to be missing.

GF # 14963 -  Summary: Create a "lifecycle" status for Account 

We currently have a "record status" (Account.status) on Account, however we do not have a "lifecycle status".  During PA WGM Jan 30, while discussing tracker 14811, we wanted to create a separate tracker to add that, thus this tracker.

A proposed valueset for the new lifecycle status is below.  This would likely be an Extensible binding.

Discharged/Not Billed
Zero Balance
Bad Debt


Add a new property billingStatus 0..1 CodableConcept with the following extensible binding:

Open - The account is open for charging transactions (account.status is active)
CareComplete/Not Billed - The account.status is still active and may have charges recorded against it (only for events in the servicePeriod), however the encounters associated are completed. (Also known as Discharged not billed) This BillingStatus is often not used in ongoing accounts. (account.status is active)
Billing - Indicates that all transactions are recorded and the finance system can perform the billing process, including preparing insurance claims, scrubbing charges, invoicing etc. During this time any new charges will not be included in the current billing run/cycle. (account.status is active)
Closed-Bad Debt - The balance of this debt has not been able to be recovered, and the organization has decided not to persue debt recovery. (account.status is in-active)
Closed-Voided - The account was not created in error, however the organization has decided that it will not be charging any transactions associated. (account.status is in-active)
Closed-Completed - The account is closed and all charges are processed and accounted for. (account.status is in-active)
Closed-Combined - This account has been merged into another account, all charged have been migrated. This account should no longer be used, and will not be billed. (account.status is in-active)

The description of the property would be:

"The BillingStatus tracks the lifecycle of the account through the billing process. It indicates how transactions are treated when they are allocated to the account. (need to explain how it relates to account status)"

Should we add invariants to ensure that billingstatus is not used when account status is entered in error?

Should the Account.status also include a completed value?

Should we collapse both statuses into the 1 property.

Cooper moves to disposition this as persuasive, Drew seconds. 

Discussion: None

Vote: 12/0/3

The chair asked if we should keep this joint quarter in the next WGM. Both agreed we should keep it 

Thursday Q3 



  • No labels

1 Comment

  1. Canadian Provider Role valuesets that can be used as a source for the additional examples for tracker 20750