Skip to end of metadata
Go to start of metadata

September 1019 HL7 WGM Minutes 

Monday

Monday Q1

Attendees 

Insert link to attendance sheet

Minutes 

No meeting due to plenary.


Monday Q2 

Attendees 

Insert link to attendance sheet

Minutes 

No meeting due to plenary.

Monday Q3 

Attendees 

2019 Sept WGM Attendance

Minutes 

First order of business was ensuring all attendees had sufficient coffee and Swiss chocolate.

Second order of business was reviewing and approving the agenda for this WGM:

Motion: Approve agenda, moved by Brian seconded by Alex

Vote: 6-0-0


The WG reviewed the mission and charter.

Question:  Is PA still the steward of personnel management?

Answer:  We call it provider directory and administrative registries, but those both are functions of personnel management.  Also the old Personnel Management WG was folded in to PA.  So yes.

Motion: Append the charter as follows, moved by Alex, seconded by Brian:

Administrative data to describe resources, their availability, [for example, represented by schedules or by status], and regulatory topics such as licensing, roles and credentialing information about individuals (i.e. personnel management), animals, organizations and devices directly or indirectly involved in the delivery of healthcare services.

Vote: 6-0-0

  • Line Saele will send the proposed charter changes to the steering committee.


The WG reviewed the SWOT: SWOT for Patient Administration Work Group

Line Saele will notify the steering committee that the PA SWOT is now hosted on Confluence instead of in the word document.

Brian suggested we update the Oppurtunities to accurately represent the other standards communities we collaborate with.

Motion: Update the Opportunities to accurately represent the other standards communities we collaborate with.  We added IHE due to patient merge, and removed OMG/HSSP.

Moved by Brian, second by Alex.

Vote: 6-0-0 


The WG began a of the three year plan: 3 year plan Patient Administration

Brian noted that we'd be getting more details about the plans for R5 throughout the week, so we opted to move the formal three year plan review to Thursday Q1.


Question about anything we'd be balloting in May.

We might want to consider balloting patient merge, but that falls under our existing PSS for FHIR.  We don't need a new PSS for that.


Update from Connectathon:  Patient Merge

  • It was a experimental track.
  • Expected it to be low interest.
  • Ended up being very high interest with involvement from 3 different tracks (PA, Argonaut, Subscriptions).
  • 6 attendees at the table (expected three)
  • ~10 people from Subscriptions track were interested in how to get notified about a merge.
    • There are considerations for systems that "delete" the source patient.  So there is no old record to link back to.
    • Options for subscribing to merge:
      • Trigger on the update of Patient.link.
      • Trigger on the operation itself.
      • Trigger on the provenance that is created by the merge.
      • Trigger on the task that is created to perform the merge.
  • Discussion on what happens when all the resources get updated to point to the new patient.
    • Will they get 100,000 notifications for each resource?
    • Will they only get a single patient merge notification, with the assumption that it is sufficient to inform the client about how to clean up the data they have already.

When Grahame said that connectathon attendance would go down, he was wrong - this connectathon had all-time high attendance.  Apparently Grahame isn't all knowing as we all believed.  Our faith in him is shattered.


The WG solicited new project proposals from the group:

  • (Informative for the WG) Brian socialized news that AU is moving stuff into R4.  They'll be using some cool Questionnaire capability.  Next stage is working on transferring data between systems (something like $everything).  They will be using FHIR directories to locate the clinics to which the data will be sent.  AU govt is also doing a "service registration assistant" that facilitates sharing of provider directory data.

For patient merge, the suggestion is that we write an IG.  Some of that will go into the IG, some will go into R5.  Will be an IG for R4.  If we ballot something, it would be an IG for how to do merge in R4.

Options:

  • Push merge behavior into R5 base via ballot.
  • Create an IG for merge behavior in R4.

Brian did confirm that all our merge work will fall under our current FHIR PSS.  We are confident we do not need a new PSS for merge work.

Question:  Should we have an unmerge operation?

Answer:  We are starting with merge.  We want to keep scope reasonable.  We may pursue unmerge in the future.


Cooper will be representing PA in FHIR-I in Mon Q4 for workflow considerations. 

Monday Q4

Attendees

2019 Sept WGM Attendance

 Minutes

Introductions

FHIR Trackers

Line had received an email from a colleague. The following were discussed:

21241 - Summary: Make prohibited use of Person more obvious

The WG discussed the user of Person, which is not used as an actor. Lloyd suggested the clarification of this. However the Norwegian contributor seems to have a need to link Person and RelatedPerson together. The WG is asking the submitter of this issue to provide use cases of why this is needed.


20771 - The WG continued on to address the concepts of Person indexes and Patient indexes.  This was updated in the Zulip chat stream 194447.

23061 - Summary: Communication needs to explain the boundary between it and messaging.

20743 - Summary: Add support for "official" address, 

The WG discussed the merit of having some "official" addresses.

This addressed all the trackers contained in the email.


21258 - Summary: HTTP Status for updating a FHIR resource without any changes

If an actual change was requested and the resource was not changed due to policy or for other reasons, a 4xx error should be raised indicating the policy that resulted in rejection of the update.

If a change is submitted where no data actually changes, we see no reason of introducing the complexity of a different response type.  Instead just return a 200 success and the same timestamp/token as exist on the current record.

The 304 "Not modified" code is intended for conditional gets and updates and deals with caching (the resource has not been modified since the specified date).  It is not described in a way that suggests it's appropriate for updates that weren't applied due to business policy.


The WG moved on to other trackers

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.

The WG discussed this and first determined that the submitter is actually referring to Encounter.class, which has a Non acute code (using v3 codes), but nothing more granular.  This seems to be more of a terminology concern, so the WG is recommending a referral to the vocabulary WG.

17303 - Summary: Encounter.statusHistory.code should be an extensible vocabulary

The Encounter.statusHistory.code has a required binding vocabulary that is not inclusive enough of events. For example in IHE we are profiling the EMS encounter prior to delivery of the patient to the hospital. There are may events that happen during this that needs to be recorded as statusHistory. (e.g. EMS dispatced, EMS arrival at scene, etc)

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.

Still waiting for input

21770 - Summary: Documentation for Encoutner:patient serach parameter should not mention "Group"

Docs say: "The patient or group present at the encounter        Encounter.subject.where(resolve() is Patient)"

The fhirpath doesn't mention "Group", and neither should the documentation string.

The WG agrees with the suggestion.

Brian moves the disposition as persuasive and will remove "and gruups" from the documentaion. Alex seconds.

Discussion: None

Vote: 7/0/0


Tuesday

Tuesday Q1 

Attendees 

2019 Sept WGM Attendance

Minutes 

  • Introductions

Coordination with FHIR Infrastructure

Brian asked if there was any FHIR Infrastructure representatives.

The proposal is to not have a ballot during Jan, but wait until May 2020, allowing for one cycle into 2021. The goal is that we would have a cycle before May, would have the first round of R5.

The WG discussed a search capability around searching for a group using "in". Patient group membership, location membership, Graham introduced the concept of "above", and "below", instead of "in". This will end up being in the scope of FHIRI to define as a modifier for a certain search reference. 

The WG then discussed the $match. this is currently under patient. However, this might be useful for use for other resources. There are currently other constructs for this concept for other resources (i.e. everything, etc.).  Graham noted that this concept could be either genericized for use with other resources, or it can be cloned and the documentation can be updated depending on the usage (i.e not patient oriented).

R5 planning

PA has been focused on patient merge. Whether to put the documentation on the confluence page or whether we should create an implementation guide. The FHIRi representatives suggested we do both. 

Hl7 shows how it would look on the api, but IHE would describe what would happen in the workflow.

There was some discussion around working together (IHE, Gemini, PA) to assure that the exchange and workflow are jointly defined and managed in an IG.

Graham had something to bring up with Patterns in the specification.

Defining event, workflow and result.

Event, request, definition, but there was no participant pattern. There may or may not be value in that but there is logic in these patters for resource use. Therefore Graham did some research.


Interface patterns - 

Graham has defined 3 patterns that relate to administration resources. 

http://build.fhir.org/patterns.html

Graham has done some research around participant type patterns (table) in the above page. He stressed that this table doesn't dictate a result, but calls out some inconsistencies.

Graham questioned whether Related person should be a target of a reference.

The table is sorted alphabetically by first resource in the list.

The ask is for PA to review this table for consistencies. 


Graham noted that the PractitionerRole cannot display the name of the reference if it is blank.

The work group noted that if there is non (i.e. if the role is needed but who is performing is not defined, then a code should be used. Graham asked if this was documented somewhere. It is not. The PAWG committed to documenting this for guidance . Graham entered tracker # 22112 (Summary: Give PractitionerRole a name) to address this.

There may be a general issue around names to displays when references are used (i.e. Encounter, Location and Organization due to their partOf capability. MnM will be contacted regarding this.

Meanwhile the PAWG will come up with guidance for PractitionerRole.

Group is a FHIRi resource. Brian asked if it should remain so. Graham noted that this resource will be discussed a lot.

Brian noted another pattern that is not defined here:  the Metadata resource. Graham noted that that will be worked on/reviewed.


Encounter seems to have a lot of trackers. Simone asked if there could be quarters defined that are not Wednesday of this week as she will not be available.

The WG decided to use the rest of this time and perhaps Thursday Q3


Encounter

Simone discussed the state that in Germany there are entities that have specified IDs for any movement within an encounter, which has origins in v2 adoption. While attempting to adopt FHIR, they found issues.

One is that the statusHIstory which would require period. Other areas that would have to change in their extensions for the following elements: Class, location, (maybe serviceProvider). 

Tracker# 22764 - The WG reviewed hospitalization and the potential of rearranging the elements.

The WG discussed the rearrangement. Simone proposed that many of the elements such as (discharge disposition, etc.) which would leave hospitality like elements (i.e dietary preference, etc.) and put the remaining elements in another backbone element.

The WG attempted to define elements that would be useful for Movement: 

Simone clarified that this movement backbone element would copy the needed elements, more for history of movement. 

The WG discussed whether the movement should be part of the encounter, or if it should be an element on it's own. There are pluses and minuses. Being discreet would allow paging and such for long term patients where the Encounter resource might grow large. 

Brian suggested to create a backbone element on the Encounter resource to continue the discussion. If the decision is made to create it's own movementHistory resource, then it could just be used with that structure.

Tuesday Q2 

Attendees 

2019 Sept WGM Attendance

Minutes 

  • Introductions

Patient Merge Working Session

The WG discussed the merge operation, clarifying that unmerge and link will be covered later.

Preview to the overall page before updates today: 

Dynamic confluence page:

The WG discussed the merge parameters table at length (tables below). 

The question came up as to whether a third patient or merge into target. Michael suggested that the server should decide that. After discussion, the wg decided the guidance should allow this. The guidance will read "In the case where a new patient is desired to be merged from the 2 patient resources, then a new patient should be created, and then call the merge operation with both resources into the new patient resource.". This will replace: "

The preview was discussed with many considerations of general server capabilities (inputs from SMEs from Cerner and EPIC representatives) and potential business needs (WG). The 

Before quarter discussion:

Parameter Name

Card

Type

Description

source-patient0..1ResourceReferenceA direct resource reference to the source patient resource (this may include an identifier)
source-patient-identifier0..*Identifier

The Identifier(s) of the source patient resource, all of these identifiers MUST be present in the located resource (in addition to the one included in the resource reference above - if included)

(The purpose of this property is to ensure that the correct source patient resource is selected)

patient0..1ResourceReference

A direct resource reference to the target patient resource

This is the surviving patient resource, the target for the merge

patient-identifier0..*IdentifierThe Identifier(s) of the target patient resource, all of these identifiers MUST be present in the located resource

(The purpose of this property is to ensure that the correct source patient resource is selected)

result-patient0..1Resource(Patient)

The details of the Patient resource that is expected to be updated to complete with.

This resource MUST have the link property included referencing the source patient resource

It will be used to perform an update on the target patient resource

The absence of this parameter the servers should copy all identifiers from the source patient into the target patient, and include the link property (as shown in the example below)

This is often used when properties from the source patient are desired to be included in the target resource

The receiving system may also apply other internal business rules onto the merge which may make the resource different to what is provided here.

If this to be a new Patient resource, the patient.Id will be blank, and the server will be required to create that resource (feedback required - should we permit this?) - resulting in a completely new Patient record, and all resources linked to either of the patient resources merged will be updated to refer to it

preview0..1boolean

If this is set to true, then the merge would not be actually performed, however an OperationOutcome would be returned indicating how many resources of what types would be impacted by the change.

e.g. Issue.diagnostics "Require updates: 23 Observations, 3 CarePlans"

(draft concept only)

RETURN1..1

Patient

or OperationOutcome

or Task (async result)

If the operation was requested as a preview, an OperationOutcome will be returned with either

  • 200 OK - If the merge request doesn't expect any issues
  • 400 Bad Request - if there are errors expected, and a list of issues in the outcome

If the operation encounters an error in processing, then an OperationOutcome will be returned as above

  • 400 Bad Request - if there are errors expected, and a list of issues in the outcome

If the operation accepted for processing, and is to continue asynchronously to update all reference data, then:

  • 202 Accepted - and a Task Resource or OperationOutcome will be returned

If the operation completed all processing and did not require to continue processing:

  • 200 OK - if the Merge is complete, all data is updated, and return the target Patient as was completed, or an OperationOutcome
  • 201 Created - if the result patient was to create a new patient (need feedback if this is permitted)

After quarter discussion:


Parameter Name

Card

Type

Description

preview0..1boolean

If this is set to true, then the merge would not be actually performed, however an OperationOutcome would be returned that will indicate that no merge has occurred, and may include other diagnostic info if desired, such as the scale of the merge.

e.g. Issue.details.text "Preview only Patient merge - no issues detected"

e.g. Issue.diagnostics "Merge would update: 10 years of content or 120 resources"

The resulting target patient resource will also be returned in the result

result-patient0..1Resource(Patient)

The details of the Patient resource that is expected to be updated to complete with, and must have the same patient.id and provided identifiers included.

This resource MUST have the link property included referencing the source patient resource

It will be used to perform an update on the target patient resource

The absence of this parameter the servers should copy all identifiers from the source patient into the target patient, and include the link property (as shown in the example below)

This is often used when properties from the source patient are desired to be included in the target resource

The receiving system may also apply other internal business rules onto the merge which may make the resource different to what is provided here.

RETURN1..1

Parameters


The status of the response will be one of:

  • 200 OK - If the merge request doesn't expect any issues (although warning may be present), or was completed without issues
  • 202 Accepted - The merge request has been accepted, and does not expect any issues, and will continue processing the merge in the background, and you can monitor the Task for completion
  • 400 Bad Request - there are errors in the input parameters that need to corrected
  • 422 Unprocessable Entity - Business rules prevent this merge from completing

The Parameters resource will include:

  • The Input parameters to the operation
  • The resulting merged Patient resource
  • An OperationOutcome containing errors, warnings and information messages
  • Optionally a Task resource to track any additional processing that was required
source-patient0..1ResourceReferenceA direct resource reference to the source patient resource (this may include an identifier)
source-patient-identifier0..*Identifier

The Identifier(s) of the source patient resource, all of these identifiers MUST be present in the located resource (in addition to the one included in the resource reference above - if included)

(The purpose of this property is to ensure that the correct source patient resource is selected)

target-patient0..1ResourceReference

A direct resource reference to the target patient resource

This is the surviving patient resource, the target for the merge

target-patient-identifier0..*IdentifierThe Identifier(s) of the target patient resource, all of these identifiers MUST be present in the located resource

(The purpose of this property is to ensure that the correct source patient resource is selected)

The WG also updated the RETURN section for success/error conditions and updated the Merging Identifiers section was updated.

Tuesday Q3 

Attendees 

2019 Sept WGM Attendance

Minutes 

  • Introduction

The WG continued with the Patient Merge Operation focusing on the Merge processing and business flow.

Tuesday Q4

Attendees 

Insert link to attendance sheet

Minutes 

  • Combined Workgroup Session: Primary and Principal Diagnosis. (PC hosting)

Wednesday

Wednesday Q1 

Attendees 

Insert link to attendance sheet

Minutes 

Motion:  Accept proposed agenda for Jan 2020.  Motion by Line, second by Toril

Vote: 8-0-1


Updates from Steering Division

  • Approved after long discussion about roles.
  • Approval for the SWOT.  They have extended the time period for SWOT approvals.
  • 3 year plan is now (optionally) a 5 year plan.  We are no longer required to update it, but we think we should to have a good reference for our plans.
  • PA got a gold star for WG health.
  • PSS  process is going to change.  They are going to change the number of approvals.  TSC will continue to approve, but steering committee won't.  


Updates for Harmonization proposals:

  • None


GF#23029 - CareTeam.encounter should support cardinality 0..*

GF#23843 - Encounter should support a reference to CareTeam


Question:  Should CareTeam point to the encounters(s)?  Or should Encounter point to the CareTeam?

There are a few scenarios:

  • Surgical procedure would have a team.
  • For planned encounters, the CareTeam could exist first.
  • In many other cases, Encounter might exist first.

CareTeam has an extension that can refer to the EpisodeOfCare, which can refer to multiple Encounters.

EpisodeOfCare.team refers to the CareTeam.  So the extension on CareTeam may be redundant.

Option:  Could stick the care team members in the participant list.  Is that a way to handle planned encounters?

The distinction between participants and CareTeam is that participants are actually participating, but CareTeam may be on-call and not necessarily always participating.

Group consensus was that CareTeam and participants are different concepts and shouldn't be combined.


<humor>

Line said she couldn't hear due to some construction.

The group couldn't hear Line, so we asked if she said "she can't hear" or "she doesn't care".

</humor>


There was discussion around the boundary between Encounter.participants and the proposed Encounter.careTeam.

Should the CareTeam be folded into the Encounter.participant structure.

  • This makes sense when the whole team does participate.
  • But it doesn't make sense when a subset of the CareTeam actually participates.


We took a tangent and reviewed PA's tentative plans around Encounter movement.  

  • Cooper Thompson Submit a tracker to remove the standard extension on CareTeam pointing to EpisodeOfCare  (Submitted:  GF#24665)

Motion: GF#23843 Add a new careTeam property (0..*) to Encounter referencing the CareTeam.  Update EpisodeOfCare.team to EpisodeOfCare.careTeam to be consistent.    Moved by Russ, seconded by Stephen.

Vote:  15-0-0

Wednesday Q2

Attendees 

Insert link to attendance sheet

Minutes 

  • Introductions

The PA WG shared with the PCWG the work around the Patient Merge.

Merge Operation

FHIR trackers (PC representative will join) - (Practitioner, PractitionerRole, CareTeam, EpisodeOfCare)

GF#23029 CareTeam.encounter should support cardinality 0..*  

The WG reviewed the PAWG tracker (GF#23843)

This allowed the group to address this tracker as they refer to related concepts

Motion made by Michelle to disposition this as persuasive, Russ seconds.

Discussion: None

Vote: 16/0/0

The WG proceeded to discuss the following, regarding Primary and Principal Diagnosis (summary/continuation):

  • GF#16147 Condition.category - can be used to specify granular type code?
  • GF#20483 Add Encounter.diagnoses elements to Condition 
  • GF#16148 Encounter.reason and Encounter.diagnosis (PA) 

The WG reviewed 16148 and proceeded to review a diagram to try to show relationships between elements involved in an encounter. This included condition and procedure (among other elements) for this discussion.

Reviewed 20483.  The WG discussed the condition/procedure and how it relates within the encounter.

The question came up of whether condition should be related to encounter, account.

After review, the joint workgroups are happy to keep the structures of condition on encounter

The WGs determined that the properties as shown on encounter meet the needs of the community and should not be demoralized into condition. 

Michelle moves to disposition this as non persuasive, Amit seconded.

Discussion: None

Vote: 17/0/0

#16147 was next discussed 


Wednesday Q3

Attendees 

Insert link to attendance sheet

Minutes 

  • Introductions

The PAWG Patient Merge continues! 

There was a comment from Michael Donnelly to add a reference to maybe deletion of records on the following on the merge operation page:

"The target is the remaining patient resource (survivor), the source will be marked as inactive"

The PAWG resolved this by adding "... (or in some systems deleted)"

There was a question added: 

Question: (During join PC/PA session) Amit Popat questions the optional nature of the source-patient and target-patient resource references, and encourages always requiring the actual resource.id be specified. The reason for the additional identifiers is to ensure that the correct resource is selected, as with v2 we included additional demographic data to ensure a safe match.

The WG continued with the post merge operations with the intention of completing work for Merge Operations planned for this WGM. Currently, this section reads:


Post Merge Expectations

Once the patient resources have been merged:

A GET on the old Patient resource ID return: e.g. GET [base]/Patient/pat01

  • 200 OK and returns the old Patient which is now marked as inactive, and has the link (replaced-by) populated with the new Patient ID
  • 404 not found (when the merge system deleted the resource)

Should as SEARCH by the old Patient Resource ID return: e.g. GET [base]/Patient?_id=pat01 (often used as a substitute for direct GET when doing _include for the managing org/general practitioner)

  • 200 Ok Bundle with no patient resource (case where the old patient was deleted)
  • 200 Ok Bundle with the inactive patient which is marked as inactive and has the link (replaced-by) populated in it (that you'll need to follow to get any further data)
  • 200 Ok Bundle with the target patient resource (with the link to the one from the search) and not include the old patient resource
  • 200 Ok Bundle with both the target and old patient resources

How would interactions on $everything or the patient compartment on the old patient resource be effected by the merge? It could redirect itself?

How will this effect the $match operation? should it also return the inactive resources? If that operation definition does not return inactive resources, then no problem here.


The WG continued discussions around reponses and 

Post quarter with updates:


Once the patient resources have been merged:

A GET on the old Patient resource ID return: e.g. GET [base]/Patient/pat01

  • 200 OK and returns the old Patient which is now marked as inactive, and has the link (replaced-by) populated with the new Patient ID
  • 404 not found (when the merge system deleted the resource)

Note: If the system "knows" that the resource was there it would be preferable to return a stub patient 202 as described above.

Should as SEARCH by the old Patient Resource ID return: e.g. GET [base]/Patient?_id=pat01%active=true (often used as a substitute for direct GET when doing _include for the managing org/general practitioner)

  • 200 Ok Bundle with the inactive patient which is marked as inactive and has the link (replaced-by) populated in it (that you'll need to follow to get any further data)
  • 200 Ok Bundle with no patient resource (case where the old patient was deleted)
  • 200 Ok Bundle with the target patient resource (with the link to the one from the search) and not include the old patient resource
  • 200 Ok Bundle with both the target and old patient resources

Accessing the Patient $everything operation on the source patient resource (now marked as inactive) will return an OperationOutcome and http status of 400 Bad Request. The error message should inform that the patient has been merged and should follow the Patient link to access the $everything content.

Searching content (e.g. Observations) based on patient ID.

  • Observation?patient=Patient/pat01 would return no results (as all have been moved to Patient/pat02)
  • Observation?patient=Patient/pat02 would return all the data that is referencing pat02, and all the data that was referencing pat01

Notification Mechanisms

The indication that a merge has been completed can be notified through several ways:

  • Using FHIR Messaging to invoke the same operation
  • An integration engine sending HL7v2 A40 merge message (A18 may also be applicable in backward compatibility modes)
  • Directly calling the $merge operation on the dependent systems (requires the system to have both patient resources)
  • Using Subscriptions to detect the merge operation has occurred

These notifications can be sent to other downstream systems, partners, or other applications (including EMPIs). An EMPI could expose the merge operation, and therefore be a notification sender.

Consideration should be taken to ensure that the correct data is acted on.

The downstream systems may not have all identifiers that the notifying system has, the notifier may be configured to know what "types" of identifiers should be propagated to which systems.

When using the identifier parameters (rather than id) you should be using the same assigner (which in the example above would be the PAS or clinical system)

Impact on Subscriptions

Subscriptions on merges are most likely to be used by applications connecting directly to the system. Many use cases could consider using FHIR Messaging (or other messaging e.g. v2 messages) to communicate the merge occurred.

There is a whole discussion on the impact on subscriptions, so won't try and replicate all of that, but instead summarize the issues

  • What can be used as triggers for the subscription
    • Patient update with new link values
    • The Task doing the Merge operation?
    • Provenance(s) as an event
    • operation itself as an event (what does this even mean? persist the parameters object?)
    • AuditEvent as a trigger?
  • Will all the data that is patched over to the target patient ID be notified

Other Notes

In the case where there aren't 2 records in the clinical system, then a simple update could be used.

this case is only in the notification handling, not the merge request.

Further consideration on the identifier assigning authority needs to be done.

In HL7 v2, the trigger message only reports the results of the operation, and has PID and merged from PID

The HL7v3 in particular looks like they link content, and send a duplicates resolved message interaction.

Wednesday Q4

Attendees 

Insert link to attendance sheet

Minutes 

  • Introductions

Review the New Patterns approach for the PA resources (as presented by FHIR Infrastructure)

http://build.fhir.org/patterns.html

Participant: CareTeam, Device, Group, HealthcareService, Location, Organization, Patient, Practitioner, PractitionerRole, RelatedPerson

The WG continued to review the Participant Patterns table within the Patterns section of the FHIR build specification.

Brian questioned whether Communication.recipient should have an endpoint.

In looking at devices, Brian noted whether that should include an endpoint reference

The WG reviewed the patterns table and had the following notes and recommendations (as many of these are the purvey of other work groups:

Patient Care

------------

Challenge Communication.recipient inclusion of endpoint

Maybe Device needs an Endpoint to handle the needs of a delivery to that thing.


Challenge CommunicationRequest.recipient including the endpoint, that isn't the recipient, its a delivery mechnism that supports getting to a recipient.

CommunicationRequst.recipient add Location (to be consistent with Communication)


CBCC

-----

Encourage Consent.provision.actor.reference to include HealthcareService, Location in the referencable types, a service can hac have access to a specific consent (as a specific part of an oganization covering a type of services, e.g. Mental Health Service)


Account Subject (RelatedPerson) is fine as an exception, charges to an account would not be incurred by a RelatedPerson, it would be the subject.

Accouny Subject (Group) should be included. Group studies and veterinarian cases (herd of cattle) would leverage this structure.

Accout Subject (CareTeam) not so sure about this one, haven't been able to come up with a potential use case for this - leave out till consulted with Patient Care.


FM

----

Contract.term.action.performer should include Group, HealthcareService.

Ask how a substance is a performer in the contract, and can it be removed

(found processing the participant pattern)



-Group -Location

----------------------

CarePlan.activity.detail.performer +group(?) 

DeviceRequest.performer (no change - accept the exemption, group/location can't be the performer in the device request)

MedicationRequest.performer +group(?) (becomes subjects responsibility)

               Would managing a population health cover this?

Procedure.performer.actor (no change)

ServiceRequest.performer +group(?) (becomes subjects responsibility - when the subject is a group)

Task.owner +Group


- [Group, HealthcareService, Location]


Thursday

Thursday Q1 

Attendees 

Insert link to attendance sheet

Minutes 

  • (Some slightly less excellent minutes by Brian)
  • Review action items, Brian and Simone have a few action items to follow up and complete
  • Accept May Meeting minutes Brian Postlethwaite/Simone Heckmann 5-0-0
  • No ballot in the current cycle
  • FHIR Planning this cycle (on the conference calls)
    • Complete FHIR Patient Merge Operation definition and work with IHE/Gemini
    • FHIR Pattern analysis
    • FHIR Trackers
  • PBX Matrix and workgroup Health are all clear
  • Line to investigate if there are any 5 year affirmations to be done 
  • Recognise that the 3 year workplan is no longer a mandatory activity, and we have decided that we will continue tracking it, purely as a way to track our progress to normative for FHIR Resources and projects (so we can know when our project PSS dates are coming up.
  • The 3 year plan was revised

(Some slightly even lesser excellent minutes by Line)

FHIR Trackers:

22485 - Comments updated for further discussion with the Tracker submitter.

Comment added: 

The ServiceType property needs to be consistent with the Appointment property of the same name and update its cardinality to be multiple.

These changes would be covered by the conditions and procedures that are connected to the encounter. Billing would then run from ChargeItems and the ranked Discharge Diagnosis etc based on the various jurisdiction specific business rules.

Will take this up again on conference calls when we have more information, and attendance with additional EHR knowledge


14451 - old tracker from 2018. 

Suggestion to have people assigned to updates on different resources, so that we don't do updates on the same resource.

Motion: No longer seeing any warning related to workflow in the QA repost, so closing the issue.

Motion by Brian, second by Simone: 7-0-0


20479 - Clarification about subject in Encounter

Need further suggestions from Lloyd and Grahame, as well as EHR developers to find out how to move forward with this.


22497 - Detail description of Encounter.serviceProvider references an unknown example

Motion to approve to add the example of colonoskopi.

Motion by Brian, second by Christian - 6-0-0


23764 - Resource Encounter - Update Mappings(v2)

Pushed to when Cooper and Alex are present.


23837 - Encounter.participant.type name is confusing

Comment added to the Tracker:

Need to clarify if this is intended to cover roles or types. Currently is bound to the V3 Partipant Type set. (which includes concepts like admitter, escort, primary performer)

Where there other similar participant properties contain a role, which is bound to the participant role valueset which includes concepts like surgeon, dental assistant, urologist, public health nurse.

Will seek wider input on which of these concepts is desired to be covered in this case.


17414 - PractitionerRole extension for FHIR STU3


22114 - Make Practitioner.communication consistent with Patient/RelatedPerson.communication



Thursday Q2 

Attendees: 

Insert link to attendance sheet

Minutes 

Joint with FM.

FHIR (joint meeting with Financial Management)

InsurancePlan vs Coverage

#24667 - Summary: Create reference from Coverage to InsurancePlan

During joint FM/PPIE Wed Q2 in Atlanta 2019 WGM, the group indicated concerns over not having an option to directly link from Coverage to Insurance plan.

I am not sure whether we want to update Coverage.class.value to allow a reference to InsurancePlan, make it a choice, or add a new property as as sibling of Coverage.class.

I'm not suggesting which option should be accepted, but I am requesting a Reference from Coverage to Insurance

The groups agree that this should be included. The history is that InsurancePlan did not exist when Coverage was designed. The question is whether the reference should be a backbone element or part of the class element.

The WG discussed the references as might benefit the usage of InsurancePlan.

The FM WG suggested that the InsurancePlan resource needs to be reviewed and maybe updated. Mary Kay suggested that this discussion needs to happen with payors in the room to understand and then help make a decision.

Brian suggested that perhaps we can move forward for this tracker and later the experts can discuss insurance plan (and perhaps separate InsurancePlan into two resource: InsurancePlan and Product, for example).

#24694 was created by Cooper to refactor InsurancePlan. These are related in that there should be a reference from Coverage to the concept that may get created as per this refactoring.

Motion was made by Mary Kay seconded by Mark Scimshire, to disposition this as persuasive. 

Discussion: The WG noted that further follow up is needed and noted that the property may chance (i.e reference name, potential choice options, etc.). 

Vote: 16/0/1

Discussion on draft FHIR resources

The WG moved on with other trackers for joint concerns.

20972 - Summary: Add balance back to account.

We would like to see the balance added back to the account resource. We feel requiring multiple calls to account to retrieve the balance is burdensome to API consumers. The primary reason to retrieve the account resource is to view the balance. The FHIR server should be allowed to respond with the balance information if it deems it appropriate.

The WG discussed the various types of balances that could be needed, especially around history of balances. A proposal was brought forth by Mary Kay to create a "current value" item, then fields to provide needed balance values (i.e. balances at 30, 60, 90, 120 days, etc.). This structure should allow for value needs (i.e. 30 60 days, or 30 60 90 days, or 30 60 90 120 days). 

Although the tracker was updated, the FM WG will take this forward into their membership for review and resolution.

The WG also considered the situations where there are pending financial transactions that are not included in the current balance.

#20496 - Summary: Accound needs business status (ready for billing|billed|paid...)

Account resource has status element (active | inactive | entered-in-error | on-hold | unknown) but also needs an element to represent the status of the account within a business process while active (possible values e.g. "ready for billing", "billed", "balanced/paid" etc.)

Suggest to add element "billingStatus" as CodableConcept to the Account Resource

This seems reasonable to the groups.

Paul moved to disposition this as persuasive. Rachel Foerster seconded.

Discusssion: None

Vote: 10/0/1

Thursday Q3

Attendees: 

Insert link to attendance sheet

Minutes 

The WG discussed the Movement structures and some limitations that systems have (i.e. Cerner, etc.), then moved on to edit the structure definition for encounter to include elements to support the movement concept.

The WG discussed the structure and considered whether the movement structure should be in the encounter or separate it out. If so, what would it be? Child encounter, a different type encounter or a completely different resource?

The WG did some analysis on the encounter elements and whether they would be needed for the different concepts (which might help determine if this is a child resource, different resource, etc.):

  • Admission encounter,
  • (typical) Encounter,
  • Movement

Although implementers in the room are satisfied with the analysis results, the WG decided to get more feedback, especially from Cerner since their representatives have expressed implementation concerns that might.

Thursday Q4 

Attendees: 

Insert link to attendance sheet

Minutes 

Meeting Cancelled due to lack of participants.

  • No labels

1 Comment

  1. I created new tracker #24827 for the suggestion I made during the Thursday Q2 meeting to allow a parent/child relationship in InsurancePlan rather than splitting it into separate resource types for plans and products.