Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-44805

Encounter plannedStart and plannedEndData are better represented by a Period

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • R5
    • Patient Administration
    • Encounter
    • 8.11.4
    • Hide

      Regarding the planned start and end date being a period, the Period data type does not work well for representing a period of time between two independent events, due to the per-1 constraint.  For example, if you are planning for an admission to start at noon, but the patient shows up at 10am, then the planned start date would remain noon.  But if the activity only takes an hour, and then you do discharge planning to set the planned end date to 11am, you end up with a planned start of noon, and a planned end of 11am, which violates the per-1 constraint.

       

      Note that there are other concerns with the per-1 constraint, but it is what it is.

       

      Regarding the Encounter.period to actualPeriod change, the migration issue is already past, as actualPeriod is in R5, so we would make it worse if folks have to do one migration from R4 to R5, and then again from R5 to R6.   

      Show
      Regarding the planned start and end date being a period, the Period data type does not work well for representing a period of time between two independent events, due to the per-1 constraint.  For example, if you are planning for an admission to start at noon, but the patient shows up at 10am, then the planned start date would remain noon.  But if the activity only takes an hour, and then you do discharge planning to set the planned end date to 11am, you end up with a planned start of noon, and a planned end of 11am, which violates the per-1 constraint.   Note that there are other concerns with the per-1 constraint, but it is what it is.   Regarding the Encounter.period to actualPeriod change, the migration issue is already past, as actualPeriod is in R5, so we would make it worse if folks have to do one migration from R4 to R5, and then again from R5 to R6.   
    • Brian Postlethwaite / Ming Dunajick : 4-0-0

    Description

      Encounter has three timing related fields: actualPeriod, plannedStartDate and plannedEndDate.

      These fields were introduced in FHIR-3251.

      The rationale was that the difference between the period in which the encounter was planned and occurred should become clearer.

      Although I agree with this remark the resolution can be improved.

      The planned start and end date contain valid information but would be better represented as a Period. I propose to change these fields to Encounter.plannedPeriod.

      The namechange from Encounter.period to Encounter.actualPeriod is not needed and will make future migrations from R4 data more complex. I propose to reverse that name change.

      Attachments

        Activity

          People

            Unassigned Unassigned
            bvdh Bas van den Heuvel
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: