This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201801 Electronic Case Reporting"

From HL7Wiki
Jump to navigation Jump to search
 
(4 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
__NOTOC__
 
__NOTOC__
 
=Electronic Case Reporting=
 
=Electronic Case Reporting=
 +
 +
[https://drive.google.com/open?id=1Qt_O6XmJxD4cJMRh26jzKU3NlNOeZCZB  Electronic Case Reporting Slides]
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
Line 8: Line 10:
  
 
==Justification==
 
==Justification==
Electronic case reporting has been maturing in the CDA product family with two documents, the electronic Initial Case Report (eICR) and the Reportability Response.  Some preliminary FHIR case reporting specifications have now been developed and are being balloted for comment. This track will explore various aspects of FHIR case reporting as they mature, beginning with:
+
 
* Trigger code representation and dissemination from Public Health to clinical care sites and EHRs;
+
Electronic case reporting (eCR) has been maturing in the CDA product family, and some preliminary FHIR case reporting specifications have now been developed and are being balloted for comment. This track will explore various aspects of FHIR case reporting as they mature, beginning with trigger code representation and dissemination, initial Electronic Case Report (eICR) and Reportability Response (RR) instance generation, and eventually expanding to distributing decision support logic and other items for the support of reporting and management in future Connectathons. This track could include discussions on additional resource needs for these use cases and discussion of items in the current “For Comment” eCR ballot.
* FHIR versions of  the electronic Initial Case Report (eICR) and Reportability Response instance exchange;
+
 
* Eventual expansion to decision support logic and other transactions to support case reporting and management as those aspects mature in future Connectathons.
 
This track will include discussions on additional resource needs for these use cases as well.
 
 
The electronic Case Reporting implementation guide currently in ballot can be found here:
 
The electronic Case Reporting implementation guide currently in ballot can be found here:
  
Line 34: Line 34:
  
 
==Roles==
 
==Roles==
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
+
 
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
 
 
===Public Health===
 
===Public Health===
  
Line 42: Line 41:
 
===Public Health Agency===
 
===Public Health Agency===
  
Jurisdiction or agency that will receive and manage case reports, and at times send and/or receive reportability responses.
+
Agencies that will eventually receive and manage electronic Initial Case Reports (eICRs), and at times send and/or receive Reportability Responses
  
 
===Intermediaries===
 
===Intermediaries===
  
Organizations in the information flow between a health care organization and a public health agency. Examples include HIEs, the shared platform supported by APHL and CSTE, etc.
+
Organizations in the information flow between a health care organization and a public health agency. 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===
 
===Health Care Organization===
  
Organization that submits case reports based on trigger codes, and receives trigger code updates and reportability responses. The health care organization can be supported by an EHR vendor in this role.
+
Organization that submits electronic Initial Case Reports (eICRs) based on trigger code matches, and receives trigger code updates and Reportability Responses. The health care organization can be supported by an EHR vendor in this role.
  
 
===eICR Document Creator===
 
===eICR Document Creator===
Organization responsible for creating an electronic Initial Case Report (eICR) and sending it to an eICR Document Participant. Examples: EHR vendors and specialty reporting companies.
+
Organization responsible for creating an electronic initial case report (eICR) and sending it to an eICR Document Participant. Examples: EHR vendors and specialty reporting companies.
  
 
===eICR Document Participant===
 
===eICR Document Participant===
Organization responsible for receiving and processing an electronic Initial Case Report (eICR). Examples: APHL or a public health agency (PHA). The eICR Document Participant may also play the role of a Reportability Response Document Creator.  
+
Organization responsible for receiving and processing an electronic initial case report (eICR). Examples: APHL or a public health agency (PHA). The eICR Document Participant may also play the role of a Reportability Response Document Creator.  
  
 
===Reportability Response Creator===
 
===Reportability Response Creator===
Organization responsible for creating a Reportability Response and sending it to a Reportability Response Consumer. Examples: APHL or a public health agency (PHA). The Reportability Response Document Creator may also play the role of an eICR Document Participant.
+
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===
 
===Reportability Response Consumer===
Organization responsible for receiving and processing a Reportability Response (RR). Examples: EHR vendors and specialty reporting companies.). The Reportability Response Consumer may also play the role of an eICR Document Creator.
+
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==
 
==Scenarios==
<!-- What will be the actions performed by participants? -->
 
  
 
=== Update Trigger Codes on Public Health FHIR Server ===
 
=== Update Trigger Codes on Public Health FHIR Server ===
Line 86: Line 84:
  
 
===Create eICR Document===  
 
===Create eICR Document===  
:Action: eICR Document Creator prepares an initial case report and POSTs it to a FHIR server.  
+
: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.
:Precondition: Patient and Encounter resources exist, and sufficient clinical information 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 eICR profiles found here: http://hl7.org/fhir/uv/ecr/2018Jan/profiles.html
+
:Success Criteria: eICR is successfully posted to a FHIR server and validates against the eCR profiles found here: http://hl7.org/fhir/uv/ecr/2018Jan/profiles.html
:Bonus point: eICR is created in response to evaluating trigger codes against patient data.  
+
:Bonus point: eICR is created in response to evaluating trigger codes against patient data. Triggering may occur if an EHR diagnosis or problem code matches a code in the diagnosis trigger code value set, if a lab result code matches a code in the lab result trigger code value set, or if a lab order code matches a code in the lab test order trigger code value set.
  
 
===Receive eICR Document===
 
===Receive eICR Document===
:Action: eICR Document Creator prepares an initial case report and POSTs it to a FHIR server. The eICR Document Consumer does a GET on the eICR and processes it. (The POST and GET here may not be the only supported transactions, but they will be the initial ones that are tested)
+
: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 eICR profiles found here: http://hl7.org/fhir/uv/ecr/2018Jan/profiles.html
+
:Success Criteria: eICR is successfully retrieved from a FHIR server and validates against the eCR profiles found here: http://hl7.org/fhir/uv/ecr/2018Jan/profiles.html
:Bonus point: a Reportability Response is created in response to the eICR.  
+
:Bonus point: a Reportability Response is created in response to the eICR.
 +
 
 +
Clarification: to be discussed as part of the connectathon what 'getting each successive eICR' means at the API level
  
===Create Reportability Response===
+
===Create Reportability Response (RR) ===
:Action: Reportability Response Creator prepares a reportability response and POSTs it to a FHIR server.  
+
: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/uv/ecr/2018Jan/profiles.html
 
:Success Criteria: RR is successfully posted to a FHIR server and validates against the eCR profiles found here: http://hl7.org/fhir/uv/ecr/2018Jan/profiles.html
  
 
===Receive Reportabilty Response===
 
===Receive Reportabilty Response===
:Action: Reportabilty Response Creator prepares reportability response and POSTs it to a FHIR server. The Reportabilty Response Consumer does a GET on the RR and processes it. (The POST and GET here may not be the only supported transactions, but they will be the initial ones that are tested)
+
: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/uv/ecr/2018Jan/profiles.html
 
:Success Criteria: RR is successfully retrieved from a FHIR server and validates against the eCR profiles found here: http://hl7.org/fhir/uv/ecr/2018Jan/profiles.html

Latest revision as of 15:38, 27 January 2018

Return to Jan 2018 Proposals

Electronic Case Reporting

Electronic Case Reporting Slides

Submitting WG/Project/Implementer Group

Public Health (PH)

Justification

Electronic case reporting (eCR) has been maturing in the CDA product family, and some preliminary FHIR case reporting specifications have now been developed and are being balloted for comment. This track will explore various aspects of FHIR case reporting as they mature, beginning with trigger code representation and dissemination, initial Electronic Case Report (eICR) and Reportability Response (RR) instance generation, and eventually expanding to distributing decision support logic and other items for the support of reporting and management in future Connectathons. This track could include discussions on additional resource needs for these use cases and discussion of items in the current “For Comment” eCR ballot.

The electronic Case Reporting implementation guide currently in ballot can be found here:

http://hl7.org/fhir/uv/ecr/2018Jan/index.html

Proposed Track Lead

  • John Loonsk
  • Rick Geimer


See Connectathon_Track_Lead_Responsibilities

Expected participants

  • APHL
  • CDC
  • CGI Federal
  • Epic
  • Lantana Consulting Group


Roles

Public Health

Responsible for managing and disseminating trigger codes and decision logic.

Public Health Agency

Agencies that will eventually receive and manage electronic Initial Case Reports (eICRs), and at times send and/or receive Reportability Responses

Intermediaries

Organizations in the information flow between a health care organization and a public health agency. 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

Organization that submits electronic Initial Case Reports (eICRs) based on trigger code matches, and receives trigger code updates and Reportability Responses. The health care organization can be supported by an EHR vendor in this role.

eICR Document Creator

Organization responsible for creating an electronic initial case report (eICR) and sending it to an eICR Document Participant. Examples: EHR vendors and specialty reporting companies.

eICR Document Participant

Organization responsible for receiving and processing an electronic initial case report (eICR). Examples: APHL 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

Update Trigger Codes on Public Health FHIR Server

Action: Public Health determines that the current trigger code value sets require an update. The appropriate value sets are updated using PUT. Also update trigger codes as a Bundle of ValueSet resources so they can be updated as a whole set.
Precondition: Original trigger code value sets exist on test server
Success Criteria: Value sets are successfully updated and can be retrieved on demand with GET
Bonus point:

Subscribe to Trigger Code Updates

Action: Provider organization uses Subscription to subscribe to changes to trigger code value sets (or value set Bundle) using any legal notification method.
Precondition: Original trigger code value sets exist on test server
Success Criteria: Provider organization is notified and receives a copy of any trigger code value sets that are updated
Bonus point:

Ingest Trigger Codes into EHR

Action: Provider organization receives a trigger code update, and ingests the trigger codes into their EHR to support case report initiation.
Precondition: Trigger codes updates have been received by provider organization
Success Criteria: Trigger code updates successfully ingested into EHR
Bonus point:

Create 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.
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/uv/ecr/2018Jan/profiles.html
Bonus point: eICR is created in response to evaluating trigger codes against patient data. Triggering may occur if an EHR diagnosis or problem code matches a code in the diagnosis trigger code value set, if a lab result code matches a code in the lab result trigger code value set, or if a lab order code matches a code in the lab test order trigger code value set.

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: http://hl7.org/fhir/uv/ecr/2018Jan/profiles.html
Bonus point: a Reportability Response is created in response to the eICR.

Clarification: to be discussed as part of the connectathon what 'getting each successive eICR' means at the API level

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: http://hl7.org/fhir/uv/ecr/2018Jan/profiles.html

Receive Reportabilty 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: http://hl7.org/fhir/uv/ecr/2018Jan/profiles.html

TestScript(s)

Security and Privacy Considerations