Stream: implementers
Topic: Time Sync / Normalization
Todd Cooper (Jun 24 2016 at 00:12):
This may be a stupid question ... but how are time synchronization rules enforced within a FHIR-based implementation? For example, if you have data coming from multiple device sources, it is imperative to ensure at least second level synchronization, if not sub-second. Obviously, security has similar needs. Is this simply a policy driven outside of FHIR or are there specific support elements? I assume it is the former but would love to be surprised!
Grahame Grieve (Jun 24 2016 at 00:20):
we assume that if you care about that, you will ensure that all nodes are running some time synchronization protocol. - so, outside FHIR
Todd Cooper (Jun 24 2016 at 03:26):
Thanks ... and thus a HUGE issue for device informatics ... I added it to the device track + will address in a new FHIR PSS that we are creating for the DEV WG.
Grahame Grieve (Jun 24 2016 at 03:44):
why do you think this is a huge issue? Aren't time sync protocols pretty routine these days?
John Moehrke (Jun 24 2016 at 14:33):
This is an operational requirement, not something that would be found in a core model. IHE has been very successful with the Consistent Time profile, many have thanked IHE for this quite basic reminder. I looked on the FHIR Security.html page, as expected to find it there as it is critical to many aspects of security including audit and provenance. It could be mentioned here among the other operational requirement reminders.
Lloyd McKenzie (Jun 24 2016 at 14:50):
Do you want to write a change request (for yourself :>)
John Moehrke (Jun 24 2016 at 15:20):
I certainly can, if we think it is the security page where this best belongs. I wonder if the FHIR spec should have a more general landing place for "Operational Considerations", where things that we recognize as operational can be mentioned without binding them into the specification. Similar to the checklist on the security page, but broader. -- I actually thought we had something like this, but can't find it rightnow.
Igor Sirkovich (Jun 24 2016 at 15:43):
I agree that having "Operational Considerations" page would be very helphul. I would also suggest to use it to officially document Grahame's FHIR Implementer’s Safety Checklist from http://www.healthintersections.com.au/?p=2426
Grahame Grieve (Jun 25 2016 at 22:29):
check list is here: http://hl7.org/fhir/implementation.html#2.0.0.1. it would be good to add in both places
John Moehrke (Jun 26 2016 at 15:16):
I created the GF#10243 for this topic.
Erich Schulz (Jun 27 2016 at 01:39):
Nice checklist
Igor Sirkovich (Jun 27 2016 at 18:17):
I would also suggest to have separate checklist / Operational Considerations for server and client applications.
Grahame Grieve (Jun 27 2016 at 20:46):
how would they differ?
Igor Sirkovich (Jun 28 2016 at 14:06):
I assume that a FHIR server might decide what they want/need to implement (e.g. support 5 resources, only specific search types and no paging) and declare the supported functionality in conformance while a client might need to be able to work with different servers. In other words, a server has more control and is mostly focused on complex back-end business rules, exposing some predefined tightly controled information to the outside world. A client, on the other hand, is focused on the user interface and correct processing of information they can get/create/update on one or more servers.
Grahame Grieve (Jun 28 2016 at 19:40):
? wrong topic
Igor Sirkovich (Jun 29 2016 at 14:29):
@Grahame Grieve , my last message was about the differences I can seebetween the Operational Considerations for a server and for a client applications (in response to your question "how would they differ?")
Grahame Grieve (Jun 29 2016 at 20:36):
ah ok. I was hoping for specific comments with regard to the current implementers safety checklist
Last updated: Apr 12 2022 at 19:14 UTC
