<style>.markdown-body { max-width: 1500px; }</style>
Statement of presence and properties of patient or provider authored documents that record a patient’s goals, preferences and priorities should a patient be unable to communicate them to a provider.
## :new: Observation Data Class
<!-- image of summary of changes-->
Draft
Final
...
<!-- markdown table summary of proposal use adobe to convert to excel and then script to markdown or just copy/paste -->
DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S)<br/>Standards listed are required. If more than one is listed, at least one is required unless otherwise noted. Where an applicable vocabulary standard has not been identified, this field will remain empty.|US Core V8 Proposal
---|---|---
| **Advance Directive Observation** <br/>Statement of presence and properties of patient or provider authored documents that record a patient’s goals, preferences and priorities should a patient be unable to communicate them to a provider. <br/> Usage note: May include whether a person has one or more advance directives, the type of advance directive, the location of the current source document, and whether it has been verified.<br/> Examples include but are not limited to indication that a living will is on file, reference to or location of durable medical power of attorney, and validating provider. | |:new: Observations (see details below)
### Known issues
1. Difficulty using Single Observation to express both Whether ADI's present and what and where they are.
3. How to link 2 Observations.
3. A FHIR Search of DocumentReference could provide this information instead of relying on an a US Core Observation Profile.
3. Conformaning to Pacio's [PACIO Advance Directive Information Implementation Guide]( https://hl7.org/fhir/us/pacio-adi/StructureDefinition-ADI-DocumentationObservation.html).
5. ADI document type binding to [Advance Directives Content Type](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1099.57/expansion/Latest)
2. in VSAC
1. will be used by CCDA too
3. duplicate codes type and category ([Advance Healthcare Directive Categories Grouper](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1115.25/expansion))
1. How to represent whether an ADI exists:
Proposal is an Observation Using a fixed code, "Advance directive/living will completed" code in `.code` and in `.value`, bind to "Yes"/"No"/"Unknown". (same pattern we used for pregnancy)
See the [Background](#Patterns-to-Represent-existence-of-ADI) for options discussed offline
3. Need to understand the "and whether it has been verified." (="validating provider") piece in USCDI and how is that be represented in CCDA and FHIR. Based on this [use case](https://build.fhir.org/ig/HL7/fhir-pacio-adi/system_use_cases.html#use-case-6-verify-current-version-of-ad-content) described in the PACIO Advance Directive Interoperability Implementation Guide:
- :thinking_face: What about Signatures?
- see background
1. Other actors (e.g. Author, Custodian)?
- supplied in the DocumentReference or the Document itself.
3. If we use DocumentReference to point to the ADI, we should add the ADI document types to the ["Common Clinical Notes"](https://hl7.org/fhir/us/core/clinical-notes.html#clinical-notes)
5. Like we do for most other Observation Profiles to support discovery and search, should we add a 0..1 MS category element of "advance-directive-observation"?
### Options
#### Option 1
**:new: Observation Profile + :new: DocumentReference Profile**
1. [US Core Observation ADI Documentation Profile2](https://healthedata1.github.io/USCDI5-Sandbox/StructureDefinition-us-core-observation-adi-documentation2.html)
- Represents whether patient ADI documents exist
- 0..1 MS category element of "advance-directive-observation"
- `.code` fixed to LOINC [45473-6](https://loinc.org/45473-6/)(Advance directive/living will completed)
- `.value` uses a SNOMED CT based Yes/No/Unknown valueset.
- add the `Observation.performer` and `Observation.issued` to address the "whether it has been verified." piece in USCDI
- 0..* MS reference(s) to ADI documents as [US Core ADI DocumentReference](https://healthedata1.github.io/USCDI5-Sandbox/StructureDefinition-us-core-adi-documentreference.html) using the standard FHIR [Supporting Info Extension](https://hl7.org/fhir/extensions/StructureDefinition-workflow-supportingInfo.html)
1. [US Core ADI DocumentReference](https://healthedata1.github.io/USCDI5-Sandbox/StructureDefinition-us-core-adi-documentreference.html)
- US Core DocumentReference + the following changes/additions:
- 0..1 MS `.category` element uses *extensible* VSAC's [Advance Healthcare Directive Categories Grouper](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1115.25/expansion/Latest)
- 1..1 MS `.type` element uses *extensible* VSAC's [Advance Directives Content Type](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1099.57/expansion/Latest)
- 0..1 MS `.authenticator` = a verifier
- 0..1 MS [US Core Authentication Time Extension](https://healthedata1.github.io/USCDI5-Sandbox/StructureDefinition-us-core-authentication-time.html) = verification. date
- the clinical period and other actors (e.g. Author, Custodian) can be supplied in the DocumentReference or the Document itself
##### Visualization
```graphviz
digraph hierarchy {
nodesep=1.0 // increases the separation between nodes
node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour
edge [color=Blue, style=dashed] //All the lines look like this
"ADI Presence Observation (Observation)"->{"Yes and here they are" NO "??Unknown??"}[ label=".value" ]
"Yes and here they are"->{"ADI1=Living Will (DocumentReference)" "ADI2=POLST (DocumentReference)"}[ label=".focus vs supportingInfo extension?" ]
"ADI1=Living Will (DocumentReference)"->"Verifier" [ label=".authenticator"]
"ADI1=Living Will (DocumentReference)"->"Verification Date" [ label="DocumentReference.attester.time extension?"]
"ADI1=Living Will (DocumentReference)"->"ADI Author" [ label=".author"]
"ADI1=Living Will (DocumentReference)"->"Advance Healthcare Directive Categories Grouper" [ label=".category"]
"ADI1=Living Will (DocumentReference)"->"Advance Directives Content Type" [ label=".type"]
"ADI1=Living Will (DocumentReference)"->"ADI Document itself" [ label=".content.attachment"]
}
```
##### Example Instances
- [ADI Observation Presence ADI Example2](https://healthedata1.github.io/USCDI5-Sandbox/Observation-ADI-example2.html)
- [ADI Observation Presence No ADI Example2](https://healthedata1.github.io/USCDI5-Sandbox/Observation-no-ADI-example2.html)
#### Option 2
**Two :new: Observation Profile + Reference to US Core DocumentReference**
1. [US Core Observation ADI Documentation Profile](https://healthedata1.github.io/USCDI5-Sandbox/StructureDefinition-us-core-observation-adi-documentation.html)
- Represents patients documents
- modeled closely to the Pacio profile but *more* constrained. (The Pacio Profile will be not be conformant.)
- 0..1 MS category element of "advance-directive-observation"
- `.code` uses *extensible* VSAC's [Advance Healthcare Directive Categories Grouper](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1115.25/expansion/Latest)
- `.value` uses *extensible* VSAC's [Advance Directives Content Type](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1099.57/expansion/Latest
- Add the ADI document types to the Common Clinical Notes ValueSet :thinking_face:
- add the `Observation.performer` and `Observation.issued` to address the "whether it has been verified." piece in USCDI
- Reference the Documents as US Core DocumentReference using `Observation.focus`
- Add guidance that the clinical period and other actors (e.g. Author, Custodian) can be supplied in the DocumentReference or the Document itself
1. [US Core Observation ADI Presence Profile](https://healthedata1.github.io/USCDI5-Sandbox/StructureDefinition-us-core-observation-adi-presence.html)
- Represents whether patient ADI documents exist
- 0..1 MS category element of "advance-directive-observation"
- `.code` fixed to LOINC [45473-6](https://loinc.org/45473-6/)(Advance directive/living will completed)
- `.value` uses a SNOMED CT based Yes/No/Unknown valueset.
- add the `Observation.performer` and `Observation.issued` to address the "whether it has been verified." piece in USCDI
##### Example Instances
- [ADI Observation Presence ADI Example](https://healthedata1.github.io/USCDI5-Sandbox/Observation-ADI-example.html)
- [ADI Observation Presence No ADI Example](https://healthedata1.github.io/USCDI5-Sandbox/Observation-no-ADI-example.html)
### Decisions
:ant:
### IG Updates
- [ ] USCDI Mapping Table
- [ ] New US Core Profile
- [ ] Implementation Specific Guidance
- [ ] Additions to Common Clinical data types and ValueSet
- [ ] New Example(s)
---
### Background
Pacio's ADI Guide:
#### Difference Between US Core and Pacio
1. US Core has no text or note Elements
2. US Core adds a category element in line with other US Core Observations
3. US Core constrains the focus element adding a must support for DocumentReference, other resource types are optional
4. US Core constrains the effective[x] element adding a must support for DateTime, other datatypes are optional
5. US Core constrains the extensible binding of values to limited set of codes, Pacio's is bound to all document types.
#### ADI document type binding options:
- VSAC's [Personal Advance Directive Document Types](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1115.22/expansion)
- Pros
1. used by [HL7 CDA® R2 Implementation Guide:
Personal Advance Care Plan (PACP) Document]
(https://www.hl7.org/implement/standards/product_brief.cfm?product_id=434)
1. in VSAC
- Cons
1. missing concepts mentioned in PACIO:
- 81352-7(MOLST or POLST) *this is ORD Scale and not DOC*
- 81351-9 (DNR) *this is ORD Scale and not DOC*
- 449891000124104 (No advance directive (finding))
- Pacio ADI's [Documentation Types](https://build.fhir.org/ig/HL7/fhir-pacio-adi/ValueSet-ADIDocumentationTypeVS.html)
- Pros
1. More Complete ( missing only 449891000124104 (No advance directive (finding)
- Cons
1. not in VSAC
2. Too large ( ~120 total and many irrelevant concepts e.g.,Wound care management note (record artifact) )
- [Mock up](https://healthedata1.github.io/USCDI5-Sandbox/ValueSet-us-core-adi-finding.html) uses [Advance Healthcare Directive Categories Grouper](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1115.25/expansion/Latest)
limited to values mentioned in Pacio
- Pros
1. Smaller than Pacio
2.in VSAC
3. Mostly complete starter set containing both patient and provider authored document values.
- Cons
1. not used by CCDA (yet?)
2. missing a "none found code" ( which we can hopefully add)
3. contains the Code 42348-3: Advance directives used in `Observation.code`
- See [Background](#Background) for
#### Understanding the "and whether it has been verified." (="validating provider") piece in USCDI and how is that be represented in CCDA and FHIR.
- Based on this [use case](https://build.fhir.org/ig/HL7/fhir-pacio-adi/system_use_cases.html#use-case-6-verify-current-version-of-ad-content) described in the PACIO Advance Directive Interoperability Implementation Guide:
- use `Observation.performer` and `Observation.issued`
- option to use the FHIR standard
- [Performer function Extension](https://hl7.org/fhir/extensions/StructureDefinition-event-performerFunction.html)
- :thinking_face: What about Signatures?
#### Patterns to Represent existence of ADI
Options discussed
1. Use the same "Advance directives" code in `.code` and add to the `.value` *document type valueset*. "449891000124104" (No advance directive (finding).
3. Use an alternate code, "Advance directive - none" code in `.code` and in `.value`, conditionally bind it to a value of "Yes"/"No"/"Unknown".
2. Use an alternate code, "Advance directive/living will completed" code in `.code` and in `.value`, conditionally bind it to a value of "Yes"/"No"/"Unknown".
and mocked up examples :point_right: [here](https://healthedata1.github.io/USCDI5-Sandbox/artifacts.html#example-example-instances)
Sign in with Wallet
Connect another wallet