Hi Thomas,
The original idea was that a logical EHR service id would be used. A
'client id' is likely to be meaningless and untrackable. The id is
only useful if it is relatively permanent, and future information
requests can be made to that logical EHR system. It would also be
the id of the system that other users who could see this information
were using, and where medico-legal investigations take place.
I think that depends on the architecture of each system. Let me explain my
architecture design:
One EHR Server: handles composition persistence, has commit and query
services.Many EMR Systems/Apps: handles data input, commit client, query client.
Functionality:The new COMPOSITIONs are available to the EHR SYSTEM when an EMR
System commits it to the EHR Server.Each EMR System has a unique ID that is
permanent, at least for data input. (I want to know who changes the EHR).For
data visualization, a unique ID or a permanent one is not required. (login
information would suffice to know who is accessing the EHR).
If there is a Paediatric EMR (PEMR) and an Emergency EMR (EEMR), from the PEMR
a clinician could see records committed from the EEMR, and he/she may want to
know that a record was created on the Emergency System.
I know this can be addressd by using EVENT_CONTEXT.location & setting, but for
medico-legal issues it will be necessary to have track of the record from the
authoring system to the persistent storage, IMO that should be done using audit
trail data from AUDIT_DETAILS (I think that's the role of AUDIT_DETAILS in the
IM).
What do you think?
In a more cloud-based world, it might not seem so clear, because
numerous organisations might be committing to a physical service
that supports multi-tenanting.
I'm thinking this to be a mini cloud, but only for one organization.
However, in either case, it should be something like a domain name
of an EHR service that is understood to be the legal EHR repository
facility of the organisation in which the clinician works.
Considering the architecture and funcionalities (services) above, you
understand as "domain name of an EHR service" as the EHR SERVER, the EMR
CLIENTs, or the whole system (one EHR SERVER, many EMR Systems)?
There might be an argument for having another field for 'client
device type' (e.g. phone, iPad etc).
I'm not on "device area" yet :)
Thanks,Pablo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130123/4ffeeaa7/attachment.html>
