Case Reporting to Public Health Agencies

Printer Friendly, PDF & Email
Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Balloted Draft
Pilot
Rating 2
No
Free
Yes
Implementation Specification
Balloted Draft
Pilot
Rating 2
No
Free
Yes – Open
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Emerging Standard
In Development
Pilot
Rating 1
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Electronic Initial Case Report (eICR) and the Reportability Response are paired together in pilot implementations to build a complete workflow.
  • Retrieve Form for Data Capture and Structured Data Capture are paired together in pilot implementation to build a complete workflow.
  • Electronic case reporting involves reporting to State and/or Local jurisdictions. It is not yet widespread.
  • Structured Data Capture Implementation Guide does not currently restrict vocabulary to standard vocabulary sets, and may require further implementation guidance for case reporting purposes. 
  • The IHE Quality, Research, and Public Health Technical Framework Supplement, Structured Data Capture, Trial Implementation Guide does not support automated initiation of sending of case reports. It can support manual entry into an electronic form as follow-up to an initial case report submission. 
  • The FHIR electronic Case Reporting (eCR) Implementation Guide is included with both its balloted implementation guide and a link to the FHIR continuous build. The later, as a continuous integration build, may at any point in time be unavailable, incoherent, or undergoing rapid change.
  • Some additional implementation guides related to public health reporting follow. Reporting is often captured under a specialized registry with associated standards when not specified as a separate measure. These include:
  • Note that the maturity level of FHIR resources may vary. The FHIR Maturity Model and each of the levels is described on the HL7 wiki.
  • See FHIR and IHE projects in the Interoperability Proving Ground.
  • Secure Communication – create a secure channel for client-to-server and server-to-server communication.
  • Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.
  • Authentication Enforcer – centralized authentication processes.
  • Authorization Enforcer – specifies access control policies.
  • Credential Tokenizer – encapsulate credentials as a security token for reuse  (e.g., – SAML, Kerberos).
  • Assertion Builder – define processing logic for identity, authorization and attribute statements.
  • User Role – identifies the role asserted by the individual initiating the transaction.
  • Purpose of Use - Identifies the purpose for the transaction.
  • FHIR Security Labels support compliance with laws, policies, and consent directives governing HIPAA PHI and specially protected information (SPI)

Comment

Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

The Pharmacy HIT Collaborative supports the balloted drafts of HL7 CDA R2 Implementation Guide: Consolidated CDA Templates for Clinical Notes (US Realm), DSTU Release 2.1 (with errata); HL7 CDA Release 2 Implementation Guide: Reporting to Public Health Case Reporting, Release 1, DSTU Release 1.1 (US Realm), the Electronic Initial Case Report (eICR); HL7 FHIR Implementation Guide: Structured Data Capture (SDC) STU2; and HL7 CDA R2 Implementation Guide: Reportability Response Release 1, STU Release 1.0 (US Realm).