Skip to end of metadata
Go to start of metadata




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

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

https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Exchange_Process_v2_062620.docx?version=1&modificationDate=1593187080074&api=v2

Attachments

3b. Project Need

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

3g. Lineage

N/A

3h. Project Dependencies

N/A

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/FHIRI/FAST+Exchange+Metadata+Using+RESTful+Headers

3j. Backwards Compatibility

No

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?

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

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

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Oct 13, 2020

7c. Co-Sponsor Approval Date

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

7g. V2 MG Approval Date

7h. Architecture Review Board Approval Date

7i. Steering Division Approval Date

7j. TSC Approval Date



 Show Changes

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

https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Exchange_Process_v2_062620.docx?version=1&modificationDate=1593187080074&api=v2

Attachments

3b. Project Need

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

3g. Lineage

N/A

3h. Project Dependencies

N/A

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/FHIRI/FAST+Exchange+Metadata+Using+RESTful+Headers

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

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

Not applicable

3m. External Vocabularies

No

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

https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Exchange_Process_v2_062620.docx?version=1&modificationDate=1593187080074&api=v2

Attachments

3b. Project Need

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

3g. Lineage

N/A

3h. Project Dependencies

N/A

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/FHIRI/FAST+Exchange+Metadata+Using+RESTful+Headers

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

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

Not applicable

3m. External Vocabularies

No

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

https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Exchange_Process_v2_062620.docx?version=1&modificationDate=1593187080074&api=v2

Attachments

3b. Project Need

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

3g. Lineage

N/A

3h. Project Dependencies

N/A

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/FHIRI/FAST+Exchange+Metadata+Using+RESTful+Headers

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

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

Not applicable

3m. External Vocabularies

No

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

https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Exchange_Process_v2_062620.docx?version=1&modificationDate=1593187080074&api=v2

Attachments

3b. Project Need

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

3g. Lineage

N/A

3h. Project Dependencies

N/A

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/FHIRI/FAST+Exchange+Metadata+Using+RESTful+Headers

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

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

Not applicable

3m. External Vocabularies

No

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

3g. Lineage

N/A

3h. Project Dependencies

N/A

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/FHIRI/FAST+Exchange+Metadata+Using+RESTful+Headers

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

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

Not applicable

3m. External Vocabularies

No

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

3g. Lineage

N/A

3h. Project Dependencies

N/A

3i. HL7-Managed Project Document Repository URL:

TBD

3j. Backwards Compatibility

No

3l. Using Current V3 Data Types?

No

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

Not applicable

3m. External Vocabularies

No

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