1a. Project Name

Argonaut Patient List Project

1b. Project ID

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact being Reaffirmed or proceeding to Normative directly after being either Informative or STU?

No

1e. Today's Date

1f. Name of standard being reaffirmed

1g. Project Artifact Information

1h. ISO/IEC Standard to Adopt

1i. Does the standard include excerpted text from one or more ISO, IEC or ISO/IEC standards, but is not an identical or modified adoption?

1j. Unit of Measure

2a. Primary/Sponsor WG

Patient Administration

2b. Co-Sponsor WG

FHIR Infrastructure

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballot

2b. Co-Sponsor WG 2

Patient Care

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballot

2b. Co-Sponsor WG 3

Clinical Quality Information

2c. Co-Sponsor Level of Involvement

Request periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2c. Co-Sponsor 3 Update Periods

WGMs

2b. Co-Sponsor WG 4

Financial Management

2d. Project Facilitator

Eric Haas

2e. Other Interested Parties (and roles)

2f. Modeling Facilitator

Eric Haas

2g. Publishing Facilitator

Eric Haas

2h. Vocabulary Facilitator

Eric Haas

2i. Domain Expert Representative

Isaac Vetter

2j. Business Requirements Analyst

Isaac Vetter

2k. Conformance Facilitator

Eric Haas

2l. Other Facilitators

2m. Implementers

1. Epic
2. MIcrosoft (RI)

3a. Project Scope

Support interoperable and standard exchange of existing EHR supported "user-facing lists".
- user-facing lists include both "system-maintained" and "user-maintained"(which are entirely ad-hoc - the user explicitly selects and manages members) lists
* Define a general framework using the FHIR API for exposing existing EHR user-facing patient lists so that EHR systems can expose any list they choose to define.

* This API would allows user-facing apps to:
1. Discover user-facing lists
- Search on existing list using very limited set of parameters such as "location characterstics" (for system-maintained lists) or Practitioner (for user-maintained list)
1. Fetch the List allowing app to enumerate members of a user-facing list
1. Provide a framework to convey other details about the members of a list

Writing, creating or managing a patient list is out of scope for this IG. Fetching client defined patients lists is also out of scope.

Current artifacts:
running notes:

https://docs.google.com/document/d/1fvb36PLO789YEkj24KrGa8YvacWMx3iRUT3fKVUUDLA/edit

draft IG for Argonaut:

https://hackmd.io/iLbMj3DVTtaNjTsseYAo5g?view

Attachments

3b. Project Need

User-facing apps often need to know things like:

- "who are the patients I'm seeing today,"
- "who are the patients I'm responsible for in the hospital right now,"
- "who are the patients in this ward."

This is core functionality supported by existing EHR systems. In FHIR, various methods have been used such as the standard search API or assembling the List or Group resource. However, no standard or guidance for creation of and manipulation of patient lists currently exists.

3c. Security Risk

No

3d. External Drivers

3e. Objectives/Deliverables and Target Dates

Deliverables: Implementation Guide

The IG will document the specification for retrieval of existing patients lists from a data source and mechanism for retrieval of other data about the members of a list. The interactions will be limited to Direct FHIR RESTful queries. The IG will also document the background for this use case.

Writing, creating or managing a patient list is out of scope for this IG. Fetching real-time client defined lists is also out of scope.

This IG will most likely include the following FHIR artifacts:

- Profile the Group, Questionnaire and QuestionnaireResponse resource
- Extensions for the Group resource
- Limited "starter set" terminology for the Group Resource
- SearchParameters

Custom operations are not anticipated.

TargetDate/Ballot Cycle: TBD and determined by level of adoption of existing argonaut project ig and maturity of real world testing and implementation experience.

3f. Common Names / Keywords / Aliases:

Patient Lists, Argo Patient Lists, PL, Argo PL

3g. Lineage

3h. Project Dependencies

US Core

3i. HL7-Managed Project Document Repository URL:

https://github.com/HL7/patient-lists

3j. Backwards Compatibility

N/A

3k. Additional Backwards Compatibility Information (if applicable)

3l. Using Current V3 Data Types?

N/A

3l. Reason for not using current V3 data types?

3m. External Vocabularies

No

3n. List of Vocabularies

3o. Earliest prior release and/or version to which the compatibility applies

N/A

4a. Products

FHIR Extensions, FHIR Implementation Guide, FHIR Profiles

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

4.0.1

4c. FHIR Profiles Version

1.0.0

4d. Please define your New Product Definition

4d. Please define your New Product Family

5a. Project Intent

Create new standard

5a. White Paper Type

5a. Is the project adopting/endorsing an externally developed IG?

5a. Externally developed IG is to be (select one)

5a. Specify external organization

5a. Revising Current Standard Info

5b. Project Ballot Type

STU to Normative

5c. Additional Ballot Info

5d. Joint Copyright

No

5e. I understand I must submit a Joint Copyright Letter of Agreement to the TSC in order for the PSS to receive TSC approval.

no

6a. External Project Collaboration

6b. Content Already Developed

80

6c. Content externally developed?

No

6d. List Developers of Externally Developed Content

6e. Is this a hosted (externally funded) project?

Yes

6f. Stakeholders

Other

6f. Other Stakeholders

Providers

6g. Vendors

EHR, PHR, Clinical Decision Support Systems

6g. Other Vendors

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health)

6h. Other Providers

6i. Realm

U.S. Realm Specific

7d. US Realm Approval Date

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

7c. Co-Sponsor Approval Date

Nov 30, 2020

7c. Co-Sponsor 2 Approval Date

Dec 14, 2020

7c. Co-Sponsor 3 Approval Date

Dec 18, 2020

7c. Co-Sponsor 4 Approval Date

7c. Co-Sponsor 5 Approval Date

7c. Co-Sponsor 6 Approval Date

7c. Co-Sponsor 7 Approval Date

7c. Co-Sponsor 8 Approval Date

7c. Co-Sponsor 9 Approval Date

7c. Co-Sponsor 10 Approval Date

7e. CDA MG Approval Date

7f. FMG Approval Date

7g. V2 MG Approval Date

7h. Architecture Review Board Approval Date

7i. Steering Division Approval Date

7j. TSC Approval Date



Version

9

Modifier

Eric Haas

Modify Date

Dec 18, 2020 18:29

1a. Project Name

Argonaut Patient List Project

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Patient Administration

2b. Co-Sponsor WG

FHIR Infrastructure

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballot

2b. Co-Sponsor WG 2

Patient Care

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballot

2c. Co-Sponsor Level of Involvement

Request periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2c. Co-Sponsor 3 Update Periods

WGMs

2d. Project Facilitator

Eric Haas

2f. Modeling Facilitator

Eric Haas

2g. Publishing Facilitator

Eric Haas

2h. Vocabulary Facilitator

Eric Haas

2i. Domain Expert Representative

Isaac Vetter

2j. Business Requirements Analyst

Isaac Vetter

2k. Conformance Facilitator

Eric Haas

2m. Implementers

1. Epic
2. MIcrosoft (RI)

3a. Project Scope

Support interoperable and standard exchange of existing EHR supported "user-facing lists".
- user-facing lists include both "system-maintained" and "user-maintained"(which are entirely ad-hoc - the user explicitly selects and manages members) lists
* Define a general framework using the FHIR API for exposing existing EHR user-facing patient lists so that EHR systems can expose any list they choose to define.

* This API would allows user-facing apps to:
1. Discover user-facing lists
- Search on existing list using very limited set of parameters such as "location characterstics" (for system-maintained lists) or Practitioner (for user-maintained list)
1. Fetch the List allowing app to enumerate members of a user-facing list
1. Provide a framework to convey other details about the members of a list

Writing, creating or managing a patient list is out of scope for this IG. Fetching client defined patients lists is also out of scope.

Current artifacts:
running notes:

https://docs.google.com/document/d/1fvb36PLO789YEkj24KrGa8YvacWMx3iRUT3fKVUUDLA/edit

draft IG for Argonaut:

https://hackmd.io/iLbMj3DVTtaNjTsseYAo5g?view

3b. Project Need

User-facing apps often need to know things like:

- "who are the patients I'm seeing today,"
- "who are the patients I'm responsible for in the hospital right now,"
- "who are the patients in this ward."

This is core functionality supported by existing EHR systems. In FHIR, various methods have been used such as the standard search API or assembling the List or Group resource. However, no standard or guidance for creation of and manipulation of patient lists currently exists.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Deliverables: Implementation Guide

The IG will document the specification for retrieval of existing patients lists from a data source and mechanism for retrieval of other data about the members of a list. The interactions will be limited to Direct FHIR RESTful queries. The IG will also document the background for this use case.

Writing, creating or managing a patient list is out of scope for this IG. Fetching real-time client defined lists is also out of scope.

This IG will most likely include the following FHIR artifacts:

- Profile the Group, Questionnaire and QuestionnaireResponse resource
- Extensions for the Group resource
- Limited "starter set" terminology for the Group Resource
- SearchParameters

Custom operations are not anticipated.

TargetDate/Ballot Cycle: TBD and determined by level of adoption of existing argonaut project ig and maturity of real world testing and implementation experience.

3f. Common Names / Keywords / Aliases:

Patient Lists, Argo Patient Lists, PL, Argo PL

3h. Project Dependencies

US Core

3i. HL7-Managed Project Document Repository URL:

https://github.com/HL7/patient-lists

3j. Backwards Compatibility

N/A

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

No

3o. Earliest prior release and/or version to which the compatibility applies

N/A

4a. Products

FHIR Extensions, FHIR Implementation Guide, FHIR Profiles

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

4.0.1

4c. FHIR Profiles Version

1.0.0

5a. Project Intent

Create new standard

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6b. Content Already Developed

80

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

Yes

6f. Stakeholders

Other

6f. Other Stakeholders

Providers

6g. Vendors

EHR, PHR, Clinical Decision Support Systems

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7c. Co-Sponsor Approval Date

Nov 30, 2020

7c. Co-Sponsor 2 Approval Date

Dec 14, 2020

7c. Co-Sponsor 3 Approval Date

Dec 18, 2020

Version

8

Modifier

Eric Haas

Modify Date

Dec 14, 2020 22:52

1a. Project Name

Argonaut Patient List Project

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Patient Administration

2b. Co-Sponsor WG

FHIR Infrastructure

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballot

2b. Co-Sponsor WG 2

Patient Care

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballot

2d. Project Facilitator

Eric Haas

2f. Modeling Facilitator

Eric Haas

2g. Publishing Facilitator

Eric Haas

2h. Vocabulary Facilitator

Eric Haas

2i. Domain Expert Representative

Isaac Vetter

2j. Business Requirements Analyst

Isaac Vetter

2k. Conformance Facilitator

Eric Haas

2m. Implementers

1. Epic
2. MIcrosoft (RI)

3a. Project Scope

Support interoperable and standard exchange of existing EHR supported "user-facing lists".
- user-facing lists include both "system-maintained" and "user-maintained"(which are entirely ad-hoc - the user explicitly selects and manages members) lists
* Define a general framework using the FHIR API for exposing existing EHR user-facing patient lists so that EHR systems can expose any list they choose to define.

* This API would allows user-facing apps to:
1. Discover user-facing lists
- Search on existing list using very limited set of parameters such as "location characterstics" (for system-maintained lists) or Practitioner (for user-maintained list)
1. Fetch the List allowing app to enumerate members of a user-facing list
1. Provide a framework to convey other details about the members of a list

Writing, creating or managing a patient list is out of scope for this IG. Fetching client defined patients lists is also out of scope.

Current artifacts:
running notes:

https://docs.google.com/document/d/1fvb36PLO789YEkj24KrGa8YvacWMx3iRUT3fKVUUDLA/edit

draft IG for Argonaut:

https://hackmd.io/iLbMj3DVTtaNjTsseYAo5g?view

3b. Project Need

User-facing apps often need to know things like:

- "who are the patients I'm seeing today,"
- "who are the patients I'm responsible for in the hospital right now,"
- "who are the patients in this ward."

This is core functionality supported by existing EHR systems. In FHIR, various methods have been used such as the standard search API or assembling the List or Group resource. However, no standard or guidance for creation of and manipulation of patient lists currently exists.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Deliverables: Implementation Guide

The IG will document the specification for retrieval of existing patients lists from a data source and mechanism for retrieval of other data about the members of a list. The interactions will be limited to Direct FHIR RESTful queries. The IG will also document the background for this use case.

Writing, creating or managing a patient list is out of scope for this IG. Fetching real-time client defined lists is also out of scope.

This IG will most likely include the following FHIR artifacts:

- Profile the Group, Questionnaire and QuestionnaireResponse resource
- Extensions for the Group resource
- Limited "starter set" terminology for the Group Resource
- SearchParameters

Custom operations are not anticipated.

TargetDate/Ballot Cycle: TBD and determined by level of adoption of existing argonaut project ig and maturity of real world testing and implementation experience.

3f. Common Names / Keywords / Aliases:

Patient Lists, Argo Patient Lists, PL, Argo PL

3h. Project Dependencies

US Core

3i. HL7-Managed Project Document Repository URL:

https://github.com/HL7/patient-lists

3j. Backwards Compatibility

N/A

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

No

3o. Earliest prior release and/or version to which the compatibility applies

N/A

4a. Products

FHIR Extensions, FHIR Implementation Guide, FHIR Profiles

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

4.0.1

4c. FHIR Profiles Version

1.0.0

5a. Project Intent

Create new standard

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6b. Content Already Developed

80

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

Yes

6f. Stakeholders

Other

6f. Other Stakeholders

Providers

6g. Vendors

EHR, PHR, Clinical Decision Support Systems

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7c. Co-Sponsor Approval Date

Nov 30, 2020

7c. Co-Sponsor 2 Approval Date

Dec 14, 2020

Version

7

Modifier

Eric Haas

Modify Date

Nov 30, 2020 20:33

1a. Project Name

Argonaut Patient List Project

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Patient Administration

2b. Co-Sponsor WG

FHIR Infrastructure

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballot

2b. Co-Sponsor WG 2

Patient Care

2d. Project Facilitator

Eric Haas

2f. Modeling Facilitator

Eric Haas

2g. Publishing Facilitator

Eric Haas

2h. Vocabulary Facilitator

Eric Haas

2i. Domain Expert Representative

Isaac Vetter

2j. Business Requirements Analyst

Isaac Vetter

2k. Conformance Facilitator

Eric Haas

2m. Implementers

1. Epic
2. MIcrosoft (RI)

3a. Project Scope

Support interoperable and standard exchange of existing EHR supported "user-facing lists".
- user-facing lists include both "system-maintained" and "user-maintained"(which are entirely ad-hoc - the user explicitly selects and manages members) lists
* Define a general framework using the FHIR API for exposing existing EHR user-facing patient lists so that EHR systems can expose any list they choose to define.

* This API would allows user-facing apps to:
1. Discover user-facing lists
- Search on existing list using very limited set of parameters such as "location characterstics" (for system-maintained lists) or Practitioner (for user-maintained list)
1. Fetch the List allowing app to enumerate members of a user-facing list
1. Provide a framework to convey other details about the members of a list

Writing, creating or managing a patient list is out of scope for this IG. Fetching client defined patients lists is also out of scope.

Current artifacts:
running notes:

https://docs.google.com/document/d/1fvb36PLO789YEkj24KrGa8YvacWMx3iRUT3fKVUUDLA/edit

draft IG for Argonaut:

https://hackmd.io/iLbMj3DVTtaNjTsseYAo5g?view

3b. Project Need

User-facing apps often need to know things like:

- "who are the patients I'm seeing today,"
- "who are the patients I'm responsible for in the hospital right now,"
- "who are the patients in this ward."

This is core functionality supported by existing EHR systems. In FHIR, various methods have been used such as the standard search API or assembling the List or Group resource. However, no standard or guidance for creation of and manipulation of patient lists currently exists.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Deliverables: Implementation Guide

The IG will document the specification for retrieval of existing patients lists from a data source and mechanism for retrieval of other data about the members of a list. The interactions will be limited to Direct FHIR RESTful queries. The IG will also document the background for this use case.

Writing, creating or managing a patient list is out of scope for this IG. Fetching real-time client defined lists is also out of scope.

This IG will most likely include the following FHIR artifacts:

- Profile the Group, Questionnaire and QuestionnaireResponse resource
- Extensions for the Group resource
- Limited "starter set" terminology for the Group Resource
- SearchParameters

Custom operations are not anticipated.

TargetDate/Ballot Cycle: TBD and determined by level of adoption of existing argonaut project ig and maturity of real world testing and implementation experience.

3f. Common Names / Keywords / Aliases:

Patient Lists, Argo Patient Lists, PL, Argo PL

3h. Project Dependencies

US Core

3i. HL7-Managed Project Document Repository URL:

https://github.com/HL7/patient-lists

3j. Backwards Compatibility

N/A

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

No

3o. Earliest prior release and/or version to which the compatibility applies

N/A

4a. Products

FHIR Extensions, FHIR Implementation Guide, FHIR Profiles

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

4.0.1

4c. FHIR Profiles Version

1.0.0

5a. Project Intent

Create new standard

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6b. Content Already Developed

80

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

Yes

6f. Stakeholders

Other

6f. Other Stakeholders

Providers

6g. Vendors

EHR, PHR, Clinical Decision Support Systems

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

7c. Co-Sponsor Approval Date

Nov 30, 2020

Version

6

Modifier

Eric Haas

Modify Date

Nov 30, 2020 20:31

1a. Project Name

Argonaut Patient List Project

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Patient Administration

2b. Co-Sponsor WG

FHIR Infrastructure

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballot

2b. Co-Sponsor WG 2

Patient Care

2d. Project Facilitator

Eric Haas

2f. Modeling Facilitator

Eric Haas

2g. Publishing Facilitator

Eric Haas

2h. Vocabulary Facilitator

Eric Haas

2i. Domain Expert Representative

Isaac Vetter

2j. Business Requirements Analyst

Isaac Vetter

2k. Conformance Facilitator

Eric Haas

2m. Implementers

1. Epic
2. MIcrosoft (RI)

3a. Project Scope

Support interoperable and standard exchange of existing EHR supported "user-facing lists".
- user-facing lists include both "system-maintained" and "user-maintained"(which are entirely ad-hoc - the user explicitly selects and manages members) lists
* Define a general framework using the FHIR API for exposing existing EHR user-facing patient lists so that EHR systems can expose any list they choose to define.

* This API would allows user-facing apps to:
1. Discover user-facing lists
- Search on existing list using very limited set of parameters such as "location characterstics" (for system-maintained lists) or Practitioner (for user-maintained list)
1. Fetch the List allowing app to enumerate members of a user-facing list
1. Provide a framework to convey other details about the members of a list

Writing, creating or managing a patient list is out of scope for this IG. Fetching client defined patients lists is also out of scope.

Current artifacts:
running notes:

https://docs.google.com/document/d/1fvb36PLO789YEkj24KrGa8YvacWMx3iRUT3fKVUUDLA/edit

draft IG for Argonaut:

https://hackmd.io/iLbMj3DVTtaNjTsseYAo5g?view

3b. Project Need

User-facing apps often need to know things like:

- "who are the patients I'm seeing today,"
- "who are the patients I'm responsible for in the hospital right now,"
- "who are the patients in this ward."

This is core functionality supported by existing EHR systems. In FHIR, various methods have been used such as the standard search API or assembling the List or Group resource. However, no standard or guidance for creation of and manipulation of patient lists currently exists.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Deliverables: Implementation Guide

The IG will document the specification for retrieval of existing patients lists from a data source and mechanism for retrieval of other data about the members of a list. The interactions will be limited to Direct FHIR RESTful queries. The IG will also document the background for this use case.

Writing, creating or managing a patient list is out of scope for this IG. Fetching real-time client defined lists is also out of scope.

This IG will most likely include the following FHIR artifacts:

- Profile the Group, Questionnaire and QuestionnaireResponse resource
- Extensions for the Group resource
- Limited "starter set" terminology for the Group Resource
- SearchParameters

Custom operations are not anticipated.

TargetDate/Ballot Cycle: TBD and determined by level of adoption of existing argonaut project ig and maturity of real world testing and implementation experience.

3f. Common Names / Keywords / Aliases:

Patient Lists, Argo Patient Lists, PL, Argo PL

3h. Project Dependencies

US Core

3i. HL7-Managed Project Document Repository URL:

https://github.com/HL7/patient-lists

3j. Backwards Compatibility

N/A

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

No

3o. Earliest prior release and/or version to which the compatibility applies

N/A

4a. Products

FHIR Extensions, FHIR Implementation Guide, FHIR Profiles

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

4.0.1

4c. FHIR Profiles Version

1.0.0

5a. Project Intent

Create new standard

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6b. Content Already Developed

80

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

Yes

6f. Stakeholders

Other

6f. Other Stakeholders

Providers

6g. Vendors

EHR, PHR, Clinical Decision Support Systems

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

5

Modifier

Eric Haas

Modify Date

Nov 30, 2020 20:26

1a. Project Name

Argonaut Patient List Project

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Patient Administration

2b. Co-Sponsor WG

FHIR Infrastructure

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballot

2b. Co-Sponsor WG 2

Patient Care

2d. Project Facilitator

Eric Haas

2f. Modeling Facilitator

Eric Haas

2g. Publishing Facilitator

Eric Haas

2h. Vocabulary Facilitator

Eric Haas

2i. Domain Expert Representative

Isaac Vetter

2j. Business Requirements Analyst

Isaac Vetter

2k. Conformance Facilitator

Eric Haas

2m. Implementers

1. Epic
2. MIcrosoft (RI)

3a. Project Scope

Support interoperable and standard exchange of existing EHR supported "user-facing lists".
- user-facing lists include both "system-maintained" and "user-maintained"(which are entirely ad-hoc - the user explicitly selects and manages members) lists
* Define a general framework using the FHIR API for exposing existing EHR user-facing patient lists so that EHR systems can expose any list they choose to define.

* This API would allows user-facing apps to:
1. Discover user-facing lists
- Search on existing list using very limited set of parameters such as "location characterstics" (for system-maintained lists) or Practitioner (for user-maintained list)
1. Fetch the List allowing app to enumerate members of a user-facing list
1. Provide a framework to convey other details about the members of a list

Writing, creating or managing a patient list is out of scope for this IG. Fetching client defined patients lists is also out of scope.

3b. Project Need

User-facing apps often need to know things like:

- "who are the patients I'm seeing today,"
- "who are the patients I'm responsible for in the hospital right now,"
- "who are the patients in this ward."

This is core functionality supported by existing EHR systems. In FHIR, various methods have been used such as the standard search API or assembling the List or Group resource. However, no standard or guidance for creation of and manipulation of patient lists currently exists.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Deliverables: Implementation Guide

The IG will document the specification for retrieval of existing patients lists from a data source and mechanism for retrieval of other data about the members of a list. The interactions will be limited to Direct FHIR RESTful queries. The IG will also document the background for this use case.

Writing, creating or managing a patient list is out of scope for this IG. Fetching real-time client defined lists is also out of scope.

This IG will most likely include the following FHIR artifacts:

- Profile the Group, Questionnaire and QuestionnaireResponse resource
- Extensions for the Group resource
- Limited "starter set" terminology for the Group Resource
- SearchParameters

Custom operations are not anticipated.

TargetDate/Ballot Cycle: TBD and determined by level of adoption of existing argonaut project ig and maturity of real world testing and implementation experience.

3f. Common Names / Keywords / Aliases:

Patient Lists, Argo Patient Lists, PL, Argo PL

3h. Project Dependencies

US Core

3i. HL7-Managed Project Document Repository URL:

https://github.com/HL7/patient-lists

3j. Backwards Compatibility

N/A

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

No

3o. Earliest prior release and/or version to which the compatibility applies

N/A

4a. Products

FHIR Extensions, FHIR Implementation Guide, FHIR Profiles

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

4.0.1

4c. FHIR Profiles Version

1.0.0

5a. Project Intent

Create new standard

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6b. Content Already Developed

80

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

Yes

6f. Stakeholders

Other

6f. Other Stakeholders

Providers

6g. Vendors

EHR, PHR, Clinical Decision Support Systems

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

4

Modifier

Eric Haas

Modify Date

Nov 18, 2020 20:25

1a. Project Name

Argonaut Patient List Project

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Patient Administration

2b. Co-Sponsor WG

FHIR Infrastructure

2c. Co-Sponsor Level of Involvement

Request periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2b. Co-Sponsor WG 2

Patient Care

2d. Project Facilitator

Eric Haas

2f. Modeling Facilitator

Eric Haas

2g. Publishing Facilitator

Eric Haas

2h. Vocabulary Facilitator

Eric Haas

2i. Domain Expert Representative

Isaac Vetter

2j. Business Requirements Analyst

Isaac Vetter

2k. Conformance Facilitator

Eric Haas

2m. Implementers

1. Epic
2. MIcrosoft (RI)

3a. Project Scope

Support interoperable and standard exchange of existing EHR supported "user-facing lists".
- user-facing lists include both "system-maintained" and "user-maintained"(which are entirely ad-hoc - the user explicitly selects and manages members) lists
* Define a general framework using the FHIR API for exposing existing EHR user-facing patient lists so that EHR systems can expose any list they choose to define.

* This API would allows user-facing apps to:
1. Discover user-facing lists
- Search on existing list using very limited set of parameters such as "location characterstics" (for system-maintained lists) or Practitioner (for user-maintained list)
1. Fetch the List allowing app to enumerate members of a user-facing list
1. Provide a framework to convey other details about the members of a list

Writing, creating or managing a patient list is out of scope for this IG. Fetching client defined patients lists is also out of scope.

3b. Project Need

User-facing apps often need to know things like:

- "who are the patients I'm seeing today,"
- "who are the patients I'm responsible for in the hospital right now,"
- "who are the patients in this ward."

This is core functionality supported by existing EHR systems. In FHIR, various methods have been used such as the standard search API or assembling the List or Group resource. However, no standard or guidance for creation of and manipulation of patient lists currently exists.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Deliverables: Implementation Guide

The IG will document the specification for retrieval of existing patients lists from a data source and mechanism for retrieval of other data about the members of a list. The interactions will be limited to Direct FHIR RESTful queries. The IG will also document the background for this use case.

Writing, creating or managing a patient list is out of scope for this IG. Fetching real-time client defined lists is also out of scope.

This IG will most likely include the following FHIR artifacts:

- Profile the Group, Questionnaire and QuestionnaireResponse resource
- Extensions for the Group resource
- Limited "starter set" terminology for the Group Resource
- SearchParameters

Custom operations are not anticipated.

TargetDate/Ballot Cycle: TBD and determined by level of adoption of existing argonaut project ig and maturity of real world testing and implementation experience.

3f. Common Names / Keywords / Aliases:

Patient Lists, Argo Patient Lists, PL, Argo PL

3h. Project Dependencies

US Core

3i. HL7-Managed Project Document Repository URL:

https://github.com/HL7/patient-lists

3j. Backwards Compatibility

N/A

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

No

3o. Earliest prior release and/or version to which the compatibility applies

N/A

4a. Products

FHIR Extensions, FHIR Implementation Guide, FHIR Profiles

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

4.0.1

4c. FHIR Profiles Version

1.0.0

5a. Project Intent

Create new standard

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6b. Content Already Developed

80

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

Yes

6f. Stakeholders

Other

6f. Other Stakeholders

Providers

6g. Vendors

EHR, PHR, Clinical Decision Support Systems

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

3

Modifier

Eric Haas

Modify Date

Nov 11, 2020 18:31

1a. Project Name

Argonaut Patient List Project

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Patient Administration

2b. Co-Sponsor WG

FHIR Infrastructure

2c. Co-Sponsor Level of Involvement

Request periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2d. Project Facilitator

Eric Haas

2f. Modeling Facilitator

Eric Haas

2g. Publishing Facilitator

Eric Haas

2h. Vocabulary Facilitator

Eric Haas

2i. Domain Expert Representative

Isaac Vetter

2j. Business Requirements Analyst

Isaac Vetter

2k. Conformance Facilitator

Eric Haas

2m. Implementers

1. Epic
2. MIcrosoft (RI)

3a. Project Scope

Support interoperable and standard exchange of existing EHR supported "user-facing lists".
- user-facing lists include both "system-maintained" and "user-maintained"(which are entirely ad-hoc - the user explicitly selects and manages members) lists
* Define a general framework using the FHIR API for exposing existing EHR user-facing patient lists so that EHR systems can expose any list they choose to define.

* This API would allows user-facing apps to:
1. Discover user-facing lists
- Search on existing list using very limited set of parameters such as "location characterstics" (for system-maintained lists) or Practitioner (for user-maintained list)
1. Fetch the List allowing app to enumerate members of a user-facing list
1. Provide a framework to convey other details about the members of a list

Writing, creating or managing a patient list is out of scope for this IG. Fetching client defined patients lists is also out of scope.

3b. Project Need

User-facing apps often need to know things like:

- "who are the patients I'm seeing today,"
- "who are the patients I'm responsible for in the hospital right now,"
- "who are the patients in this ward."

This is core functionality supported by existing EHR systems. In FHIR, various methods have been used such as the standard search API or assembling the List or Group resource. However, no standard or guidance for creation of and manipulation of patient lists currently exists.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Deliverables: Implementation Guide

The IG will document the specification for retrieval of existing patients lists from a data source and mechanism for retrieval of other data about the members of a list. The interactions will be limited to Direct FHIR RESTful queries. The IG will also document the background for this use case.

Writing, creating or managing a patient list is out of scope for this IG. Fetching real-time client defined lists is also out of scope.

This IG will most likely include the following FHIR artifacts:

- Profile the Group, Questionnaire and QuestionnaireResponse resource
- Extensions for the Group resource
- Limited "starter set" terminology for the Group Resource
- SearchParameters

Custom operations are not anticipated.

TargetDate/Ballot Cycle: TBD and determined by level of adoption of existing argonaut project ig and maturity of real world testing and implementation experience.

3f. Common Names / Keywords / Aliases:

Patient Lists, Argo Patient Lists, PL, Argo PL

3h. Project Dependencies

US Core

3i. HL7-Managed Project Document Repository URL:

https://github.com/HL7/patient-lists

3j. Backwards Compatibility

N/A

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

No

3o. Earliest prior release and/or version to which the compatibility applies

N/A

4a. Products

FHIR Extensions, FHIR Implementation Guide, FHIR Profiles

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

4.0.1

4c. FHIR Profiles Version

1.0.0

5a. Project Intent

Create new standard

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6b. Content Already Developed

80

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

Yes

6f. Stakeholders

Other

6f. Other Stakeholders

Providers

6g. Vendors

EHR, PHR, Clinical Decision Support Systems

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

2

Modifier

Eric Haas

Modify Date

Nov 11, 2020 17:20

1a. Project Name

Argonaut Patient List Project

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Patient Administration

2b. Co-Sponsor WG

FHIR Infrastructure

2c. Co-Sponsor Level of Involvement

Request periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2d. Project Facilitator

Eric Haas

2f. Modeling Facilitator

Eric Haas

2g. Publishing Facilitator

Eric Haas

2h. Vocabulary Facilitator

Eric Haas

2i. Domain Expert Representative

Eric Haas

2j. Business Requirements Analyst

Eric Haas

2k. Conformance Facilitator

Eric Haas

2m. Implementers

1. ?
2. ?

3a. Project Scope

Support interoperable and standard exchange of existing EHR supported "user-facing lists".
- user-facing lists include both "system-maintained" and "user-maintained"(which are entirely ad-hoc - the user explicitly selects and manages members) lists
* Define a general framework using the FHIR API for exposing existing EHR user-facing patient lists so that EHR systems can expose any list they choose to define.

* This API would allows user-facing apps to:
1. Discover user-facing lists
- Search on existing list using very limited set of parameters such as "location characterstics" (for system-maintained lists) or Practitioner (for user-maintained list)
1. Fetch the List allowing app to enumerate members of a user-facing list
1. Provide a framework to convey other details about the members of a list

Writing, creating or managing a patient list is out of scope for this IG. Fetching client defined patients lists is also out of scope.

3b. Project Need

User-facing apps often need to know things like:

- "who are the patients I'm seeing today,"
- "who are the patients I'm responsible for in the hospital right now,"
- "who are the patients in this ward."

This is core functionality supported by existing EHR systems. In FHIR, various methods have been used such as the standard search API or assembling the List or Group resource. However, no standard or guidance for creation of and manipulation of patient lists currently exists.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Deliverables: Implementation Guide

The IG will document the specification for retrieval of existing patients lists from a data source and mechanism for retrieval of other data about the members of a list. The interactions will be limited to Direct FHIR RESTful queries. The IG will also document the background for this use case.

Writing, creating or managing a patient list is out of scope for this IG. Fetching real-time client defined lists is also out of scope.

This IG will most likely include the following FHIR artifacts:

- Profile the Group, Questionnaire and QuestionnaireResponse resource
- Extensions for the Group resource
- Limited "starter set" terminology for the Group Resource
- SearchParameters

Custom operations are not anticipated.

TargetDate/Ballot Cycle: TBD and determined by level of adoption of existing argonaut project ig and maturity of real world testing and implementation experience.

3f. Common Names / Keywords / Aliases:

Patient Lists, Argo Patient Lists, PL, Argo PL

3h. Project Dependencies

US Core

3i. HL7-Managed Project Document Repository URL:

https://github.com/HL7/patient-lists

3j. Backwards Compatibility

N/A

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

No

3o. Earliest prior release and/or version to which the compatibility applies

N/A

4a. Products

FHIR Extensions, FHIR Implementation Guide, FHIR Profiles

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

4.0.1

4c. FHIR Profiles Version

1.0.0

5a. Project Intent

Create new standard

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6b. Content Already Developed

80

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

Yes

6f. Stakeholders

Other

6f. Other Stakeholders

Providers

6g. Vendors

EHR, PHR, Clinical Decision Support Systems

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR

Version

1

Modifier

Eric Haas

Modify Date

Nov 11, 2020 17:09

1a. Project Name

Argonaut Patient List Project

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?

No

2a. Primary/Sponsor WG

Patient Administration

2b. Co-Sponsor WG

FHIR Infrastructure

2c. Co-Sponsor Level of Involvement

Request periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2d. Project Facilitator

Eric Haas

2f. Modeling Facilitator

Eric Haas

2g. Publishing Facilitator

Eric Haas

2h. Vocabulary Facilitator

Eric Haas

2i. Domain Expert Representative

Eric Haas

2j. Business Requirements Analyst

Eric Haas

2k. Conformance Facilitator

Eric Haas

2m. Implementers

1. ?
2. ?

3a. Project Scope

Support interoperable and standard exchange of existing EHR supported "user-facing lists".
- user-facing lists include both "system-maintained" and "user-maintained"(which are entirely ad-hoc - the user explicitly selects and manages members) lists
* Define a general framework using the FHIR API for exposing existing EHR user-facing patient lists so that EHR systems can expose any list they choose to define.

* This API would allows user-facing apps to:
1. Discover user-facing lists
- Search on existing list using very limited set of parameters such as "location characterstics" (for system-maintained lists) or Practitioner (for user-maintained list)
1. Fetch the List allowing app to enumerate members of a user-facing list
1. Provide a framework to convey other details about the members of a list

3b. Project Need

User-facing apps often need to know things like:

- "who are the patients I'm seeing today,"
- "who are the patients I'm responsible for in the hospital right now,"
- "who are the patients in this ward."

This is core functionality supported by existing EHR systems. In FHIR, various methods have been used such as the standard search API or assembling the List or Group resource. However, no standard or guidance for creation of and manipulation of patient lists currently exists.

3c. Security Risk

No

3e. Objectives/Deliverables and Target Dates

Deliverables: Implementation Guide

The IG will document the specification for retrieval of existing patients lists from a data source and mechanism for retrieval of other data about the members of a list. The interactions will be limited to Direct FHIR RESTful queries. The IG will also document the background for this use case.

Writing, creating or managing a patient list is out of scope for this IG. Fetching real-time client defined lists is also out of scope.

This IG will most likely include the following FHIR artifacts:

- Profile the Group, Questionnaire and QuestionnaireResponse resource
- Extensions for the Group resource
- Limited "starter set" terminology for the Group Resource
- SearchParameters

Custom operations are not anticipated.

TargetDate/Ballot Cycle: TBD and determined by level of adoption of existing argonaut project ig and maturity of real world testing and implementation experience.

3f. Common Names / Keywords / Aliases:

Patient Lists, Argo Patient Lists, PL, Argo PL

3h. Project Dependencies

US Core

3i. HL7-Managed Project Document Repository URL:

https://github.com/HL7/patient-lists

3j. Backwards Compatibility

N/A

3l. Using Current V3 Data Types?

N/A

3m. External Vocabularies

No

3o. Earliest prior release and/or version to which the compatibility applies

N/A

4a. Products

FHIR Extensions, FHIR Implementation Guide, FHIR Profiles

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

4.0.1

4c. FHIR Profiles Version

1.0.0

5a. Project Intent

Create new standard

5b. Project Ballot Type

STU to Normative

5d. Joint Copyright

No

6b. Content Already Developed

80

6c. Content externally developed?

No

6e. Is this a hosted (externally funded) project?

Yes

6f. Stakeholders

Other

6f. Other Stakeholders

Providers

6g. Vendors

EHR, PHR, Clinical Decision Support Systems

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health)

6i. Realm

U.S. Realm Specific

7a. Management Group(s) to Review PSS

FHIR