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