Procedure is relatively mature within FHIR. The required properties include:
- status - e.g., preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown
- subject - reference to the patient
So, I would recommend including status (± status_reason) and patient so we’re aligned with FHIR.
Your procedure name (presumably a concept id) aligns with FHIR’s Procedure.code. Ideally, custom name would be required iff the procedure is set to a specific procedure concept like “Procedure, non-coded” … but I couldn’t fiend a CIEL concept for this.
Outcome aligns with FHIR’s Procedure.outcome.
Recording procedure start and optional end time makes sense, but…
- I don’t understand the end datetime comment “null for historical procedures”. I would expect end datetime to be missing if the procedure is still ongoing or if it wasn’t recorded.
- Do we need duration? Couldn’t this be determined from start & end times?
Other properties I would include:
- performer(s) – who performed the procedure. Ideally, would support multiple performers and a function/role for each.
- note (a text field to document details of the procedure).
I agree with @ibacher. Yes, optionally. Matches FHIR’s Procedure.encounter.
I shared a proposal for better date/time support a couple of years ago that would help with partial dates, including allowing capturing a procedure date like “2018”. Like @ibacher suggested, it uses ISO 8601 dates for the actual data and then allows for a date (or datetime) to hold an interpretation (like 2018-01-01) to be used when an actual date/time is needed. I would love to see us start adopting a convention like this (as long as we are consistent as we adopt it instead of re-inventing a new approach in each case).