FHIR at Scale (FAST): Exchange with or without Intermediaries
1b. Project ID
1653
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
N/A
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
FHIR Infrastructure
2b. Co-Sponsor WG
Implementable Technology Specifications
2c. Co-Sponsor Level of Involvement
Request formal content review prior to ballot
2d. Project Facilitator
Patrick Murta
2e. Other Interested Parties (and roles)
2f. Modeling Facilitator
2g. Publishing Facilitator
2h. Vocabulary Facilitator
2i. Domain Expert Representative
2j. Business Requirements Analyst
Durwin Day
2k. Conformance Facilitator
Lloyd McKenzie
2l. Other Facilitators
2m. Implementers
Humana, Health Care Service Corporation (HCSC)
3a. Project Scope
As the the need for integration between different actors in healthcare has grown, the aspect of transactions routings across one or more intermediaries such as clearinghouses, HIEs, national networks, and other exchanges is recognized. An example of this scenario is when a payer uses a clearinghouse intermediary as their 'gateway' for transactions. There are both technical and business operational value adds in this intermediary model. This model was born in the world of the original X12 transaction set and it is expected to continue in the evolving RESTful FHIR API integration model. Other networks including HIEs and national networks, have emerged as brokering intermediaries (document access/exchange, e-prescribing, etc.), that may also engage in FHIR based interoperability.
In the model described above, the interaction originator will know the the final destination but will be abstracted from the number of intermediaries involved in the message routing. For example, if provider A needs to request information from payer B and payer B uses a payer agnostic intermediary, provider A will initiate the interaction with a known endpoint representing payer B, which in this case is an intermediary, and the intermediary will handle routing of the transaction and provide any value-add services. The intermediary, or intermediaries, will need to have origination and routing information available during the life-cycle of the transaction to ensure appropriate delivery.
A variation of the use case is one in which the requester, provider A, simply provides the request to their intermediary who then provides routing information so that the transaction can move across additional intermediaries before getting to payer B.
Of course, there are cases in which there are no intermediaries involved and the routing information is not explicitly needed, but there is no harm with it being available.
Our goal is to provide a model which supports a hybrid model of point to point interaction as well as intermediary brokered interaction without the actors in either side needing detailed knowledge of how intermediary routing works.
A reliable routing solution needs to support:
• Consistent definition and representation of routing information
• Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns
• A hybrid environment - transactions over both dynamic point to point and intermediary brokered models
The planned approach is to create an IG which uses the model described as part of Custom Headers defined within the FHIR Exchange Module (http://build.fhir.org/http.html#custom) with proposed new “X-Originator” and “X-Destination headers.
Solution advantages:
• Common pattern, used for many years in healthcare and other industries
• Lightweight
• Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available
• Universally usable, regardless of FHIR transaction – it’s resource agnostic
Supporting Reference:
This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019 and Summer 2020, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry.
Links to additional documentation:
https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/FAST+HL7+FHIR+Standard+Based+Solution+for+Intermediary-to-Intermediary+Exchange+-+Expert+Panel+Discussion
In today’s environment, FHIR integration is typically point-to-point without the need for routing information. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing.
3c. Security Risk
No
3d. External Drivers
3e. Objectives/Deliverables and Target Dates
FHIR Connectathon – 2021 Jan WGM
Submit for STU Ballot – 2021 May Ballot
FHIR Connectathon – 2021 May WGM
STU Reconciliation – June 2021
Publish STU 1 – July 2021
Submit 2nd STU Ballot – May 2022 Ballot
2nd STU Reconciliation – June 2022
Publish 2nd STU – July 2022
Submit Normative Ballot – 2023 Sept Ballot
Normative Reconciliation – November 2023
Publish Normative IG – December 2023
3f. Common Names / Keywords / Aliases:
Common Name: FAST Exchange Metadata; Keywords: FAST, Exchange, Metadata, Intermediaries
3k. Additional Backwards Compatibility Information (if applicable)
3l. Using Current V3 Data Types?
No
3l. Reason for not using current V3 data types?
Not applicable
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 Implementation Guide, FHIR Profiles
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
FHIR R4+
4c. FHIR Profiles Version
FHIR R4+
4d. Please define your New Product Definition
4d. Please define your New Product Family
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. White Paper Type
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Externally developed IG is to be (select one)
5a. Specify external organization
N/A
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
ONC FHIR at Scale Taskforce (FAST)
6b. Content Already Developed
Less than 10%
6c. Content externally developed?
No
6d. List Developers of Externally Developed Content
ONC FHIR at Scale Taskforce (FAST)
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors
6f. Other Stakeholders
6g. Vendors
Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6g. Other Vendors
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, Healthcare Institutions (hospitals, long term care, home care, mental health)
6h. Other Providers
6i. Realm
U.S. Realm Specific
7d. US Realm Approval Date
Nov 03, 2020
7a. Management Group(s) to Review PSS
FHIR
7b. Sponsoring WG Approval Date
Oct 13, 2020
7c. Co-Sponsor Approval Date
Dec 22, 2020
7c. Co-Sponsor 2 Approval Date
7c. Co-Sponsor 3 Approval Date
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
Nov 04, 2020
7g. V2 MG Approval Date
7h. Architecture Review Board Approval Date
7i. Steering Division Approval Date
Jan 04, 2021
7j. TSC Approval Date
Jan 11, 2021
Show Changes
Version
12
Modifier
Frank McKinney
Modify Date
Oct 27, 2021 18:09
1a. Project Name
FHIR at Scale (FAST): Exchange with or without Intermediaries
1b. Project ID
1653
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
1f. Name of standard being reaffirmed
N/A
2a. Primary/Sponsor WG
FHIR Infrastructure
2b. Co-Sponsor WG
Implementable Technology Specifications
2c. Co-Sponsor Level of Involvement
Request formal content review prior to ballot
2d. Project Facilitator
Patrick Murta
2j. Business Requirements Analyst
Durwin Day
2k. Conformance Facilitator
Lloyd McKenzie
2m. Implementers
Humana, Health Care Service Corporation (HCSC)
3a. Project Scope
As the the need for integration between different actors in healthcare has grown, the aspect of transactions routings across one or more intermediaries such as clearinghouses, HIEs, national networks, and other exchanges is recognized. An example of this scenario is when a payer uses a clearinghouse intermediary as their 'gateway' for transactions. There are both technical and business operational value adds in this intermediary model. This model was born in the world of the original X12 transaction set and it is expected to continue in the evolving RESTful FHIR API integration model. Other networks including HIEs and national networks, have emerged as brokering intermediaries (document access/exchange, e-prescribing, etc.), that may also engage in FHIR based interoperability.
In the model described above, the interaction originator will know the the final destination but will be abstracted from the number of intermediaries involved in the message routing. For example, if provider A needs to request information from payer B and payer B uses a payer agnostic intermediary, provider A will initiate the interaction with a known endpoint representing payer B, which in this case is an intermediary, and the intermediary will handle routing of the transaction and provide any value-add services. The intermediary, or intermediaries, will need to have origination and routing information available during the life-cycle of the transaction to ensure appropriate delivery.
A variation of the use case is one in which the requester, provider A, simply provides the request to their intermediary who then provides routing information so that the transaction can move across additional intermediaries before getting to payer B.
Of course, there are cases in which there are no intermediaries involved and the routing information is not explicitly needed, but there is no harm with it being available.
Our goal is to provide a model which supports a hybrid model of point to point interaction as well as intermediary brokered interaction without the actors in either side needing detailed knowledge of how intermediary routing works.
A reliable routing solution needs to support:
• Consistent definition and representation of routing information
• Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns
• A hybrid environment - transactions over both dynamic point to point and intermediary brokered models
The planned approach is to create an IG which uses the model described as part of Custom Headers defined within the FHIR Exchange Module (http://build.fhir.org/http.html#custom) with proposed new “X-Originator” and “X-Destination headers.
Solution advantages:
• Common pattern, used for many years in healthcare and other industries
• Lightweight
• Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available
• Universally usable, regardless of FHIR transaction – it’s resource agnostic
Supporting Reference:
This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019 and Summer 2020, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry.
Links to additional documentation:
https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/FAST+HL7+FHIR+Standard+Based+Solution+for+Intermediary-to-Intermediary+Exchange+-+Expert+Panel+Discussion
In today’s environment, FHIR integration is typically point-to-point without the need for routing information. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing.
3c. Security Risk
No
3e. Objectives/Deliverables and Target Dates
FHIR Connectathon – 2021 Jan WGM
Submit for STU Ballot – 2021 May Ballot
FHIR Connectathon – 2021 May WGM
STU Reconciliation – June 2021
Publish STU 1 – July 2021
Submit 2nd STU Ballot – May 2022 Ballot
2nd STU Reconciliation – June 2022
Publish 2nd STU – July 2022
Submit Normative Ballot – 2023 Sept Ballot
Normative Reconciliation – November 2023
Publish Normative IG – December 2023
3f. Common Names / Keywords / Aliases:
Common Name: FAST Exchange Metadata; Keywords: FAST, Exchange, Metadata, Intermediaries
3o. Earliest prior release and/or version to which the compatibility applies
N/A
4a. Products
FHIR Implementation Guide, FHIR Profiles
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
FHIR R4+
4c. FHIR Profiles Version
FHIR R4+
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Specify external organization
N/A
5b. Project Ballot Type
STU to Normative
5d. Joint Copyright
No
6a. External Project Collaboration
ONC FHIR at Scale Taskforce (FAST)
6b. Content Already Developed
Less than 10%
6c. Content externally developed?
No
6d. List Developers of Externally Developed Content
ONC FHIR at Scale Taskforce (FAST)
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors
6g. Vendors
Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, Healthcare Institutions (hospitals, long term care, home care, mental health)
6i. Realm
U.S. Realm Specific
7a. Management Group(s) to Review PSS
FHIR
7b. Sponsoring WG Approval Date
Oct 13, 2020
7c. Co-Sponsor Approval Date
Dec 22, 2020
7d. US Realm Approval Date
Nov 03, 2020
7f. FMG Approval Date
Nov 04, 2020
7i. Steering Division Approval Date
Jan 04, 2021
7j. TSC Approval Date
Jan 11, 2021
Version
11
Modifier
Anne Wizauer
Modify Date
Jan 12, 2021 20:52
1a. Project Name
FHIR at Scale (FAST): Exchange with or without Intermediaries
1b. Project ID
1653
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
1f. Name of standard being reaffirmed
N/A
2a. Primary/Sponsor WG
FHIR Infrastructure
2b. Co-Sponsor WG
Implementable Technology Specifications
2c. Co-Sponsor Level of Involvement
Request formal content review prior to ballot
2d. Project Facilitator
Patrick Murta
2j. Business Requirements Analyst
Durwin Day
2k. Conformance Facilitator
Lloyd McKenzie
2m. Implementers
Humana, Health Care Service Corporation (HCSC)
3a. Project Scope
As the the need for integration between different actors in healthcare has grown, the aspect of transactions routings across one or more intermediaries such as clearinghouses, HIEs, national networks, and other exchanges is recognized. An example of this scenario is when a payer uses a clearinghouse intermediary as their 'gateway' for transactions. There are both technical and business operational value adds in this intermediary model. This model was born in the world of the original X12 transaction set and it is expected to continue in the evolving RESTful FHIR API integration model. Other networks including HIEs and national networks, have emerged as brokering intermediaries (document access/exchange, e-prescribing, etc.), that may also engage in FHIR based interoperability.
In the model described above, the interaction originator will know the the final destination but will be abstracted from the number of intermediaries involved in the message routing. For example, if provider A needs to request information from payer B and payer B uses a payer agnostic intermediary, provider A will initiate the interaction with a known endpoint representing payer B, which in this case is an intermediary, and the intermediary will handle routing of the transaction and provide any value-add services. The intermediary, or intermediaries, will need to have origination and routing information available during the life-cycle of the transaction to ensure appropriate delivery.
A variation of the use case is one in which the requester, provider A, simply provides the request to their intermediary who then provides routing information so that the transaction can move across additional intermediaries before getting to payer B.
Of course, there are cases in which there are no intermediaries involved and the routing information is not explicitly needed, but there is no harm with it being available.
Our goal is to provide a model which supports a hybrid model of point to point interaction as well as intermediary brokered interaction without the actors in either side needing detailed knowledge of how intermediary routing works.
A reliable routing solution needs to support:
• Consistent definition and representation of routing information
• Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns
• A hybrid environment - transactions over both dynamic point to point and intermediary brokered models
The planned approach is to create an IG which uses the model described as part of Custom Headers defined within the FHIR Exchange Module (http://build.fhir.org/http.html#custom) with proposed new “X-Originator” and “X-Destination headers.
Solution advantages:
• Common pattern, used for many years in healthcare and other industries
• Lightweight
• Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available
• Universally usable, regardless of FHIR transaction – it’s resource agnostic
Supporting Reference:
This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019 and Summer 2020, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry.
Links to additional documentation:
https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/FAST+HL7+FHIR+Standard+Based+Solution+for+Intermediary-to-Intermediary+Exchange+-+Expert+Panel+Discussion
In today’s environment, FHIR integration is typically point-to-point without the need for routing information. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing.
3c. Security Risk
No
3e. Objectives/Deliverables and Target Dates
FHIR Connectathon – 2021 Jan WGM
Submit for STU Ballot – 2021 May Ballot
FHIR Connectathon – 2021 May WGM
STU Reconciliation – June 2021
Publish STU 1 – July 2021
Submit 2nd STU Ballot – May 2022 Ballot
2nd STU Reconciliation – June 2022
Publish 2nd STU – July 2022
Submit Normative Ballot – 2023 Sept Ballot
Normative Reconciliation – November 2023
Publish Normative IG – December 2023
3f. Common Names / Keywords / Aliases:
Common Name: FAST Exchange Metadata; Keywords: FAST, Exchange, Metadata, Intermediaries
3o. Earliest prior release and/or version to which the compatibility applies
N/A
4a. Products
FHIR Implementation Guide, FHIR Profiles
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
FHIR R4+
4c. FHIR Profiles Version
FHIR R4+
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Specify external organization
N/A
5b. Project Ballot Type
STU to Normative
5d. Joint Copyright
No
6a. External Project Collaboration
ONC FHIR at Scale Taskforce (FAST)
6b. Content Already Developed
Less than 10%
6c. Content externally developed?
Yes
6d. List Developers of Externally Developed Content
ONC FHIR at Scale Taskforce (FAST)
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors
6g. Vendors
Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, Healthcare Institutions (hospitals, long term care, home care, mental health)
6i. Realm
U.S. Realm Specific
7a. Management Group(s) to Review PSS
FHIR
7b. Sponsoring WG Approval Date
Oct 13, 2020
7c. Co-Sponsor Approval Date
Dec 22, 2020
7d. US Realm Approval Date
Nov 03, 2020
7f. FMG Approval Date
Nov 04, 2020
7i. Steering Division Approval Date
Jan 04, 2021
7j. TSC Approval Date
Jan 11, 2021
Version
10
Modifier
Anne Wizauer
Modify Date
Jan 05, 2021 21:57
1a. Project Name
FHIR at Scale (FAST): Exchange with or without Intermediaries
1b. Project ID
1653
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
1f. Name of standard being reaffirmed
N/A
2a. Primary/Sponsor WG
FHIR Infrastructure
2b. Co-Sponsor WG
Implementable Technology Specifications
2c. Co-Sponsor Level of Involvement
Request formal content review prior to ballot
2d. Project Facilitator
Patrick Murta
2j. Business Requirements Analyst
Durwin Day
2k. Conformance Facilitator
Lloyd McKenzie
2m. Implementers
Humana, Health Care Service Corporation (HCSC)
3a. Project Scope
As the the need for integration between different actors in healthcare has grown, the aspect of transactions routings across one or more intermediaries such as clearinghouses, HIEs, national networks, and other exchanges is recognized. An example of this scenario is when a payer uses a clearinghouse intermediary as their 'gateway' for transactions. There are both technical and business operational value adds in this intermediary model. This model was born in the world of the original X12 transaction set and it is expected to continue in the evolving RESTful FHIR API integration model. Other networks including HIEs and national networks, have emerged as brokering intermediaries (document access/exchange, e-prescribing, etc.), that may also engage in FHIR based interoperability.
In the model described above, the interaction originator will know the the final destination but will be abstracted from the number of intermediaries involved in the message routing. For example, if provider A needs to request information from payer B and payer B uses a payer agnostic intermediary, provider A will initiate the interaction with a known endpoint representing payer B, which in this case is an intermediary, and the intermediary will handle routing of the transaction and provide any value-add services. The intermediary, or intermediaries, will need to have origination and routing information available during the life-cycle of the transaction to ensure appropriate delivery.
A variation of the use case is one in which the requester, provider A, simply provides the request to their intermediary who then provides routing information so that the transaction can move across additional intermediaries before getting to payer B.
Of course, there are cases in which there are no intermediaries involved and the routing information is not explicitly needed, but there is no harm with it being available.
Our goal is to provide a model which supports a hybrid model of point to point interaction as well as intermediary brokered interaction without the actors in either side needing detailed knowledge of how intermediary routing works.
A reliable routing solution needs to support:
• Consistent definition and representation of routing information
• Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns
• A hybrid environment - transactions over both dynamic point to point and intermediary brokered models
The planned approach is to create an IG which uses the model described as part of Custom Headers defined within the FHIR Exchange Module (http://build.fhir.org/http.html#custom) with proposed new “X-Originator” and “X-Destination headers.
Solution advantages:
• Common pattern, used for many years in healthcare and other industries
• Lightweight
• Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available
• Universally usable, regardless of FHIR transaction – it’s resource agnostic
Supporting Reference:
This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019 and Summer 2020, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry.
Links to additional documentation:
https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/FAST+HL7+FHIR+Standard+Based+Solution+for+Intermediary-to-Intermediary+Exchange+-+Expert+Panel+Discussion
In today’s environment, FHIR integration is typically point-to-point without the need for routing information. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing.
3c. Security Risk
No
3e. Objectives/Deliverables and Target Dates
FHIR Connectathon – 2021 Jan WGM
Submit for STU Ballot – 2021 May Ballot
FHIR Connectathon – 2021 May WGM
STU Reconciliation – June 2021
Publish STU 1 – July 2021
Submit 2nd STU Ballot – May 2022 Ballot
2nd STU Reconciliation – June 2022
Publish 2nd STU – July 2022
Submit Normative Ballot – 2023 Sept Ballot
Normative Reconciliation – November 2023
Publish Normative IG – December 2023
3f. Common Names / Keywords / Aliases:
Common Name: FAST Exchange Metadata; Keywords: FAST, Exchange, Metadata, Intermediaries
3o. Earliest prior release and/or version to which the compatibility applies
N/A
4a. Products
FHIR Implementation Guide, FHIR Profiles
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
FHIR R4+
4c. FHIR Profiles Version
FHIR R4+
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Specify external organization
N/A
5b. Project Ballot Type
STU to Normative
5d. Joint Copyright
No
6a. External Project Collaboration
ONC FHIR at Scale Taskforce (FAST)
6b. Content Already Developed
Less than 10%
6c. Content externally developed?
Yes
6d. List Developers of Externally Developed Content
ONC FHIR at Scale Taskforce (FAST)
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors
6g. Vendors
Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, Healthcare Institutions (hospitals, long term care, home care, mental health)
6i. Realm
U.S. Realm Specific
7a. Management Group(s) to Review PSS
FHIR
7b. Sponsoring WG Approval Date
Oct 13, 2020
7c. Co-Sponsor Approval Date
Dec 22, 2020
7d. US Realm Approval Date
Nov 03, 2020
7f. FMG Approval Date
Nov 04, 2020
7i. Steering Division Approval Date
Jan 04, 2021
Version
9
Modifier
Paul Knapp
Modify Date
Dec 22, 2020 19:49
1a. Project Name
FHIR at Scale (FAST): Exchange with or without Intermediaries
1b. Project ID
1653
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
1f. Name of standard being reaffirmed
N/A
2a. Primary/Sponsor WG
FHIR Infrastructure
2b. Co-Sponsor WG
Implementable Technology Specifications
2c. Co-Sponsor Level of Involvement
Request formal content review prior to ballot
2d. Project Facilitator
Patrick Murta
2j. Business Requirements Analyst
Durwin Day
2k. Conformance Facilitator
Lloyd McKenzie
2m. Implementers
Humana, Health Care Service Corporation (HCSC)
3a. Project Scope
As the the need for integration between different actors in healthcare has grown, the aspect of transactions routings across one or more intermediaries such as clearinghouses, HIEs, national networks, and other exchanges is recognized. An example of this scenario is when a payer uses a clearinghouse intermediary as their 'gateway' for transactions. There are both technical and business operational value adds in this intermediary model. This model was born in the world of the original X12 transaction set and it is expected to continue in the evolving RESTful FHIR API integration model. Other networks including HIEs and national networks, have emerged as brokering intermediaries (document access/exchange, e-prescribing, etc.), that may also engage in FHIR based interoperability.
In the model described above, the interaction originator will know the the final destination but will be abstracted from the number of intermediaries involved in the message routing. For example, if provider A needs to request information from payer B and payer B uses a payer agnostic intermediary, provider A will initiate the interaction with a known endpoint representing payer B, which in this case is an intermediary, and the intermediary will handle routing of the transaction and provide any value-add services. The intermediary, or intermediaries, will need to have origination and routing information available during the life-cycle of the transaction to ensure appropriate delivery.
A variation of the use case is one in which the requester, provider A, simply provides the request to their intermediary who then provides routing information so that the transaction can move across additional intermediaries before getting to payer B.
Of course, there are cases in which there are no intermediaries involved and the routing information is not explicitly needed, but there is no harm with it being available.
Our goal is to provide a model which supports a hybrid model of point to point interaction as well as intermediary brokered interaction without the actors in either side needing detailed knowledge of how intermediary routing works.
A reliable routing solution needs to support:
• Consistent definition and representation of routing information
• Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns
• A hybrid environment - transactions over both dynamic point to point and intermediary brokered models
The planned approach is to create an IG which uses the model described as part of Custom Headers defined within the FHIR Exchange Module (http://build.fhir.org/http.html#custom) with proposed new “X-Originator” and “X-Destination headers.
Solution advantages:
• Common pattern, used for many years in healthcare and other industries
• Lightweight
• Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available
• Universally usable, regardless of FHIR transaction – it’s resource agnostic
Supporting Reference:
This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019 and Summer 2020, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry.
Links to additional documentation:
https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/FAST+HL7+FHIR+Standard+Based+Solution+for+Intermediary-to-Intermediary+Exchange+-+Expert+Panel+Discussion
In today’s environment, FHIR integration is typically point-to-point without the need for routing information. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing.
3c. Security Risk
No
3e. Objectives/Deliverables and Target Dates
FHIR Connectathon – 2021 Jan WGM
Submit for STU Ballot – 2021 May Ballot
FHIR Connectathon – 2021 May WGM
STU Reconciliation – June 2021
Publish STU 1 – July 2021
Submit 2nd STU Ballot – May 2022 Ballot
2nd STU Reconciliation – June 2022
Publish 2nd STU – July 2022
Submit Normative Ballot – 2023 Sept Ballot
Normative Reconciliation – November 2023
Publish Normative IG – December 2023
3f. Common Names / Keywords / Aliases:
Common Name: FAST Exchange Metadata; Keywords: FAST, Exchange, Metadata, Intermediaries
3o. Earliest prior release and/or version to which the compatibility applies
N/A
4a. Products
FHIR Implementation Guide, FHIR Profiles
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
FHIR R4+
4c. FHIR Profiles Version
FHIR R4+
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Specify external organization
N/A
5b. Project Ballot Type
STU to Normative
5d. Joint Copyright
No
6a. External Project Collaboration
ONC FHIR at Scale Taskforce (FAST)
6b. Content Already Developed
Less than 10%
6c. Content externally developed?
Yes
6d. List Developers of Externally Developed Content
ONC FHIR at Scale Taskforce (FAST)
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors
6g. Vendors
Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, Healthcare Institutions (hospitals, long term care, home care, mental health)
6i. Realm
U.S. Realm Specific
7a. Management Group(s) to Review PSS
FHIR
7b. Sponsoring WG Approval Date
Oct 13, 2020
7c. Co-Sponsor Approval Date
Dec 22, 2020
7d. US Realm Approval Date
Nov 03, 2020
7f. FMG Approval Date
Nov 04, 2020
Version
8
Modifier
Patrick Murta
Modify Date
Nov 06, 2020 12:06
1a. Project Name
FHIR at Scale (FAST): Exchange with or without Intermediaries
1b. Project ID
1653
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
1f. Name of standard being reaffirmed
N/A
2a. Primary/Sponsor WG
FHIR Infrastructure
2d. Project Facilitator
Patrick Murta
2j. Business Requirements Analyst
Durwin Day
2k. Conformance Facilitator
Lloyd McKenzie
2m. Implementers
Humana, Health Care Service Corporation (HCSC)
3a. Project Scope
As the the need for integration between different actors in healthcare has grown, the aspect of transactions routings across one or more intermediaries such as clearinghouses, HIEs, national networks, and other exchanges is recognized. An example of this scenario is when a payer uses a clearinghouse intermediary as their 'gateway' for transactions. There are both technical and business operational value adds in this intermediary model. This model was born in the world of the original X12 transaction set and it is expected to continue in the evolving RESTful FHIR API integration model. Other networks including HIEs and national networks, have emerged as brokering intermediaries (document access/exchange, e-prescribing, etc.), that may also engage in FHIR based interoperability.
In the model described above, the interaction originator will know the the final destination but will be abstracted from the number of intermediaries involved in the message routing. For example, if provider A needs to request information from payer B and payer B uses a payer agnostic intermediary, provider A will initiate the interaction with a known endpoint representing payer B, which in this case is an intermediary, and the intermediary will handle routing of the transaction and provide any value-add services. The intermediary, or intermediaries, will need to have origination and routing information available during the life-cycle of the transaction to ensure appropriate delivery.
A variation of the use case is one in which the requester, provider A, simply provides the request to their intermediary who then provides routing information so that the transaction can move across additional intermediaries before getting to payer B.
Of course, there are cases in which there are no intermediaries involved and the routing information is not explicitly needed, but there is no harm with it being available.
Our goal is to provide a model which supports a hybrid model of point to point interaction as well as intermediary brokered interaction without the actors in either side needing detailed knowledge of how intermediary routing works.
A reliable routing solution needs to support:
• Consistent definition and representation of routing information
• Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns
• A hybrid environment - transactions over both dynamic point to point and intermediary brokered models
The planned approach is to create an IG which uses the model described as part of Custom Headers defined within the FHIR Exchange Module (http://build.fhir.org/http.html#custom) with proposed new “X-Originator” and “X-Destination headers.
Solution advantages:
• Common pattern, used for many years in healthcare and other industries
• Lightweight
• Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available
• Universally usable, regardless of FHIR transaction – it’s resource agnostic
Supporting Reference:
This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019 and Summer 2020, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry.
Links to additional documentation:
https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/FAST+HL7+FHIR+Standard+Based+Solution+for+Intermediary-to-Intermediary+Exchange+-+Expert+Panel+Discussion
In today’s environment, FHIR integration is typically point-to-point without the need for routing information. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing.
3c. Security Risk
No
3e. Objectives/Deliverables and Target Dates
FHIR Connectathon – 2021 Jan WGM
Submit for STU Ballot – 2021 May Ballot
FHIR Connectathon – 2021 May WGM
STU Reconciliation – June 2021
Publish STU 1 – July 2021
Submit 2nd STU Ballot – May 2022 Ballot
2nd STU Reconciliation – June 2022
Publish 2nd STU – July 2022
Submit Normative Ballot – 2023 Sept Ballot
Normative Reconciliation – November 2023
Publish Normative IG – December 2023
3f. Common Names / Keywords / Aliases:
Common Name: FAST Exchange Metadata; Keywords: FAST, Exchange, Metadata, Intermediaries
3o. Earliest prior release and/or version to which the compatibility applies
N/A
4a. Products
FHIR Implementation Guide, FHIR Profiles
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
FHIR R4+
4c. FHIR Profiles Version
FHIR R4+
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Specify external organization
N/A
5b. Project Ballot Type
STU to Normative
5d. Joint Copyright
No
6a. External Project Collaboration
ONC FHIR at Scale Taskforce (FAST)
6b. Content Already Developed
Less than 10%
6c. Content externally developed?
Yes
6d. List Developers of Externally Developed Content
ONC FHIR at Scale Taskforce (FAST)
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors
6g. Vendors
Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, Healthcare Institutions (hospitals, long term care, home care, mental health)
6i. Realm
U.S. Realm Specific
7a. Management Group(s) to Review PSS
FHIR
7b. Sponsoring WG Approval Date
Oct 13, 2020
7d. US Realm Approval Date
Nov 03, 2020
7f. FMG Approval Date
Nov 04, 2020
Version
7
Modifier
Anne Wizauer
Modify Date
Nov 05, 2020 17:19
1a. Project Name
FAST Exchange Metadata Using RESTful Headers
1b. Project ID
1653
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
1f. Name of standard being reaffirmed
N/A
2a. Primary/Sponsor WG
FHIR Infrastructure
2d. Project Facilitator
Patrick Murta
2j. Business Requirements Analyst
Durwin Day
2k. Conformance Facilitator
Lloyd McKenzie
2m. Implementers
Humana, Health Care Service Corporation (HCSC)
3a. Project Scope
As the the need for integration between different actors in healthcare has grown, the aspect of transactions routings across one or more intermediaries such as clearinghouses and exchanges is recognized. An example of this scenario is when a payer uses a clearinghouse intermediary as their 'gateway' for transactions. There are both technical and business operational value adds in this intermediary model. This model was born in the world of the original X12 transaction set and it is expected to continue in the evolving RESTful FHIR API integration model. There are other examples as well such as HIEs/trust frameworks.
In the model described above, the interaction originator will know the the final destination but will be abstracted from the number of intermediaries involved in the message routing. For example, if provider A needs to request information from payer B and payer B uses a payer agnostic intermediary, provider A will initiate the interaction with a known endpoint representing payer B, which in this case is an intermediary, and the intermediary will handle routing of the transaction and provide any value-add services. The intermediary, or intermediaries, will need to have origination and routing information available during the life-cycle of the transaction to ensure appropriate delivery.
A variation of the use case is one in which the requester, provider A, simply provides the request to their intermediary who then provides routing information so that the transaction can move across additional intermediaries before getting to payer B.
Of course, there are cases in which there are no intermediaries involved and the routing information is not explicitly needed, but there is no harm with it being available.
Our goal is to provide a model which supports a hybrid model of point to point interaction as well as intermediary brokered interaction without the actors in either side needing detailed knowledge of how intermediary routing works.
A reliable routing solution needs to support:
• Consistent definition and representation of routing information
• Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns
• A hybrid environment - transactions over both dynamic point to point and intermediary brokered models
The planned approach is to create an IG which uses the model described as part of Custom Headers defined within the FHIR Exchange Module (http://build.fhir.org/http.html#custom) with proposed new “X-Originator” and “X-Destination headers.
Solution advantages:
• Common pattern, used for many years in healthcare and other industries
• Lightweight
• Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available
• Universally usable, regardless of FHIR transaction – it’s resource agnostic
Supporting Reference:
This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019 and Summer 2020, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry.
Links to additional documentation:
https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/FAST+HL7+FHIR+Standard+Based+Solution+for+Intermediary-to-Intermediary+Exchange+-+Expert+Panel+Discussion
In today’s environment, FHIR integration is typically point-to-point without the need for routing information. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing.
3c. Security Risk
No
3e. Objectives/Deliverables and Target Dates
FHIR Connectathon – 2021 Jan WGM
Submit for STU Ballot – 2021 May Ballot
FHIR Connectathon – 2021 May WGM
STU Reconciliation – June 2021
Publish STU 1 – July 2021
Submit 2nd STU Ballot – May 2022 Ballot
2nd STU Reconciliation – June 2022
Publish 2nd STU – July 2022
Submit Normative Ballot – 2023 Sept Ballot
Normative Reconciliation – November 2023
Publish Normative IG – December 2023
3f. Common Names / Keywords / Aliases:
Common Name: FAST Exchange Metadata; Keywords: FAST, Exchange, Metadata, Intermediaries
3o. Earliest prior release and/or version to which the compatibility applies
N/A
4a. Products
FHIR Implementation Guide, FHIR Profiles
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
FHIR R4+
4c. FHIR Profiles Version
FHIR R4+
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Specify external organization
N/A
5b. Project Ballot Type
STU to Normative
5d. Joint Copyright
No
6a. External Project Collaboration
ONC FHIR at Scale Taskforce (FAST)
6b. Content Already Developed
Less than 10%
6c. Content externally developed?
Yes
6d. List Developers of Externally Developed Content
ONC FHIR at Scale Taskforce (FAST)
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors
6g. Vendors
Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, Healthcare Institutions (hospitals, long term care, home care, mental health)
6i. Realm
U.S. Realm Specific
7a. Management Group(s) to Review PSS
FHIR
7b. Sponsoring WG Approval Date
Oct 13, 2020
7d. US Realm Approval Date
Nov 03, 2020
7f. FMG Approval Date
Nov 04, 2020
Version
6
Modifier
Dave Hamill
Modify Date
Oct 22, 2020 17:39
1a. Project Name
FAST Exchange Metadata Using RESTful Headers
1b. Project ID
1653
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
1f. Name of standard being reaffirmed
N/A
2a. Primary/Sponsor WG
FHIR Infrastructure
2d. Project Facilitator
Patrick Murta
2j. Business Requirements Analyst
Durwin Day
2k. Conformance Facilitator
Lloyd McKenzie
2m. Implementers
Humana, Health Care Service Corporation (HCSC)
3a. Project Scope
As the the need for integration between different actors in healthcare has grown, the aspect of transactions routings across one or more intermediaries such as clearinghouses and exchanges is recognized. An example of this scenario is when a payer uses a clearinghouse intermediary as their 'gateway' for transactions. There are both technical and business operational value adds in this intermediary model. This model was born in the world of the original X12 transaction set and it is expected to continue in the evolving RESTful FHIR API integration model. There are other examples as well such as HIEs/trust frameworks.
In the model described above, the interaction originator will know the the final destination but will be abstracted from the number of intermediaries involved in the message routing. For example, if provider A needs to request information from payer B and payer B uses a payer agnostic intermediary, provider A will initiate the interaction with a known endpoint representing payer B, which in this case is an intermediary, and the intermediary will handle routing of the transaction and provide any value-add services. The intermediary, or intermediaries, will need to have origination and routing information available during the life-cycle of the transaction to ensure appropriate delivery.
A variation of the use case is one in which the requester, provider A, simply provides the request to their intermediary who then provides routing information so that the transaction can move across additional intermediaries before getting to payer B.
Of course, there are cases in which there are no intermediaries involved and the routing information is not explicitly needed, but there is no harm with it being available.
Our goal is to provide a model which supports a hybrid model of point to point interaction as well as intermediary brokered interaction without the actors in either side needing detailed knowledge of how intermediary routing works.
A reliable routing solution needs to support:
• Consistent definition and representation of routing information
• Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns
• A hybrid environment - transactions over both dynamic point to point and intermediary brokered models
The planned approach is to create an IG which uses the model described as part of Custom Headers defined within the FHIR Exchange Module (http://build.fhir.org/http.html#custom) with proposed new “X-Originator” and “X-Destination headers.
Solution advantages:
• Common pattern, used for many years in healthcare and other industries
• Lightweight
• Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available
• Universally usable, regardless of FHIR transaction – it’s resource agnostic
Supporting Reference:
This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019 and Summer 2020, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry.
Links to additional documentation:
https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/FAST+HL7+FHIR+Standard+Based+Solution+for+Intermediary-to-Intermediary+Exchange+-+Expert+Panel+Discussion
In today’s environment, FHIR integration is typically point-to-point without the need for routing information. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing.
3c. Security Risk
No
3e. Objectives/Deliverables and Target Dates
FHIR Connectathon – 2021 Jan WGM
Submit for STU Ballot – 2021 May Ballot
FHIR Connectathon – 2021 May WGM
STU Reconciliation – June 2021
Publish STU 1 – July 2021
Submit 2nd STU Ballot – May 2022 Ballot
2nd STU Reconciliation – June 2022
Publish 2nd STU – July 2022
Submit Normative Ballot – 2023 Sept Ballot
Normative Reconciliation – November 2023
Publish Normative IG – December 2023
3f. Common Names / Keywords / Aliases:
Common Name: FAST Exchange Metadata; Keywords: FAST, Exchange, Metadata, Intermediaries
3o. Earliest prior release and/or version to which the compatibility applies
N/A
4a. Products
FHIR Implementation Guide, FHIR Profiles
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
FHIR R4+
4c. FHIR Profiles Version
FHIR R4+
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Specify external organization
N/A
5b. Project Ballot Type
STU to Normative
5d. Joint Copyright
No
6a. External Project Collaboration
ONC FHIR at Scale Taskforce (FAST)
6b. Content Already Developed
Less than 10%
6c. Content externally developed?
Yes
6d. List Developers of Externally Developed Content
ONC FHIR at Scale Taskforce (FAST)
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors
6g. Vendors
Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, Healthcare Institutions (hospitals, long term care, home care, mental health)
6i. Realm
U.S. Realm Specific
7a. Management Group(s) to Review PSS
FHIR
7b. Sponsoring WG Approval Date
Oct 13, 2020
Version
5
Modifier
Dave Hamill
Modify Date
Oct 16, 2020 18:26
1a. Project Name
FAST Exchange Metadata Using RESTful Headers
1b. Project ID
1653
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
1f. Name of standard being reaffirmed
N/A
2a. Primary/Sponsor WG
FHIR Infrastructure
2d. Project Facilitator
Patrick Murta
2j. Business Requirements Analyst
Durwin Day
2k. Conformance Facilitator
Lloyd McKenzie
2m. Implementers
Humana, Health Care Service Corporation (HCSC)
3a. Project Scope
As the the need for integration between different actors in healthcare has grown, the aspect of transactions routings across one or more intermediaries such as clearinghouses and exchanges is recognized. An example of this scenario is when a payer uses a clearinghouse intermediary as their 'gateway' for transactions. There are both technical and business operational value adds in this intermediary model. This model was born in the world of the original X12 transaction set and it is expected to continue in the evolving RESTful FHIR API integration model. There are other examples as well such as HIEs/trust frameworks.
In the model described above, the interaction originator will know the the final destination but will be abstracted from the number of intermediaries involved in the message routing. For example, if provider A needs to request information from payer B and payer B uses a payer agnostic intermediary, provider A will initiate the interaction with a known endpoint representing payer B, which in this case is an intermediary, and the intermediary will handle routing of the transaction and provide any value-add services. The intermediary, or intermediaries, will need to have origination and routing information available during the life-cycle of the transaction to ensure appropriate delivery.
A variation of the use case is one in which the requester, provider A, simply provides the request to their intermediary who then provides routing information so that the transaction can move across additional intermediaries before getting to payer B.
Of course, there are cases in which there are no intermediaries involved and the routing information is not explicitly needed, but there is no harm with it being available.
Our goal is to provide a model which supports a hybrid model of point to point interaction as well as intermediary brokered interaction without the actors in either side needing detailed knowledge of how intermediary routing works.
A reliable routing solution needs to support:
• Consistent definition and representation of routing information
• Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns
• A hybrid environment - transactions over both dynamic point to point and intermediary brokered models
The planned approach is to create an IG which uses the model described as part of Custom Headers defined within the FHIR Exchange Module (http://build.fhir.org/http.html#custom) with proposed new “X-Originator” and “X-Destination headers.
Solution advantages:
• Common pattern, used for many years in healthcare and other industries
• Lightweight
• Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available
• Universally usable, regardless of FHIR transaction – it’s resource agnostic
Supporting Reference:
This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019 and Summer 2020, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry.
Links to additional documentation:
https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/FAST+HL7+FHIR+Standard+Based+Solution+for+Intermediary-to-Intermediary+Exchange+-+Expert+Panel+Discussion
In today’s environment, FHIR integration is typically point-to-point without the need for routing information. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing.
3c. Security Risk
No
3e. Objectives/Deliverables and Target Dates
FHIR Connectathon – 2021 Jan WGM
Submit for STU Ballot – 2021 May Ballot
FHIR Connectathon – 2021 May WGM
STU Reconciliation – June 2021
Publish STU 1 – July 2021
Submit 2nd STU Ballot – May 2022 Ballot
2nd STU Reconciliation – June 2022
Publish 2nd STU – July 2022
Submit Normative Ballot – 2023 Sept Ballot
Normative Reconciliation – November 2023
Publish Normative IG – December 2023
3f. Common Names / Keywords / Aliases:
Common Name: FAST Exchange Metadata; Keywords: FAST, Exchange, Metadata, Intermediaries
3o. Earliest prior release and/or version to which the compatibility applies
N/A
4a. Products
FHIR Implementation Guide, FHIR Profiles
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
FHIR R4+
4c. FHIR Profiles Version
FHIR R4+
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Specify external organization
N/A
5b. Project Ballot Type
STU to Normative
5d. Joint Copyright
No
6a. External Project Collaboration
ONC FHIR at Scale Taskforce (FAST)
6b. Content Already Developed
Less than 10%
6c. Content externally developed?
Yes
6d. List Developers of Externally Developed Content
ONC FHIR at Scale Taskforce (FAST)
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors
6g. Vendors
Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, 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
Patrick Murta
Modify Date
Oct 12, 2020 18:46
1a. Project Name
FAST Exchange Metadata Using RESTful Headers
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
1f. Name of standard being reaffirmed
N/A
2a. Primary/Sponsor WG
FHIR Infrastructure
2d. Project Facilitator
Patrick Murta
2j. Business Requirements Analyst
Durwin Day
2k. Conformance Facilitator
Lloyd McKenzie
2m. Implementers
Humana, Health Care Service Corporation (HCSC)
3a. Project Scope
As the the need for integration between different actors in healthcare has grown, the aspect of transactions routings across one or more intermediaries such as clearinghouses and exchanges is recognized. An example of this scenario is when a payer uses a clearinghouse intermediary as their 'gateway' for transactions. There are both technical and business operational value adds in this intermediary model. This model was born in the world of the original X12 transaction set and it is expected to continue in the evolving RESTful FHIR API integration model. There are other examples as well such as HIEs/trust frameworks.
In the model described above, the interaction originator will know the the final destination but will be abstracted from the number of intermediaries involved in the message routing. For example, if provider A needs to request information from payer B and payer B uses a payer agnostic intermediary, provider A will initiate the interaction with a known endpoint representing payer B, which in this case is an intermediary, and the intermediary will handle routing of the transaction and provide any value-add services. The intermediary, or intermediaries, will need to have origination and routing information available during the life-cycle of the transaction to ensure appropriate delivery.
A variation of the use case is one in which the requester, provider A, simply provides the request to their intermediary who then provides routing information so that the transaction can move across additional intermediaries before getting to payer B.
Of course, there are cases in which there are no intermediaries involved and the routing information is not explicitly needed, but there is no harm with it being available.
Our goal is to provide a model which supports a hybrid model of point to point interaction as well as intermediary brokered interaction without the actors in either side needing detailed knowledge of how intermediary routing works.
A reliable routing solution needs to support:
• Consistent definition and representation of routing information
• Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns
• A hybrid environment - transactions over both dynamic point to point and intermediary brokered models
The planned approach is to create an IG which uses the model described as part of Custom Headers defined within the FHIR Exchange Module (http://build.fhir.org/http.html#custom) with proposed new “X-Originator” and “X-Destination headers.
Solution advantages:
• Common pattern, used for many years in healthcare and other industries
• Lightweight
• Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available
• Universally usable, regardless of FHIR transaction – it’s resource agnostic
Supporting Reference:
This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019 and Summer 2020, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry.
Links to additional documentation:
https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/FAST+HL7+FHIR+Standard+Based+Solution+for+Intermediary-to-Intermediary+Exchange+-+Expert+Panel+Discussion
In today’s environment, FHIR integration is typically point-to-point without the need for routing information. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing.
3c. Security Risk
No
3e. Objectives/Deliverables and Target Dates
FHIR Connectathon – 2021 Jan WGM
Submit for STU Ballot – 2021 May Ballot
FHIR Connectathon – 2021 May WGM
STU Reconciliation – June 2021
Publish STU 1 – July 2021
Submit 2nd STU Ballot – May 2022 Ballot
2nd STU Reconciliation – June 2022
Publish 2nd STU – July 2022
Submit Normative Ballot – 2023 Sept Ballot
Normative Reconciliation – November 2023
Publish Normative IG – December 2023
3f. Common Names / Keywords / Aliases:
Common Name: FAST Exchange Metadata; Keywords: FAST, Exchange, Metadata, Intermediaries
3o. Earliest prior release and/or version to which the compatibility applies
N/A
4a. Products
FHIR Implementation Guide, FHIR Profiles
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
FHIR R4+
4c. FHIR Profiles Version
FHIR R4+
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Specify external organization
N/A
5b. Project Ballot Type
STU to Normative
5d. Joint Copyright
No
6a. External Project Collaboration
ONC FHIR at Scale Taskforce (FAST)
6b. Content Already Developed
Less than 10%
6c. Content externally developed?
Yes
6d. List Developers of Externally Developed Content
ONC FHIR at Scale Taskforce (FAST)
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors
6g. Vendors
Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, 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
Dana Marcelonis
Modify Date
Oct 08, 2020 13:31
1a. Project Name
FAST Exchange Metadata Using RESTful Headers
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
1f. Name of standard being reaffirmed
N/A
2a. Primary/Sponsor WG
FHIR Infrastructure
2d. Project Facilitator
Patrick Murta
2j. Business Requirements Analyst
Durwin Day
2k. Conformance Facilitator
Lloyd McKenzie
2m. Implementers
Humana, Health Care Service Corporation (HCSC)
3a. Project Scope
As the the need for integration between different actors in healthcare has grown, the aspect of transactions routings across one or more intermediaries such as clearinghouses and exchanges is recognized. An example of this scenario is when a payer uses a clearinghouse intermediary as their 'gateway' for transactions. There are both technical and business operational value adds in this intermediary model. This model was born in the world of the original X12 transaction set and it is expected to continue in the evolving RESTful FHIR API integration model. There are other examples as well such as HIEs/trust frameworks.
In the model described above, the interaction originator will know the the final destination but will be abstracted from the number of intermediaries involved in the message routing. For example, if provider A needs to request information from payer B and payer B uses a payer agnostic intermediary, provider A will initiate the interaction with a known endpoint representing payer B, which in this case is an intermediary, and the intermediary will handle routing of the transaction and provide any value-add services. The intermediary, or intermediaries, will need to have origination and routing information available during the life-cycle of the transaction to ensure appropriate delivery.
Of course, there are cases in which there are no intermediaries involved and the routing information is not explicitly needed, but there is no harm with it being available.
Our goal is to provide a model which supports a hybrid model of point to point interaction as well as intermediary brokered interaction without the actors in either side needing detailed knowledge of how intermediary routing works.
A reliable routing solution needs to support:
• Consistent definition and representation of routing information
• Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns
• A hybrid environment - transactions over both dynamic point to point and intermediary brokered models
The planned approach is to create an IG which uses the model described as part of Custom Headers defined within the FHIR Exchange Module (http://build.fhir.org/http.html#custom) with proposed new “X-Originator” and “X-Destination headers.
Solution advantages:
• Common pattern, used for many years in healthcare and other industries
• Lightweight
• Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available
• Universally usable, regardless of FHIR transaction – it’s resource agnostic
Supporting Reference:
This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019 and Summer 2020, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry.
Links to additional documentation:
https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/FAST+HL7+FHIR+Standard+Based+Solution+for+Intermediary-to-Intermediary+Exchange+-+Expert+Panel+Discussion
In today’s environment, FHIR integration is typically point-to-point without the need for routing information. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing.
3c. Security Risk
No
3e. Objectives/Deliverables and Target Dates
FHIR Connectathon – 2021 Jan WGM
Submit for STU Ballot – 2021 May Ballot
FHIR Connectathon – 2021 May WGM
STU Reconciliation – June 2021
Publish STU 1 – July 2021
Submit 2nd STU Ballot – May 2022 Ballot
2nd STU Reconciliation – June 2022
Publish 2nd STU – July 2022
Submit Normative Ballot – 2023 Sept Ballot
Normative Reconciliation – November 2023
Publish Normative IG – December 2023
3f. Common Names / Keywords / Aliases:
Common Name: FAST Exchange Metadata; Keywords: FAST, Exchange, Metadata, Intermediaries
3o. Earliest prior release and/or version to which the compatibility applies
N/A
4a. Products
FHIR Implementation Guide, FHIR Profiles
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
FHIR R4+
4c. FHIR Profiles Version
FHIR R4+
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Specify external organization
N/A
5b. Project Ballot Type
STU to Normative
5d. Joint Copyright
No
6a. External Project Collaboration
ONC FHIR at Scale Taskforce (FAST)
6b. Content Already Developed
Less than 10%
6c. Content externally developed?
Yes
6d. List Developers of Externally Developed Content
ONC FHIR at Scale Taskforce (FAST)
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors
6g. Vendors
Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, 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
Dana Marcelonis
Modify Date
Oct 02, 2020 13:52
1a. Project Name
FAST Exchange Metadata Using RESTful Headers
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
1f. Name of standard being reaffirmed
N/A
2a. Primary/Sponsor WG
FHIR Infrastructure
2d. Project Facilitator
Patrick Murta
2j. Business Requirements Analyst
Durwin Day
2k. Conformance Facilitator
Lloyd McKenzie
2m. Implementers
Humana, Health Care Service Corporation (HCSC)
3a. Project Scope
The ONC FHIR at Scale Taskforce (FAST) has identified a number of ecosystem issues and technical barriers that, if mitigated, can facilitate deployment of FHIR solutions “at scale”. The FAST Exchange Metadata Using RESTful Headers project will address one of those barriers, related to transaction exchange within a hybrid environment where both intermediary (such as clearinghouses and HIEs) and non-intermediary models are being employed. The solution aims to address how stakeholders consistently and reliably exchange data across a hybrid system with the standardization of metadata exchange.
A reliable routing solution needs to support:
• Consistent definition and representation of metadata – routing participants will expect consistent header field use and value population in order to reliably route information
• Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns
• A hybrid environment - transactions over both dynamic point to point and intermediary brokered models
In order to meet these needs, this project aims to:
1. Identify use cases in scope to support reliable exchange between intermediaries
2. Further vet the proposed solution approach with stakeholders
3. Define requirements for using RESTful headers in the use case scenarios
4. Develop, test, and ballot a FHIR Implementation Guide to send metadata/routing identifiers using RESTful header parameters
The recommended solution approach is to use the Custom Headers defined within the FHIR Exchange Module (http://build.fhir.org/http.html#custom) in conjunction with the proposed “X-Originator” and “X-Destination” headers.
Solution advantages:
• Common pattern, used for many years in healthcare and other industries
• Lightweight
• Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available
• Universally usable, regardless of FHIR transaction – it’s resource agnostic
This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry.
Attachments
3b. Project Need
Accelerated adoption of FHIR for the production exchange of clinical information between stakeholders will lead to predictable scalability challenges. The ONC FHIR at Scale Taskforce (FAST) has identified a number of ecosystem issues and technical barriers that, if mitigated, can facilitate deployment of FHIR solutions “at scale”.
In today’s environment, FHIR integration is typically point-to-point without the need for routing metadata. In addition, given the point-to-point model, it is typically obvious who the requester and responder are without the need for multi-hop routing data. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing and standardize metadata exchange.
3c. Security Risk
No
3e. Objectives/Deliverables and Target Dates
FHIR Connectathon – 2021 Jan WGM
Submit for STU Ballot – 2021 May Ballot
FHIR Connectathon – 2021 May WGM
STU Reconciliation – June 2021
Publish STU 1 – July 2021
Submit 2nd STU Ballot – May 2022 Ballot
2nd STU Reconciliation – June 2022
Publish 2nd STU – July 2022
Submit Normative Ballot – 2023 Sept Ballot
Normative Reconciliation – November 2023
Publish Normative IG – December 2023
3f. Common Names / Keywords / Aliases:
Common Name: FAST Exchange Metadata; Keywords: FAST, Exchange, Metadata, Intermediaries
3o. Earliest prior release and/or version to which the compatibility applies
N/A
4a. Products
FHIR Implementation Guide, FHIR Profiles
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
FHIR R4+
4c. FHIR Profiles Version
FHIR R4+
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Specify external organization
N/A
5b. Project Ballot Type
STU to Normative
5d. Joint Copyright
No
6a. External Project Collaboration
ONC FHIR at Scale Taskforce (FAST)
6b. Content Already Developed
Less than 10%
6c. Content externally developed?
Yes
6d. List Developers of Externally Developed Content
ONC FHIR at Scale Taskforce (FAST)
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors
6g. Vendors
Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, 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
Dana Marcelonis
Modify Date
Oct 02, 2020 13:40
1a. Project Name
FAST Exchange Metadata Using RESTful Headers
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
1f. Name of standard being reaffirmed
N/A
2a. Primary/Sponsor WG
FHIR Infrastructure
2d. Project Facilitator
Patrick Murta
2j. Business Requirements Analyst
Durwin Day
2k. Conformance Facilitator
Lloyd McKenzie
2m. Implementers
Humana, Health Care Service Corporation (HCSC)
3a. Project Scope
The ONC FHIR at Scale Taskforce (FAST) has identified a number of ecosystem issues and technical barriers that, if mitigated, can facilitate deployment of FHIR solutions “at scale”. The FAST Exchange Metadata Using RESTful Headers project will address one of those barriers, related to transaction exchange within a hybrid environment where both intermediary (such as clearinghouses and HIEs) and non-intermediary models are being employed. The solution aims to address how stakeholders consistently and reliably exchange data across a hybrid system with the standardization of metadata exchange.
A reliable routing solution needs to support:
• Consistent definition and representation of metadata – routing participants will expect consistent header field use and value population in order to reliably route information
• Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns
• A hybrid environment - transactions over both dynamic point to point and intermediary brokered models
In order to meet these needs, this project aims to:
1. Identify use cases in scope to support reliable exchange between intermediaries
2. Further vet the proposed solution approach with stakeholders
3. Define requirements for using RESTful headers in the use case scenarios
4. Develop, test, and ballot a FHIR Implementation Guide to send metadata/routing identifiers using RESTful header parameters
The recommended solution approach is to use the Custom Headers defined within the FHIR Exchange Module (http://build.fhir.org/http.html#custom) in conjunction with the proposed “X-Originator” and “X-Destination” headers.
Solution advantages:
• Common pattern, used for many years in healthcare and other industries
• Lightweight
• Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available
• Universally usable, regardless of FHIR transaction – it’s resource agnostic
This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry.
Attachments
3b. Project Need
Accelerated adoption of FHIR for the production exchange of clinical information between stakeholders will lead to predictable scalability challenges. The ONC FHIR at Scale Taskforce (FAST) has identified a number of ecosystem issues and technical barriers that, if mitigated, can facilitate deployment of FHIR solutions “at scale”.
In today’s environment, FHIR integration is typically point-to-point without the need for routing metadata. In addition, given the point-to-point model, it is typically obvious who the requester and responder are without the need for multi-hop routing data. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing and standardize metadata exchange.
3c. Security Risk
No
3e. Objectives/Deliverables and Target Dates
FHIR Connectathon – 2021 Jan WGM
Submit for STU Ballot – 2021 May Ballot
FHIR Connectathon – 2021 May WGM
STU Reconciliation – June 2021
Publish STU 1 – July 2021
Submit 2nd STU Ballot – May 2022 Ballot
2nd STU Reconciliation – June 2022
Publish 2nd STU – July 2022
Submit Normative Ballot – 2023 Sept Ballot
Normative Reconciliation – November 2023
Publish Normative IG – December 2023
3f. Common Names / Keywords / Aliases:
Common Name: FAST Exchange Metadata; Keywords: FAST, Exchange, Metadata, Intermediaries
3o. Earliest prior release and/or version to which the compatibility applies
N/A
4a. Products
FHIR Implementation Guide, FHIR Profiles
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
FHIR R4+
4c. FHIR Profiles Version
FHIR R4+
5a. Project Intent
Implementation Guide (IG) will be created/modified
5a. Is the project adopting/endorsing an externally developed IG?
No
5a. Specify external organization
N/A
5b. Project Ballot Type
STU to Normative
5d. Joint Copyright
No
6a. External Project Collaboration
ONC FHIR at Scale Taskforce (FAST)
6b. Content Already Developed
Less than 10%
6c. Content externally developed?
Yes
6d. List Developers of Externally Developed Content
ONC FHIR at Scale Taskforce (FAST)
6e. Is this a hosted (externally funded) project?
Yes
6f. Stakeholders
Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors
6g. Vendors
Pharmaceutical, EHR, PHR, Equipment, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, Healthcare Institutions (hospitals, long term care, home care, mental health)
Per the determination made in the March 29 discussion referenced in Melva Peters 's note above, and conversation today with Melva, Lloyd McKenzie and Josh Mandel from FHIR-I, I corrected 6c. Content externally developed? above to "No"
3 Comments
Anne Wizauer
Dana Marcelonis Patrick Murta TSC approved 2021-01-11
Melva Peters
2021-03-29: TSC External Review complete - no external review is required as content is being developed within FHIR-i
FAST Exchange Metadata Using RESTful Headers
Frank McKinney
Per the determination made in the March 29 discussion referenced in Melva Peters 's note above, and conversation today with Melva, Lloyd McKenzie and Josh Mandel from FHIR-I, I corrected 6c. Content externally developed? above to "No"
Copying Patrick Murta , Dana Marcelonis