This page is intended to capture the discussions and design work around the re-design of how these resources are connected, and ranked across the many use cases that they are done in.
Contributors: Brian Postlethwaite, Cooper Thompson, Michelle Miller
Once the initial use cases are documented and ready for further review this will be scheduled on a joint conference call between Patient Administration and Patient Care sometime at the end of June (likely 28th).
The resources involved in the design are Encounter, EpisodeOfCare, Condition, Procedure, Claim, ExplanationOfBenefit, Account, ChargeItem
Trackers
| Tracker | Description |
|---|---|
| GF#16147 | 2018-May Core - In Person Claude |
| GF#20483 | Add Encounter.diagnoses elements to Condition In Person |
| GF#16148 | Encounter.reason and Encounter.diagnosis (PA) In Person |
| GF#18829 | Make element naming and modeling more consistent for Appointment/Encounter reason - STU #27 |
| GF#13668 | Remove reference to Procedure as an option in Encounter/diagnosis |
Master tracker: FHIR-16148 - Getting issue details... STATUS
FHIR-22764 - Getting issue details... STATUS
FHIR-22797 - Getting issue details... STATUS
FHIR-22850 - Getting issue details... STATUS
FHIR-28188 - Getting issue details... STATUS
FHIR-19285 - Getting issue details... STATUS
FHIR-28590 - Getting issue details... STATUS
FHIR-28590 - Getting issue details... STATUS
FHIR-29818 - Getting issue details... STATUS
FHIR-33006 - Getting issue details... STATUS
FHIR-36307 - Getting issue details... STATUS
This has been discussed previously in (at least) two WGMs and a few conference calls:
Design
Resource References
May 2019
Sept 2019
September 2020 Virtual WGM Monday 4:00 PM - 5:30 PM ET
Input for joined session with PC, CQI and CDS
All,
This email is going to the following 8 HL7 groups to request a combined meeting (perhaps some sort of Birds-of-a-Feather or 2-hour session during the upcoming virtual HL7 WGM. The issue came up because of differences in the way a Claim or an Encounter diagnosis might represent a primary diagnosis, a principal diagnosis, and how to represent Claim and Encounter diagnosis in a harmonized manner. They are currently different as shown in the attached slide deck. I apologize in advance if I mis-represented anything in the deck. I am trying to get a good handle on how HL7 can manage this encounter-related diagnosis issue consistently. This issue arose when considering how CQI creates QI-Core to address an Encounter.diagnosis with rank (or sequence).
If we can all align on a common meeting time or 2 or 3 separate meeting times to discuss, that would be very helpful.
I look forward to learning when we can meet.
- Patient Administration: Alexander de Leon, Brian Postlethwaite, Irma Jongeneel-de Haas, Line Saele
- Financial Management: Kathleen Connor, Mary Kay McDaniel, Andy Stechishin, Paul Knapp, Benoit Schoeffler
- Patient Care: Stephen Chu, Emma Jones, Michelle Miller, Michael Tan, Laura Heermann Langford, Jay Lyle, Michael Padula
- Vocabulary: Reuben Daniels, Robert Hausam, Carol Macumber, Heather Grain, Ted Klein, Rob McClure
- CARIN Alliance: Amol Vyas, Pat Taylor, Lisa Nelson
- US Core: Brett Marquard, Eric Haas
- CGP Co-chairs: Floyd Eisenberg (me), Jean Duteau
- CQI Co-chairs: Floyd Eisenberg (me), Juliet Rubini, Paul Denning, Patty Craig, Yan Heras
Thank you all very much in advance – I understand timing is difficult since we include folks in New Zealand, Australia, Europe, England, US, Canada and perhaps some countries I missed.
Best Regards,
Floyd
Movement Resource Design notes
Orders and Observations considered creating a complete resource that would capture a more complete set of metadata around these events.
Task profile?
Conditions under which the movement took place - environmental
From a patient administrative perspective this could include other requirements for the movement to occur, such as wheelchairs, PPE, ...
Patient Transport could also fit into this space to transfer between facilities
Sept WGM Design Notes
Cooper Thompson 1/27/2021 12:31 PM: Updated during Joint PA/PC (with Paul from FM) Virtual WGM - Jan 2021
Cooper Thompson 1/28/2021 4:34 PM: Updated during PA Virtual WGM - Jan 2021 - Thurs Q3
Cooper Thompson 2/17/2021 2:29 PM: Updated during PA Conf Call - Feb 17 2021 - minor updates, finalized HCS inclusion. Ready for submission for more community feedback
--------------------------------------------
Encounter modification proposal
Changes proposed under tracker FHIR-16148 - Getting issue details... STATUS
--------------------------------------------
Encounter.reason 0..*
reason CodableReference 0..* (Condition | Procedure | Observation | ImmunizationRecommendation | HealthcareService)
use CodeableConcept 0..1 (new ValueSet including concepts like: Chief Complaint, Admitting Diagnosis, Reason for Visit, Health Maintenance (including screening))
rank int 0..1 - Do folks think we need this? Should this just be an extension? What do systems actually do ranking for the reason for encounter? Note that the question is about ranking reason , not encounter diagnoses (documented during the encounter), triage status, condition acuity, or ranking for the purpose of reimbursement (e.g. in the US)
encounter.reason Definition: The list of medical reasons or symptoms that is expected to be addressed during the encounter.
encounter.reason.reason Definition: The medical reason or symptom that is expected to be addressed during the encounter, expressed as a text, code or a reference to another resource.
Comments: The reason communicates what medical problem or symptom the patient has that should be addressed during the encounter. This reason could be patient reported complaint, a clinical indication that was determined in a previous encounter, or some planned care such as an immunization recommendation. In the case where you have a primary reason, but are expecting to also address other problems, you can list the primary reason with a use code of "Chief Complaint", while the other problems being addressed would have a use code of "Reason for Visit".
Examples:
- annual physical, pediatric checkups would use HealthcareService as the reason
- surgeries would could use Procedure, or possibly Condition as the reason
Encounter.diagnosis 0..*
condition CodableReference 0..* (Condition)
use CodeableConcept 0..1 (ValueSet: Rename:https://build.fhir.org/valueset-diagnosis-role.html to diagnosis-use-code, remove "Billing", add "Working" and "Final")
rank int 0..1 - Should this just be an extension or a native property? Note that the question is about ranking, not triage status, condition acuity, or ranking for the purpose of reimbursement (e.g. in the US)
encounter.diagnosis Definition: The list of medical condition that was addressed during the encounter.
encounter.diagnosis.condition Definition: The medical condition that was addressed during the encounter, expressed as a text, code or a reference to another resource.
Comments: The diagnosis communicates what medical conditions were actually addressed during the encounter. If a diagnosis was provided as a reason for visit, and was treated during the encounter, it may be listed in both Encounter.reason and Encounter.diagnosis. Diagnoses related to billing can be documented on the Account resources which supports ranking for the purpose of reimbursement.
--------------------------------------------
End encounter modification proposal
--------------------------------------------
Zulip thread:
https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Encounter.20reasons
Cooper Thompson 1/20/2022 3:06 PM
Joint PA/PC approved these changes in tracker FHIR-16148 - Getting issue details... STATUS . The decision was to drop the rank property, and include comments about how you can rank diagnosis for billing on Account. Implementers can also use extensions for rank if necessary in their jursdiction.
--------------------------------------------
Start account modification proposal
--------------------------------------------
Account modifications were tabled as of PA/PC WGM - Jan 2021. Needs more discussion with FM
FHIR-19285 - Getting issue details... STATUS
Account modification proposal (to handle the billing-related admitting diagnosis and POA tracking):
Account.diagnosis *..0 BackboneElement
condition Reference(Condition)
type 0..* CodeableConcept (Admitting, Discharge, Cause of Death, etc.)
rank positiveInt
Account.procedure 0..* BackboneElement
procedure *Reference(Procedure)
type CodeableConcept
rank positiveInt
--------------------------------------------
End account modification proposal
--------------------------------------------
Cooper Thompson 5/27/2021 7:25 AM
Overall, FM was fine with this high level approach in Account, just a lot of details to work out on value sets and guidance.
Cooper Thompson 1/28/2021 4:32 PM
PA Virtual WGM Thurs Q3 Jan 2021
We are leaning toward dropping Encounter.diagnosis and Encounter.procedure in favor of Encounter.reason above (potentially with a name of reasonForVisit, or something else).
Encounter.diagnosis 0..1 (BackboneElement) condition CodableReference 1..1 – should this also support coded only (i.e. use codeablereference) use CodeableConcept 0..1 (billing/admitting/etc) http://build.fhir.org/valueset-diagnosis-role.html (minus Billing, and maybe Chief Complaint) [Extensible] rank int 0..1
Definition: The list of diagnoses relevant to this encounter.
Comments: The diagnoses
This would include:
An admission diagnosis that was validated by a clinician during the encounter.
An alternate idea is to blow out the concepts in to discrete fields rather than folding them into reason/diagnosis properties with use codes. This was just an idea and only initially discussed.
reasonForVisit - this is the same as the chiefComplaint
admissionDiagnosis (/reason?)
chiefComplaint
transferDiagnosis (/reason?)
dischargeDiagnosis
comorbidityDiagnosis (this would be a Condition, not on Encounter)
encounterDiagnosis (this would be a Condition, not on Encounter)
administrativeReasonForFacility
Cooper Thompson 1/28/2021 2:13 PM
This sort of of procedure info can be included in either the reason (if a procedure is the reason for an encounter), or in the Account.diagnosis if you need a ranked list of procedures for billing. We are debating removing Encounter.procedure from this proposal.
We may want to revisit a ranked procedures in the context of waitlists or pre-admission rescheduling in future work.
Encounter.procedure (BackboneElement) 0..*
procedure CodableReference 1..1 (v2: PR1-14) use CodeableConcept 0..1 (billing/admitting/etc) – is this even needed here? Maybe quality measures? rank int 0..1
Definition: Reason the encounter takes place, expressed as a code or a reference to another resource.
Comments: .
Question: What is the example as to why we have the HealthcareService here?
Answer: There was some example given during Jan 2021 WGM that seemed to fit for HealthcareService, but honestly, we don't remember what the example was. Drug/alcohol counseling could be a good example of this. Also, well-child visits or annual checkups. Dialysis might be a HealthcareService or a Procedure.
Question: What are the types that go on the procedure backbone element?
Question: What guidance to we provide for what procedures go on the Account? Only billable services, or other relevant procedures?