FHIR Workflow Minutes CC 20160523
FHIR Workflow Conference Call 3:00PM Eastern Time (Date above)
Return to FHIR Workflow Minutes
Agenda
Attendees
- Lloyd McKenzie (chair/scribe)
- Brian Nantz
- Chethan Makonahalli
- Eric Haas
- Gary Dickinson
- Hans Buitendijk
- Karl Holzer
- Miranda Hoang
- Reinhard Egelkraut
- Yunwei Wang
- Jose Costa Teixeira (after minutes)
Minutes
- Motion to approve minutes of May 2: Hans/Chethan unan
- Motion to approve minutes of May 4: Hans/Reinhard unan
Agenda
Discussion on order history
Workflow discussion
How to handle changes to an order. Current possibilities are using event and using version history. If those are captured in these different ways, there is nothing enforcing that those would match.
Another proposed option would be to include an extension or core element that points to a provenance, which can be used to preserve the changes of the order.
Currently, each historical version has a provenance.
To retrieve the changes, we do not have to go into the history, we could just have link to 0..* provenances, each of which points to a specific historical point.
This mechanism would also avoid worries about duplicate data.
About simply using history for that:
Another choice could be tagging the elements that have changed if they are salient changes.
Issue is that currently, each historical version has the original content, but it is currently not possible to search for relevant previous versions, as history cannot be searched.
One challenge is that this seems overloading provenance. We are using provenance as it was intended AND to track relevant prior history. Having one relation for both the Current and prior provenance, not distinguish could be problematic. Using the date to distringuish - i.e. the last provenance is the provencance, every other is history... could work but could need to change in the future for complex cases.
To address this, we can have a "relevanthistory" kind of element with the 0..* cardinality. We don't have to keep all history. What is important can change over time. Business rules would dictate when to "tag" one specific relevant version.
Still unanswered is the matter of data elements that are not in the request element but are relevant: Status is one of them. This history mechanism should also retrieve that status as it is part of the relevant history.
The reason to go to 0..* is to satisfy the need to express "for this current version here is a list of relevant changes".
Querying this can choose to bring back the provenance (current), or the previous history,avoiding the race condition that could be an issue when resolving this.
Link to document:
- See [1]
About changes and status preservation in that history: What is captured in provenance is the state, not the transition. How do we capture the relevant state information from that?
Looked at http://hl7-fhir.github.io/v3/ProvenanceEventCurrentState/vs.html
Need to review the activity state codes, as they are referring to states and not transitions.
Discussion will continue on Monday.
