Stream: implementers
Topic: Realtime Procedure with timestamps
René Störmer (Aug 25 2020 at 12:57):
In the procedure the following is mentioned: "The creation of a resource to support detailed real-time procedure information awaits the identification of a specific implementation use-case to share such information." I don't get, why this is regarded as such a minor use case. Every hospital at least in Germany needs to document timestamps of the operation as it unfolds (Cut, Suture, Anesthesia Start, Anesthesia End, ...), which is possible in every major Hospital Information System there is. Therefore I thought to create a thread for this, as this mandates a specific discussion in my opinion.
Right now we ware creating an application, which urgently needs to support this feature and FHIR doesn't seem to have a straightforward way to do this, or at least there is some confusion about this topic:
- An extension has been made to support Incision time in a Procedure: procedure-incisionDateTime
- Some people recommend to create a number of procedures to for each phase --> Bad, as there are many timestamps, which would each result in a Procedure for the same Procedure.Code that is being done on the patient (36 timestamps, in the standard we are using, ...)
- Some people talk about using the Procedure, but adding the timestamps in a later revision of FHIR
Right now we are following this process (Simplified):
1. Patient enters the hospital. Doctor diagnoses the Patient and creates a "Condition"
2. Patient needs to be treated, doctor creates a ServiceRequest with the specific code that heals the patients "Condition"
3. An appointment is set, when the ServiceRequest should be filled
4. A Procedure documents the operation and fills the ServiceRequest with the same code.
Major problem:
- No possibility to fill real timestamps in Procedure, like Cut, Suture, Anesthesia Start, ...
- No possibility to document planned timestamps in Appointment
John Moehrke (Aug 25 2020 at 13:01):
You could use AuditEvent, it is intended to record events as they happen. It is used for some workflow tracking use-cases. I don't know of a profiling effort to use it for procedure step tracking, such as surgery or cath-lab.
René Störmer (Aug 25 2020 at 13:05):
John Moehrke said:
You could use AuditEvent, it is intended to record events as they happen. It is used for some workflow tracking use-cases. I don't know of a profiling effort to use it for procedure step tracking, such as surgery or cath-lab.
An AuditEvent is: A record of an event made for purposes of maintaining a security log. Typical uses include detection of intrusion attempts and monitoring for inappropriate usage.
That doesnt fit in my opinion. I am actively suggesting to adapt the Procedure Resource, as the use case fits perfectly in that resource, or to create a new realtime Procedure resource. This could make use of the known coding structure, like so:
[
{
"code" : {
"coding" : [
{
"system" : "VOPM",
"code" : "timeOpEnter"
}
],
"text" : "Patient in OP Raum"
},
"performedDateTime" : ISODate("2020-08-05T05:05:00.000Z")
},
{
"code" : {
"coding" : [
{
"system" : "VOPM",
"code" : "timeOpStart"
}
],
"text" : "Schnitt"
},
"performedDateTime" : ISODate("2020-08-05T05:17:04.000Z")
},
{
"code" : {
"coding" : [
{
"system" : "VOPM",
"code" : "timeOpStop"
}
],
"text" : "Naht"
},
"performedDateTime" : ISODate("2020-08-05T05:36:04.000Z")
},
{
"code" : {
"coding" : [
{
"system" : "VOPM",
"code" : "timeOpExit"
}
],
"text" : "Patient aus OP Raum"
},
"performedDateTime" : ISODate("2020-08-05T05:39:31.000Z")
}
]
John Moehrke (Aug 25 2020 at 13:07):
That is an very old definition of AuditEvent
A record of an event relevant for purposes such as operations, privacy, security, maintenance, and performance analysis.
René Störmer (Aug 25 2020 at 13:25):
John Moehrke said:
That is an very old definition of AuditEvent
A record of an event relevant for purposes such as operations, privacy, security, maintenance, and performance analysis.
Thats what I found on https://www.hl7.org/fhir/auditevent.html. Anyway, thanks for your suggestion, but thats not what I am looking for. I explicitly want to discuss the following sentence in the Procedure: The creation of a resource to support detailed real-time procedure information awaits the identification of a specific implementation use-case to share such information.
Lloyd McKenzie (Aug 25 2020 at 13:39):
Procedure hasn't been well-exercised for real-time data capture - it's primarily been used (so far) for after-the fact summarization. Feedback (and change requests) are welcome. Note that dateTime can capture the full precision of a timestamp, it just doesn't require it. It's possible to capture sub-procedures for aspects such as individual incisions, etc.
René Störmer (Aug 25 2020 at 13:42):
Lloyd McKenzie said:
Procedure hasn't been well-exercised for real-time data capture - it's primarily been used (so far) for after-the fact summarization. Feedback (and change requests) are welcome. Note that dateTime can capture the full precision of a timestamp, it just doesn't require it. It's possible to capture sub-procedures for aspects such as individual incisions, etc.
Thanks. Consider this as feedback ;) The resource Procedure is perfect for our case, however I just can't insert a number of timestamps and I really don't want to split one procedure.code with 36 timestamps, into 18 different procedures in our data.
Lloyd McKenzie (Aug 25 2020 at 13:49):
Feedback that drive's change needs to be submitted as a formal change request - use the "propose a change" link at the bottom of any page in the spec.
Jose Costa Teixeira (Aug 25 2020 at 21:47):
@René Störmer this seems another thread with same question.
Jose Costa Teixeira (Aug 25 2020 at 21:47):
I think the German colleagues suggested a standard extension for that use case.
Jose Costa Teixeira (Aug 25 2020 at 21:52):
And my understanding of your use case is the following: if you make changes for each specific (legal) requirement, you'll need to capture a facet of the information for this requirement, later you will still have to capture other details, and this will grow... My personal opinion is that if your scope grows, you'll be longing for the days when one procedure was only 18+1 resources
Jose Costa Teixeira (Aug 25 2020 at 21:57):
Why can't you use contained Procedure resources? I think you only need 5attributes for each: status, patient, code, time and partOf
Jose Costa Teixeira (Aug 25 2020 at 22:00):
I don't see why this would require a change in core
René Störmer (Aug 26 2020 at 12:19):
I am copying the rest of your reply from another thread over to this place. Thanks for the discussion with you so far!
Jose Costa Teixeira: From what I can follow: If you really only ever want the timestamps for those events, you can use the progressStatus extension.
Jose Costa Teixeira: If you want to capture the use of medication, you'd need a medicationAdministration at least. If you want to capture room usage, you'd also better capture some of the different resources.
Jose Costa Teixeira: It seems your use case @René Störmer is about statistics/process control indicators. The "timestamps" are synthetic and are OK for that.
If your case would be OR optimization, you may be interested in capturing more details (e.g. which operating room, which anesthesist, which monitors are used, etc.).
Jose Costa Teixeira said:
And my understanding of your use case is the following: if you make changes for each specific (legal) requirement, you'll need to capture a facet of the information for this requirement, later you will still have to capture other details, and this will grow... My personal opinion is that if your scope grows, you'll be longing for the days when one procedure was only 18+1 resources
The scope of one procedure is "almost" perfect right now. Of course I want to track things like used material, peformers, locations, but that is all there and can be done in one procedure. That way I also only have to track and update the status of one procedure, as it in preparation, in-progress and completed.
I am able to track all performers that took part in the procedure and I really like that logic. The same I would like to do for timestamps, as they give a more detailed view on the "in-progress" status part of the procedure.
In my understanding one procedure tracks the fulfilment of one Procedure.code, which might be a Snomed, OPS or ICD-10-PCS code. So I would like to say:
We are operating Patient A with the following procedure, which is documented in Procedure.code. This procedure goes through the lifecycle, as documented in Procedure.status. As soon as I set my Procedure to "completed" in Procedure.status, I know that the patient has undergone that Procedure. I don't want to look in multiple other 18 procedures or manage 18 other procedures. What I would do is, to create another Procedure, if two Procedure.code are operated on the patient in the same appointment, maybe even in parallel. That would make total sense and would be possible to handle from a data perspective.
I could use the extension progressStatus, but in my opinion, tracking timestamps for a procedure is a core requirement (As tracking timestamps is a legal requirement in Germany) and using the extension would definitely disqualify using the Procedure resource as a data saving format (Which I would very much like to do), as it is not very suitable for performant queries.
Vassil Peytchev (Aug 26 2020 at 13:32):
using the extension would definitely disqualify using the Procedure resource as a data saving format
What is the reason for such a disqualification?
FHIR#28358 created. @René Störmer, please create a Jira account at https://jira.hl7.org/ and add yourself to watch this issue (if you want to participate in the Patient Care workgroup discussions on it).
Jose Costa Teixeira (Aug 26 2020 at 13:55):
The existing mechanisms allow for tracking this in sub-procedures. Tracking timestamps is a core procedure, but tracking timestamps only and in the top resource is not.
Jose Costa Teixeira (Aug 26 2020 at 13:55):
I don't see why we'd want to change the core behaviour to accommodate for a requirement that is about monitoring which in my experience always comes with more and more requirements - you will need to drill down to the details, see the timestamp AND performer AND location...
Jose Costa Teixeira (Aug 26 2020 at 13:59):
The fact that this resource is almost perfect for this one use case is great, but not a requirement that we must make it perfect in that way. This
seems tweaking the standard to support a specific requirement rather than the diversity we have out there, and I don't think it is a good idea.
Jose Costa Teixeira (Aug 26 2020 at 14:00):
Maybe I am not understanding well how this could be done without duplicating the functionality we have today, but what is being asked is already supported.
Jose Costa Teixeira (Aug 26 2020 at 14:00):
I've commented something along these lines in the tracker issue
René Störmer (Aug 26 2020 at 14:27):
Vassil Peytchev said:
using the extension would definitely disqualify using the Procedure resource as a data saving format
What is the reason for such a disqualification?
FHIR#28358 created. René Störmer, please create a Jira account at https://jira.hl7.org/ and add yourself to watch this issue (if you want to participate in the Patient Care workgroup discussions on it).
Because the way extensions are stored don't lead to a good readability and performance when querying. For smaller adaptions to a resource this is okay, but timestamps are a core feature for us as I said, so it would be bad design for us to do this in a FHIR extension in the Procedure Resource.
Thanks for creating the Ticket! I requested an Account
René Störmer (Aug 26 2020 at 14:41):
Jose Costa Teixeira said:
The fact that this resource is almost perfect for this one use case is great, but not a requirement that we must make it perfect in that way. This
seems tweaking the standard to support a specific requirement rather than the diversity we have out there, and I don't think it is a good idea.
It is not a specific requirement, but a common use case in Europe. Imagine a random example Procedure with the code 039C40Z, which I want to track. This Procedure takes place and has a number of timestamps, which are in this case named by the customer (Easily solvable with the Coding resource). How would you do this using multiple procedure resources and still be able to track the status of the main procedure easily and query after the all timestamps in an efficient manner, based on the main Procedure that we are using in our program logic?
Patient arrived in hospital: 18.02.2020 08:00
Patient requested: 18.02.2020 10:01
Patient in OP Area: 18.02.2020 10:30
Patient waiting time start: 18.02.2020 10:44
Patient waiting time end: 18.02.2020 10:49
Patient Anesthesia Start: 18.02.2020 11:20
Patient Anesthesia Stop: 18.02.2020 11:30
Patient in OP Room: 18.02.2020 11:40
Patient Cut: 18.02.2020 11:45
Patient Suture: : 18.02.2020 12:15
Patient out OP Room: 18.02.2020 12:30
Room clean start: 18.02.2020 12:45
Room clean stop: 18.02.2020 13:00
Patient out OP Area: 18.02.2020 13:30
René Störmer (Aug 26 2020 at 14:47):
The main question really is, what is the scope of the procedure? I would say that the scope of a procedure is Procedure.code. It should be possible to track the overall status of the scope of a Procedure in a Procedure resource. This can be done in parts by Procedure.status, but not in detail, while the Procedure unfolds in real time, which is what I am asking for --> Procedure.timestamps
Jose Costa Teixeira (Aug 26 2020 at 16:16):
capturing ONLY the timestamps seems like a very specific requirement.
Jose Costa Teixeira (Aug 26 2020 at 16:17):
Timestamps alone are core feature for one project, for another project it will be the timestamps and sub-procedures.
Jose Costa Teixeira (Aug 26 2020 at 16:19):
René Störmer said:
The main question really is, what is the scope of the procedure? I would say that the scope of a procedure is Procedure.code. It should be possible to track the overall status of the scope of a Procedure in a Procedure resource. This can be done in parts by Procedure.status, but not in detail, while the Procedure unfolds in real time, which is what I am asking for --> Procedure.timestamps
It seems what you are asking is :
We don't want to use sub-procedures for this use case. But we have a requirement to preserve the timestamps for the evolution of the procedure, and the way our database is working makes the use of extensions less interesting/ less performant, so I suggest changing the core standard.
Jose Costa Teixeira (Aug 26 2020 at 16:24):
so:
- Is is clear that you can track the timestamps using sub-procedures? Or is there a gap there?
- what is the issue with extensions' "readability and performance"? extensions are for computers to read, and computers can handle a bit of nesting. Did you consider an extension or you just want to change the core to fit that use case?
Jose Costa Teixeira (Aug 26 2020 at 16:25):
An example: A few years ago we needed "serial number" on medications. It was not commonly known that this was a legal requirement, and most systems were not ready, so we accepted to have an extension that then became part of the core. And that was a unique, unmet requirement. What you are asking does not seem a unique, unmet requirement, but a design preference.
Lloyd McKenzie (Aug 26 2020 at 17:15):
One thing to consider is that the 'sub-procedures' could be contained resources within the overall Procedure instance.
René Störmer (Sep 01 2020 at 08:50):
Lloyd McKenzie said:
One thing to consider is that the 'sub-procedures' could be contained resources within the overall Procedure instance.
@Jose Costa Teixeira posted the following example in JIRA. To clarify a few questions. I will write a more complete reply in JIRA once I find time:
- Procedure.code should be used to name the code of the procedure, so what is being done on the patient. It would be confusing to insert a timestamp here in contained resources, as we are using Procedure.code in the main Procedure correctly
- I guess instead of occurence[x] you meant performed[x]?
- I would only need to specify which timestamp I am referencing and performedDateTime. Procedure.status is required, but I really don't want to track the correct status as of now.
In my opinion this is not a clean and explicit solution, but a possible one anyway!
{
"resourceType": "Procedure",
"id": "mainSurgery",
"contained": [
{
"resourceType": "Procedure",
"id": "prep",
"partOf": [{"reference": "Procedure/mainSurgery"}],
"status": "completed",
"code": {
"coding": [{"code": "#preparation"}]},
"occurrencePeriod": {
"start": "xxxxx",
"end": "yyyyy"
}
},
{
"resourceType": "Procedure",
"id": "anesthesia",
"partOf": [{ "reference": "Procedure/mainSurgery" }],
"status": "completed",
"code": {
"coding": [{ "code": "#anesthesia"}]},
"occurrencePeriod": {
"start": "xxxxx",
"end": "yyyyy"
}
},
...
{
"resourceType": "Procedure",
"id": "recovery",
"partOf": [{
"reference": "Procedure/mainSurgery"}],
"status": "completed",
"code": {
"coding": [{"code": "#recovery"}]
},
"occurrencePeriod": {
"start": "xxxxx",
"end": "yyyyy"
}
}
],
"status": "completed",
"code": {"coding": [{"code": "#Appendectomy"}]},
"occurrencePeriod": {
"start": "xxxxx",
"end": "yyyyy"
}
}
Jose Costa Teixeira (Sep 01 2020 at 08:56):
- the contained procedure.code is the code for the detailed activity (as in the other stream, other people have the requirement to track that). If your case does not require that, you can just put the same code as the main procedure.
- performed[x] became occurrence[x] in the current build, so yes, it's the same.
- if you know specific status of "anesthesia" or "recovery", you can track it there. Presumably they are completed by the time you finish the procedure.
Last updated: Apr 12 2022 at 19:14 UTC
