This page is part of the electronic Case Reporting (eCR) (v0.2.0: STU 1 Ballot 2) based on FHIR R3. The current version which supercedes this version is 2.1.0. For a full list of available versions, see the Directory of published versions 
Notice to Ballot Commenters
Notice to Ballot Commenters
This STU ballot continues and expands on work-to-date on CDA electronic Case Reporting (eCR) standards (HL7 CDA® R2 Electronic Initial Case Report (eICR) Standard for Trial Use (STU) and HL7 CDA® R2 Reportability Response (RR) STU) as well as a previous “For Comment” HL7 FHIR® eCR ballot.
How to provide comments on Ballot
To sign up for the ballot and provide input on this specification follow the same process as for other HL7 artifacts using ballot spreadsheets as described on the HL7 Balloting website or the FHIR GForge Tracker.
If using the spreadsheet, please be sure to include a comment summary for each comment. It is required to be populated in the FHIR GForge Tracker when your comments are moved there. To reference an item in the ballot, Provide the HTML Page Name and/or URL. Look for this icon to appear when you hover over a section.
We would especially appreciate comments on the following items.
1. Additional timing-related reporting parameters and suggested values
The included Knowledge Distribution profile defines three timing-related parameters for initating case reports from Electronic Health Records:
- Delay eICR construction (for example “6” hours) - time after the start of the encounter before a triggered eICR should be composed and sent.(This delay is intended to allow adequate data to be recorded in the EHR, but is not so long as to delay reporting in critical circumstances.)
- eICR periodic update (for example “48” hours) – the time after an initial eICR transmission to send new eICRs as an update for long episodes of care.
- eICR episode of care close-out (for example “24” hours or “0” hours for no delay) – the time after the end of an episode of care for a final eICR to be sent when there has been one or more trigger events. (The close-out eICR is intended to provide the full data available at the end of an episode of care.)
This standard defines these parameters but does not make normative the specific hour values for them. We would appreciate your comments on the possible hour values (in parentheses above) for use in guiding implementations. We would also appreciate comments on the utility of these three parameters or of the needs for others.
2. Difficulties related to CDA using nullFlavors while FHIR does not
The base datatype used by CDA has the property nullFlavor. This means that, unless an IG element constraint has specifically precluded nullFlavor, it is possible to use a nullFlavor for any element in CDA. FHIR on the other hand, does not have this option. To express a nullFlavor concept in FHIR, one would either need to have a value set containing those values or add an extension to express the nullFlavor. Adding an extension to every FHIR data element would be problematic. This means that if an element is required and has not explicitly precluded a nullFlavor in a CDA IG, it is possible, when the data isn’t available to send a nullFlavor instead of a proper value. If the equivalent element is required in a FHIR IG, it isn’t possible to send a nullFlavor unless that nullFlavor value has been added to a value set or an extension has been added to the element. To get around this, we make elements “must support” but allow them to be optional. Then in the case of missing data, the instance still validates.
3. How to best implement patient vital signs for public health reporting
We would propose using either the FHIR Vital Signs profiles (STU) or using the US Core Vital Signs Profile - which outlines “additional guidance which sets the minimum expectations for recording, searching and retreiving vital signs associated with a patient. Together they identify which elements, extensions, vocabularies and value sets SHALL be present in the resource when using this profile.”
