Difference between revisions of "201809 Public Health"
| (15 intermediate revisions by 2 users not shown) | |||
| Line 16: | Line 16: | ||
Public health registry reporting shares numerous design elements with electronic case reporting. Some of these elements include the distribution of triggering / reporting rules from public health, appropriate triggering in EHRs, the application of more complex inclusion/exclusion and reporting logic, unsolicited push messaging, supplemental data acquisition, and provider information provisioning. Cancer reporting and others are exploring approaches to implementation that support needed program outcomes from clinical workflow and data and leverage commonalities with other reporting. The CDC Cancer program plans to work on a FHIR physician reporting specification and triggering issues in this Connectathon. | Public health registry reporting shares numerous design elements with electronic case reporting. Some of these elements include the distribution of triggering / reporting rules from public health, appropriate triggering in EHRs, the application of more complex inclusion/exclusion and reporting logic, unsolicited push messaging, supplemental data acquisition, and provider information provisioning. Cancer reporting and others are exploring approaches to implementation that support needed program outcomes from clinical workflow and data and leverage commonalities with other reporting. The CDC Cancer program plans to work on a FHIR physician reporting specification and triggering issues in this Connectathon. | ||
| − | Bidirectional Services eReferrals (BSeRs) are closed-loop exchanges between EHRs in clinical care and mostly extra-clinical social services and lifestyle change programs. There is a FHIR BSeR September ballot with transactions to support the transmission of a referral and response and update communications from the program back to the referring provider. Numerous Centers for Disease Control and Prevention and other agency programs seek to facilitate cessation and prevention programs to increase health and decrease healthcare costs. Unlike referrals between clinicians, specific data segmentation is appropriate to provide these programs relevant data they need without revealing unrelated patient information. The FHIR Bidirectional Services eReferral specification can be found here: http://hl7.org/fhir/us/bser/2018Sep/. | + | Bidirectional Services eReferrals (BSeRs) are closed-loop exchanges between EHRs in clinical care and mostly extra-clinical social services and lifestyle change programs. There is a FHIR BSeR September ballot with transactions to support the transmission of a referral and response and update communications from the program back to the referring provider. Numerous Centers for Disease Control and Prevention and other agency programs seek to facilitate cessation and prevention programs to increase health and decrease healthcare costs. Unlike referrals between clinicians, specific data segmentation is appropriate to provide these programs relevant data they need without revealing unrelated patient information. The FHIR Bidirectional Services eReferral specification can be found here: |
| + | * http://hl7.org/fhir/us/bser/2018Sep/. | ||
==Proposed Track Lead== | ==Proposed Track Lead== | ||
| Line 60: | Line 61: | ||
==Scenarios (Reporting)== | ==Scenarios (Reporting)== | ||
<!-- What will be the actions performed by participants? --> | <!-- What will be the actions performed by participants? --> | ||
| + | The Reporting scenarios will use the AIMS Platform's experimental FHIR Server. To access it: | ||
| + | * Go to https://fhir.experimental.aimsplatform.com | ||
| + | * Select "API Key" in top-right | ||
| + | * Click "Login" | ||
| + | * Register/login. It will re-direct you back to the HAPI/FHIR server when done. Required fields are first, last, email, username, and password. | ||
| + | * Select "API Key" in the top-right, again | ||
| + | * It will show you your token, so that you can use it in FHIR REST API requests | ||
| − | ===Update Trigger Codes | + | For example: GET https://fhir.experimental.aimsplatform.com/baseDstu3/Bundle/1 with an "Authorization" header of "Bearer <your_token>" |
| + | |||
| + | The token stays active for 24 hours, and then it expires, and you have to re-login to get a new token | ||
| + | |||
| + | ===Update Knowledge Distribution / Trigger Codes on Public Health FHIR Server=== | ||
In this scenario and elsewhere we refer to “trigger codes / reporting logic” which is used to refer to distributable knowledge resources that will be used by clinical care / EHRs to support triggering and reporting. Coordinated through a PlanDefinition, they include value set bundles and other reporting metadata and eventually CQL and other knowledge resources. For some time, the value set bundles may be the only machine processable XML and JSON content, but the additional information provides human processable context and a standards-based wrapper to coordinate these elements. | In this scenario and elsewhere we refer to “trigger codes / reporting logic” which is used to refer to distributable knowledge resources that will be used by clinical care / EHRs to support triggering and reporting. Coordinated through a PlanDefinition, they include value set bundles and other reporting metadata and eventually CQL and other knowledge resources. For some time, the value set bundles may be the only machine processable XML and JSON content, but the additional information provides human processable context and a standards-based wrapper to coordinate these elements. | ||
:Action: Public Health determines that the current trigger code value sets / reporting logic require an update. The appropriate value sets are updated using PUT. Also update trigger codes as a Bundle of ValueSet resources referenced by the PlanDefinition so they can be updated as a set and linked to other reporting criteria. | :Action: Public Health determines that the current trigger code value sets / reporting logic require an update. The appropriate value sets are updated using PUT. Also update trigger codes as a Bundle of ValueSet resources referenced by the PlanDefinition so they can be updated as a set and linked to other reporting criteria. | ||
| Line 67: | Line 79: | ||
:Success Criteria: Value sets are successfully updated and can be retrieved on demand with GET | :Success Criteria: Value sets are successfully updated and can be retrieved on demand with GET | ||
| − | ===Subscribe to Trigger | + | ===Subscribe to Knowledge Distribution / Trigger Codes Updates=== |
:Action: Provider organization uses Subscription to subscribe to changes to the PlanDefinition and trigger code value sets / reporting logic using any legal notification method. | :Action: Provider organization uses Subscription to subscribe to changes to the PlanDefinition and trigger code value sets / reporting logic using any legal notification method. | ||
:Precondition: Original PlanDefinition and trigger code value sets / reporting logic exist on test server | :Precondition: Original PlanDefinition and trigger code value sets / reporting logic exist on test server | ||
:Success Criteria: Provider organization is notified and receives a copy of any PlanDefinition and trigger code value sets / reporting logic specifications that are updated | :Success Criteria: Provider organization is notified and receives a copy of any PlanDefinition and trigger code value sets / reporting logic specifications that are updated | ||
| − | ===Ingest Trigger Codes | + | ===Ingest Knowledge Distribution / Trigger Codes into EHR=== |
:Action: Provider organization receives a PlanDefinition trigger code / reporting logic update, and ingests them into their EHR to support case report initiation. | :Action: Provider organization receives a PlanDefinition trigger code / reporting logic update, and ingests them into their EHR to support case report initiation. | ||
:Precondition: PlanDefinition trigger codes / reporting logic updates have been received by provider organization | :Precondition: PlanDefinition trigger codes / reporting logic updates have been received by provider organization | ||
| Line 80: | Line 92: | ||
:Action: Document Creator prepares an eICR (or other registry submission) and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with public health and other extra-clinical organizations. Some may test FHIR messaging for transmissions. | :Action: Document Creator prepares an eICR (or other registry submission) and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with public health and other extra-clinical organizations. Some may test FHIR messaging for transmissions. | ||
:Precondition: Patient and Encounter resources exist, and sufficient clinical information (Condition, Observation, and other resources) to populate an eICR. | :Precondition: Patient and Encounter resources exist, and sufficient clinical information (Condition, Observation, and other resources) to populate an eICR. | ||
| − | :Success Criteria: eICR is successfully posted to a FHIR server and validates against the eCR profiles found here: http://hl7.org/fhir/us/ecr/2018Sep/profiles.html#electronic-initial-case-report-eicr-transaction-and-profiles | + | :Success Criteria: eICR is successfully posted to a FHIR server and validates against the eCR profiles found here: |
| + | * http://hl7.org/fhir/us/ecr/2018Sep/profiles.html#electronic-initial-case-report-eicr-transaction-and-profiles | ||
===Receive eICR Document=== | ===Receive eICR Document=== | ||
:Action: eICR Document Creator prepares an initial case report and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with public health. eICRs will be queued. The eICR Document Consumer does a GET on each successive eICR and processes it. | :Action: eICR Document Creator prepares an initial case report and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with public health. eICRs will be queued. The eICR Document Consumer does a GET on each successive eICR and processes it. | ||
:Precondition: eICR exists on a FHIR server. | :Precondition: eICR exists on a FHIR server. | ||
| − | :Success Criteria: eICR is successfully retrieved from a FHIR server and validates against the eCR profiles found here: http://hl7.org/fhir/us/ecr/2018Sep/profiles.html#electronic-initial-case-report-eicr-transaction-and-profiles | + | :Success Criteria: eICR is successfully retrieved from a FHIR server and validates against the eCR profiles found here: |
| + | * http://hl7.org/fhir/us/ecr/2018Sep/profiles.html#electronic-initial-case-report-eicr-transaction-and-profiles | ||
===Create Reportability Response (RR)=== | ===Create Reportability Response (RR)=== | ||
:Action: RR Document Creator prepares a reportability response and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care. | :Action: RR Document Creator prepares a reportability response and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care. | ||
:Precondition: eICR on which the RR is based exists and contains sufficient information to create an RR. | :Precondition: eICR on which the RR is based exists and contains sufficient information to create an RR. | ||
| − | :Success Criteria: RR is successfully posted to a FHIR server and validates against the eCR profiles found here: http://hl7.org/fhir/us/ecr/2018Sep/profiles.html#reportability-response-rr-transaction-and-profiles | + | :Success Criteria: RR is successfully posted to a FHIR server and validates against the eCR profiles found here: |
| + | * http://hl7.org/fhir/us/ecr/2018Sep/profiles.html#reportability-response-rr-transaction-and-profiles | ||
===Receive Reportability Response=== | ===Receive Reportability Response=== | ||
:Action: RR Document Creator prepares reportability response and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care. RRs will be queued. The RR Document Consumer does a GET on each successive RR and processes it. | :Action: RR Document Creator prepares reportability response and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care. RRs will be queued. The RR Document Consumer does a GET on each successive RR and processes it. | ||
:Precondition: RR exists on a FHIR server. | :Precondition: RR exists on a FHIR server. | ||
| − | :Success Criteria: RR is successfully retrieved from a FHIR server and validates against the eCR profiles found here: http://hl7.org/fhir/us/ecr/2018Sep/profiles.html#reportability-response-rr-transaction-and-profiles | + | :Success Criteria: RR is successfully retrieved from a FHIR server and validates against the eCR profiles found here: |
| + | * http://hl7.org/fhir/us/ecr/2018Sep/profiles.html#reportability-response-rr-transaction-and-profiles | ||
==Scenarios (Referrals)== | ==Scenarios (Referrals)== | ||
| Line 101: | Line 117: | ||
:Action: EHR prepares and POSTs an electronic referral. This POST may be one of several different transport methodologies supported for exchange with clinical care. The referral receiver does a GET on each successive referral and processes it. | :Action: EHR prepares and POSTs an electronic referral. This POST may be one of several different transport methodologies supported for exchange with clinical care. The referral receiver does a GET on each successive referral and processes it. | ||
:Precondition: Referral exists on a FHIR server. | :Precondition: Referral exists on a FHIR server. | ||
| − | :Success Criteria: Referral is successfully retrieved from a FHIR server and validates against the profiles found here: http://hl7.org/fhir/us/bser/2018Sep/ReferralRequestTransactionProfiles.html | + | :Success Criteria: Referral is successfully retrieved from a FHIR server and validates against the profiles found here: |
| + | * http://hl7.org/fhir/us/bser/2018Sep/ReferralRequestTransactionProfiles.html | ||
===Receive Referral=== | ===Receive Referral=== | ||
:Action: Referral creator prepares referral and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care. Referrals may be queued. The referral consumer does a GET on each successive referral and processes it. | :Action: Referral creator prepares referral and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care. Referrals may be queued. The referral consumer does a GET on each successive referral and processes it. | ||
:Precondition: Referral exists on a FHIR server. | :Precondition: Referral exists on a FHIR server. | ||
| − | :Success Criteria: Referral is successfully retrieved from a FHIR server and validates against the profiles found here: http://hl7.org/fhir/us/bser/2018Sep/ReferralRequestTransactionProfiles.html | + | :Success Criteria: Referral is successfully retrieved from a FHIR server and validates against the profiles found here: |
| + | * http://hl7.org/fhir/us/bser/2018Sep/ReferralRequestTransactionProfiles.html | ||
===Create and Send Report Back=== | ===Create and Send Report Back=== | ||
:Action: A referral report is created and POSTed it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange. | :Action: A referral report is created and POSTed it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange. | ||
:Precondition: Referral report information exists sufficient to populate a referral report. | :Precondition: Referral report information exists sufficient to populate a referral report. | ||
| − | :Success Criteria: Referral report is successfully posted to a FHIR server and validates against the profiles found here: http://hl7.org/fhir/us/bser/2018Sep/ReferralFeedbackTransactionProfiles.html | + | :Success Criteria: Referral report is successfully posted to a FHIR server and validates against the profiles found here: |
| + | * http://hl7.org/fhir/us/bser/2018Sep/ReferralFeedbackTransactionProfiles.html | ||
===Receive Report and Attach to Patient Chart=== | ===Receive Report and Attach to Patient Chart=== | ||
:Action: Referral report creator prepares a referral report and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care. The referral consumer does a GET on each referral report and processes it. | :Action: Referral report creator prepares a referral report and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care. The referral consumer does a GET on each referral report and processes it. | ||
:Precondition: Referral report exists on a FHIR server. | :Precondition: Referral report exists on a FHIR server. | ||
| − | :Success Criteria: Referral report is successfully retrieved from a FHIR server and validates against the profiles found here: http://hl7.org/fhir/us/bser/2018Sep/ReferralFeedbackTransactionProfiles.html | + | :Success Criteria: Referral report is successfully retrieved from a FHIR server and validates against the profiles found here: |
| + | * http://hl7.org/fhir/us/bser/2018Sep/ReferralFeedbackTransactionProfiles.html | ||
| + | |||
| + | ==Scenarios (Cancer)== | ||
| + | |||
| + | ===Create a Cancer Registry Profile and Extensions (Cancer Specific)=== | ||
| + | In this scenario, the reporting to the Cancer Registry requires inclusion of Treatment Plans, Planned Medication Activity, Radiation treatment and results, Family History, Vital Signs, and Cancer Diagnosis elements. This activity involves assessing gaps between existing FHIR resources and necessary Cancer Reporting elements, in order to define a FHIR Profile and Extensions that meets the requirements of Cancer Reporting. | ||
| + | |||
| + | Action: Public Health creates a Cancer Registry Profile and Extensions that captures information needed to support a FHIR Document for Cancer Registry report. | ||
| + | |||
| + | Precondition: Patient, Encounter, and Diagnostic Reporting resources exist on EHR FHIR Server, and sufficient clinical information (Patient, Encounter, Diagnostic Report, Condition, Observation, and other resources) to populate an Ambulatory Cancer report is available on EHR FHIR Server. | ||
| + | |||
| + | Success Criteria: FHIR Profile and Extensions for Cancer Reporting are created and include elements to support cancer reporting | ||
| + | |||
| + | === Update Trigger Codes / Reporting Logic on Public Health FHIR Server (Cancer) === | ||
| + | In this scenario and elsewhere we refer to “cancer trigger codes” which is used to refer to distributable knowledge resources that will be used by clinical care / EHRs to support triggering and initiating a FHIR Document to support reporting to Cancer Registries. | ||
| + | Action: Public Health determines that the current “cancer trigger codes / reporting logic” trigger code value sets / reporting logic require an update. The appropriate value sets are updated in the Public health FHIR Server. Also, a Bundle of Cancer Value Set resources, referenced by the PlanDefinition, will be updated. | ||
| + | Precondition: Original trigger code value sets / reporting logic exists on Public Health FHIR server. | ||
| + | Success Criteria: Value sets are successfully updated and can be retrieved on demand with GET. | ||
| + | |||
| + | === Subscribe to Cancer Trigger Code Updates === | ||
| + | Action: Provider organization uses Subscription to subscribe to changes to the PlanDefinition and trigger code value sets using any legal notification method. | ||
| + | Precondition: Original PlanDefinition and trigger code value sets exist on test server | ||
| + | Success Criteria: Provider organization is notified and receives a copy of any PlanDefinition and trigger code value sets / reporting logic specifications that are updated. Provider ingests Cancer Trigger Codes into EHR | ||
| + | Action: Provider organization receives a PlanDefinition Cancer trigger code update, and ingests them into their EHR to support Cancer Registry report initiation. | ||
| + | Precondition: PlanDefinition Cancer trigger codes updates have been received by provider organization | ||
| + | Success Criteria: Updates successfully ingested into EHR | ||
| + | |||
| + | === Create and Send Cancer FHIR Registry Report Document (Cancer Specific) === | ||
| + | Action: EHR prepares a FHIR Document based on the FHIR Profile for Cancer Reporting and Posts it to the Public Health FHIR Server. This POST may be one of several different transport methodologies supported for exchange with clinical care. | ||
| + | Precondition: Cancer Report trigger has fired, and FHIR Profile for Cancer Reporting exists on a FHIR server. | ||
| + | Success Criteria: FHIR Document for Cancer Report is posted and can be retrieved from Public Health FHIR server and validates against the cancer profiles found here: (Zulip Public Health track) | ||
==TestScript(s)== | ==TestScript(s)== | ||
Latest revision as of 15:01, 29 September 2018
DRAFT Public Health (Case Reporting, Registries, and Referrals)
Draft for Fall 2018 FHIR Connectathon proposal review
Submitting WG/Project/Implementer Group
Public Health (PH)
Justification
Public health includes a number of use cases involving the exchange of information between Electronic Health Records in clinical care and governmental Public Health Agencies (PHAs) or other extra-clinical organizations. The use cases can differ, but frequently share a number of common design elements as well. This track will build on the previous public health electronic case reporting (eCR) track to provide a home and critical mass for these use cases as they develop and grow.
Electronic case reporting (eCR) has existing CDA product family standards, had a FHIR "for comment" ballot in January of 2018, and now has a September FHIR STU ballot. This use case will focus on the FHIR subscription dissemination of public health reporting trigger codes in a PlanDefinition construct and also establish a path for distribution of reporting criteria and more complex business logic. It will also involve the triggering and creation of the electronic Initial Case Report (eICR) in EHRs, the messaging and exchange of the eICR, and the creation and transmission of Reportability Response information back to providers of care and clinical care reporters as appropriate. The FHIR electronic Case Reporting implementation guide currently in ballot can be found here:
Public health registry reporting shares numerous design elements with electronic case reporting. Some of these elements include the distribution of triggering / reporting rules from public health, appropriate triggering in EHRs, the application of more complex inclusion/exclusion and reporting logic, unsolicited push messaging, supplemental data acquisition, and provider information provisioning. Cancer reporting and others are exploring approaches to implementation that support needed program outcomes from clinical workflow and data and leverage commonalities with other reporting. The CDC Cancer program plans to work on a FHIR physician reporting specification and triggering issues in this Connectathon.
Bidirectional Services eReferrals (BSeRs) are closed-loop exchanges between EHRs in clinical care and mostly extra-clinical social services and lifestyle change programs. There is a FHIR BSeR September ballot with transactions to support the transmission of a referral and response and update communications from the program back to the referring provider. Numerous Centers for Disease Control and Prevention and other agency programs seek to facilitate cessation and prevention programs to increase health and decrease healthcare costs. Unlike referrals between clinicians, specific data segmentation is appropriate to provide these programs relevant data they need without revealing unrelated patient information. The FHIR Bidirectional Services eReferral specification can be found here:
Proposed Track Lead
- Rick Geimer
- John Loonsk
- Arun Srinivasan
See Connectathon_Track_Lead_Responsibilities
Expected participants
- Association of Public Health Laboratories
- AthenaHealth
- Centers for Disease Control and Prevention
- Cerner Corporation
- CGI Federal
- Lantana Consulting Group
- Northrup Grumman
- YMCAs of America
Roles
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
Public Health
Responsible for managing and disseminating trigger codes, decision logic, and knowledge resources. It fosters disease control and prevention programs and activities.
Public Health Agencies
Agencies that receive and manage electronic Initial Case Reports (eICRs), and at times send and/or receive Reportability Responses. Some Public Health Agencies support lifestyle and social services programs.
Intermediaries
Organizations in the information flow between a health care organization and a public health agency or extra-clinical program. Examples include Health Information Exchanges, the shared platform supported by APHL and CSTE that performs routing, RCKMS decision support and, at times, creates Reportability Responses, etc.
Health Care Organization
An organization that submits electronic Initial Case Reports (eICRs) based on trigger code matches, and receives trigger code updates and Reportability Responses. Health Care Organizations also report to public health registries and initiate referrals to extra-clinical social services programs. The health care organization can be supported by an EHR vendor in these roles.
Social Services and Lifestyle Change Programs
Organizations that provide classes, planning, counseling, and/or expertise in the control and prevention of chronic and acute diseases, tobacco cessation, diabetes prevention and others.
EHR Document / Report Creator
Organization responsible for creating an electronic initial case report (eICR) or another report and sending it to a EHR Document Report Receiver. Examples: EHR vendors and specialty reporting companies.
EHR Document / Report Receiver
Organization responsible for receiving and processing an electronic initial case report (eICR) and registry submissions. Examples: APHL, public health registry, or a public health agency (PHA). The eICR Document Participant may also play the role of a Reportability Response Document Creator.
Reportability Response Creator
Organization responsible for creating a Reportability Response (RR) and sending it to a Reportability Response Document Consumer. Examples: APHL or a public health agency (PHA). The Reportability Response Document Creator may also play the role of an eICR Document Participant.
Reportability Response Consumer
Organization responsible for receiving and processing a Reportability Response (RR). Examples: EHR vendors and specialty reporting companies). The Reportability Response Document Consumer may also play the role of an eICR Document Creator.
Scenarios (Reporting)
The Reporting scenarios will use the AIMS Platform's experimental FHIR Server. To access it:
- Go to https://fhir.experimental.aimsplatform.com
- Select "API Key" in top-right
- Click "Login"
- Register/login. It will re-direct you back to the HAPI/FHIR server when done. Required fields are first, last, email, username, and password.
- Select "API Key" in the top-right, again
- It will show you your token, so that you can use it in FHIR REST API requests
For example: GET https://fhir.experimental.aimsplatform.com/baseDstu3/Bundle/1 with an "Authorization" header of "Bearer <your_token>"
The token stays active for 24 hours, and then it expires, and you have to re-login to get a new token
Update Knowledge Distribution / Trigger Codes on Public Health FHIR Server
In this scenario and elsewhere we refer to “trigger codes / reporting logic” which is used to refer to distributable knowledge resources that will be used by clinical care / EHRs to support triggering and reporting. Coordinated through a PlanDefinition, they include value set bundles and other reporting metadata and eventually CQL and other knowledge resources. For some time, the value set bundles may be the only machine processable XML and JSON content, but the additional information provides human processable context and a standards-based wrapper to coordinate these elements.
- Action: Public Health determines that the current trigger code value sets / reporting logic require an update. The appropriate value sets are updated using PUT. Also update trigger codes as a Bundle of ValueSet resources referenced by the PlanDefinition so they can be updated as a set and linked to other reporting criteria.
- Precondition: Original trigger code value sets / reporting logic exists on test server
- Success Criteria: Value sets are successfully updated and can be retrieved on demand with GET
Subscribe to Knowledge Distribution / Trigger Codes Updates
- Action: Provider organization uses Subscription to subscribe to changes to the PlanDefinition and trigger code value sets / reporting logic using any legal notification method.
- Precondition: Original PlanDefinition and trigger code value sets / reporting logic exist on test server
- Success Criteria: Provider organization is notified and receives a copy of any PlanDefinition and trigger code value sets / reporting logic specifications that are updated
Ingest Knowledge Distribution / Trigger Codes into EHR
- Action: Provider organization receives a PlanDefinition trigger code / reporting logic update, and ingests them into their EHR to support case report initiation.
- Precondition: PlanDefinition trigger codes / reporting logic updates have been received by provider organization
- Success Criteria: Updates successfully ingested into EHR
Create and Send eICR Document
- Action: Document Creator prepares an eICR (or other registry submission) and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with public health and other extra-clinical organizations. Some may test FHIR messaging for transmissions.
- Precondition: Patient and Encounter resources exist, and sufficient clinical information (Condition, Observation, and other resources) to populate an eICR.
- Success Criteria: eICR is successfully posted to a FHIR server and validates against the eCR profiles found here:
Receive eICR Document
- Action: eICR Document Creator prepares an initial case report and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with public health. eICRs will be queued. The eICR Document Consumer does a GET on each successive eICR and processes it.
- Precondition: eICR exists on a FHIR server.
- Success Criteria: eICR is successfully retrieved from a FHIR server and validates against the eCR profiles found here:
Create Reportability Response (RR)
- Action: RR Document Creator prepares a reportability response and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care.
- Precondition: eICR on which the RR is based exists and contains sufficient information to create an RR.
- Success Criteria: RR is successfully posted to a FHIR server and validates against the eCR profiles found here:
Receive Reportability Response
- Action: RR Document Creator prepares reportability response and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care. RRs will be queued. The RR Document Consumer does a GET on each successive RR and processes it.
- Precondition: RR exists on a FHIR server.
- Success Criteria: RR is successfully retrieved from a FHIR server and validates against the eCR profiles found here:
Scenarios (Referrals)
Create and Send Referral
- Action: EHR prepares and POSTs an electronic referral. This POST may be one of several different transport methodologies supported for exchange with clinical care. The referral receiver does a GET on each successive referral and processes it.
- Precondition: Referral exists on a FHIR server.
- Success Criteria: Referral is successfully retrieved from a FHIR server and validates against the profiles found here:
Receive Referral
- Action: Referral creator prepares referral and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care. Referrals may be queued. The referral consumer does a GET on each successive referral and processes it.
- Precondition: Referral exists on a FHIR server.
- Success Criteria: Referral is successfully retrieved from a FHIR server and validates against the profiles found here:
Create and Send Report Back
- Action: A referral report is created and POSTed it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange.
- Precondition: Referral report information exists sufficient to populate a referral report.
- Success Criteria: Referral report is successfully posted to a FHIR server and validates against the profiles found here:
Receive Report and Attach to Patient Chart
- Action: Referral report creator prepares a referral report and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care. The referral consumer does a GET on each referral report and processes it.
- Precondition: Referral report exists on a FHIR server.
- Success Criteria: Referral report is successfully retrieved from a FHIR server and validates against the profiles found here:
Scenarios (Cancer)
Create a Cancer Registry Profile and Extensions (Cancer Specific)
In this scenario, the reporting to the Cancer Registry requires inclusion of Treatment Plans, Planned Medication Activity, Radiation treatment and results, Family History, Vital Signs, and Cancer Diagnosis elements. This activity involves assessing gaps between existing FHIR resources and necessary Cancer Reporting elements, in order to define a FHIR Profile and Extensions that meets the requirements of Cancer Reporting.
Action: Public Health creates a Cancer Registry Profile and Extensions that captures information needed to support a FHIR Document for Cancer Registry report.
Precondition: Patient, Encounter, and Diagnostic Reporting resources exist on EHR FHIR Server, and sufficient clinical information (Patient, Encounter, Diagnostic Report, Condition, Observation, and other resources) to populate an Ambulatory Cancer report is available on EHR FHIR Server.
Success Criteria: FHIR Profile and Extensions for Cancer Reporting are created and include elements to support cancer reporting
Update Trigger Codes / Reporting Logic on Public Health FHIR Server (Cancer)
In this scenario and elsewhere we refer to “cancer trigger codes” which is used to refer to distributable knowledge resources that will be used by clinical care / EHRs to support triggering and initiating a FHIR Document to support reporting to Cancer Registries. Action: Public Health determines that the current “cancer trigger codes / reporting logic” trigger code value sets / reporting logic require an update. The appropriate value sets are updated in the Public health FHIR Server. Also, a Bundle of Cancer Value Set resources, referenced by the PlanDefinition, will be updated. Precondition: Original trigger code value sets / reporting logic exists on Public Health FHIR server. Success Criteria: Value sets are successfully updated and can be retrieved on demand with GET.
Subscribe to Cancer Trigger Code Updates
Action: Provider organization uses Subscription to subscribe to changes to the PlanDefinition and trigger code value sets using any legal notification method. Precondition: Original PlanDefinition and trigger code value sets exist on test server Success Criteria: Provider organization is notified and receives a copy of any PlanDefinition and trigger code value sets / reporting logic specifications that are updated. Provider ingests Cancer Trigger Codes into EHR Action: Provider organization receives a PlanDefinition Cancer trigger code update, and ingests them into their EHR to support Cancer Registry report initiation. Precondition: PlanDefinition Cancer trigger codes updates have been received by provider organization Success Criteria: Updates successfully ingested into EHR
Create and Send Cancer FHIR Registry Report Document (Cancer Specific)
Action: EHR prepares a FHIR Document based on the FHIR Profile for Cancer Reporting and Posts it to the Public Health FHIR Server. This POST may be one of several different transport methodologies supported for exchange with clinical care. Precondition: Cancer Report trigger has fired, and FHIR Profile for Cancer Reporting exists on a FHIR server. Success Criteria: FHIR Document for Cancer Report is posted and can be retrieved from Public Health FHIR server and validates against the cancer profiles found here: (Zulip Public Health track)
