Difference between revisions of "FHIR Workflow Minutes CC 20160523"
(draft) |
|||
| Line 17: | Line 17: | ||
No minutes from previous call | No minutes from previous call | ||
| − | |||
==Agenda== | ==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. | 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. | ||
| Line 28: | Line 28: | ||
Currently, each historical version has a provenance. | 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. | 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. | This mechanism would also avoid worries about duplicate data. | ||
| + | |||
About simply using history for that: | About simply using history for that: | ||
| Line 50: | Line 52: | ||
Link to document: | Link to document: | ||
* See [http://wiki.hl7.org/images/0/0f/Workflow_to_date.docx] | * See [http://wiki.hl7.org/images/0/0f/Workflow_to_date.docx] | ||
| + | |||
| Line 63: | Line 66: | ||
Discussion will continue on Monday. | Discussion will continue on Monday. | ||
| − | |||
| − | |||
| − | |||
| − | |||
==Adjournment== | ==Adjournment== | ||
Revision as of 19:28, 23 May 2016
FHIR Workflow Conference Call 3:00PM Eastern Time (Date above)
Return to FHIR Workflow Minutes
Agenda
Attendees
- Lloyd McKenzie (chair/scribe)
- Hans Buitendijk
- Keith Boone
- Bob ??
- ???
Minutes
No minutes from previous call
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.
