Providers should not be required to provide the precise reason for missing data

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Highest
    • US Da Vinci Alerts (FHIR)
    • 0.2.0 [deprecated]
    • Infrastructure & Messaging
    • Framework
    • 2.1.6
    • Hide

      This is not a functional requirement but a data exchange requirement and doesn't prescribe how the data absent reason is generated by the Sender (data source)

      This text is taken from US Core Implementation guide definition of must support. It means that if a system can identify the reason the data is empty then provide a reason. It does not prescribe UX feature as the commenter is suggesting.

      for example if a value is missing and the reason is the system can interpret a string value for a structured element that is not string then the system would indicate by adding the Data absent reason extension with a value of "unknown" . In some cases the end user may indeed enter the reason such as "asked but unknown" ,etc. but this is an implementation detail and out of scope for this implementation guide.

      Will update the text to read:

      "If a particular data element is missing and the Sender knows the precise reason for the absence of data, then the Sender SHALL provide the reason for the missing information using "null" values from the value set where they exist or using the dataAbsentReason extension. - The assumption is that system implementers will, wherever possible, automate the population of missing values with "null" values without requiring--but providing the option for--manual entry."

      Show
      This is not a functional requirement but a data exchange requirement and doesn't prescribe how the data absent reason is generated by the Sender (data source) This text is taken from US Core Implementation guide definition of must support. It means that if a system can identify the reason the data is empty then provide a reason. It does not prescribe UX feature as the commenter is suggesting. for example if a value is missing and the reason is the system can interpret a string value for a structured element that is not string then the system would indicate by adding the Data absent reason extension with a value of "unknown" . In some cases the end user may indeed enter the reason such as "asked but unknown" ,etc. but this is an implementation detail and out of scope for this implementation guide. Will update the text to read: "If a particular data element is missing and the Sender knows the precise reason for the absence of data, then the Sender SHALL provide the reason for the missing information using "null" values from the value set where they exist or using the dataAbsentReason extension. - The assumption is that system implementers will, wherever possible, automate the population of missing values with "null" values without requiring-- but providing the option for --manual entry."
    • Eric Haas/Paul Knapp: 3-0-1
    • Clarification
    • Non-substantive
    • Yes

       The AMA would like to express concern – if the data aren’t available, will the physician need to manually check a box to indicate this (vs. just leaving empty)? Why does the receiver care if there is a reason for the data not being there – it is absent because it isn’t present in the sender’s system. This sounds burdensome for providers to have to provide a reason for a missing element.

      Existing Wording:

      In situations where information on a particular data element is missing and the Sender knows the precise reason for the absence of data, the Sender SHALL provide the reason for the missing information using values (such as nullFlavors) from the value set where they exist or using the dataAbsentReason extension. 

            Assignee:
            Unassigned
            Reporter:
            Celine Lefebvre
            Celine Lefebvre
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: