Sending study to another user
I am interested if there is any possibility to send a study to another user without using an AE station for that.
For instance what could be done if the reffering physician want a second opinion from a specialist (that can write a note attached to the study)?
Making the study public or exporting it is more difficult than just giving access to the private study and some mean to include the specialist into some kind of workflow.
I think this question touches a bit of telemedicine concept.
For instance what could be done if the reffering physician want a second opinion from a specialist (that can write a note attached to the study)?
Making the study public or exporting it is more difficult than just giving access to the private study and some mean to include the specialist into some kind of workflow.
I think this question touches a bit of telemedicine concept.
This can be easily done via a URL in the email sent to the user, but the main concern here is security/privacy, i.e.:
1. Do we want to encode the authentication information (e.g., username/password) within the URL in the email? That would be a security risk since we have no control over how the email may be delivered?
2. If we do not include any authentication information in the email to the user, then he/she will have to enter the authentication information manually from the web browser after clicking on the URL from the email. In this case, how do we authenticate this user? Are you going to allow that user to login as your registered username/password so that he/she can access all the studies you can see, or do you want to allow allow access for a particular study that's referenced in the URL? If it's the latter case, then the user would need to login via a separate/temporary username/password so that only that study can be accessed.
1. Do we want to encode the authentication information (e.g., username/password) within the URL in the email? That would be a security risk since we have no control over how the email may be delivered?
2. If we do not include any authentication information in the email to the user, then he/she will have to enter the authentication information manually from the web browser after clicking on the URL from the email. In this case, how do we authenticate this user? Are you going to allow that user to login as your registered username/password so that he/she can access all the studies you can see, or do you want to allow allow access for a particular study that's referenced in the URL? If it's the latter case, then the user would need to login via a separate/temporary username/password so that only that study can be accessed.
Well, in the first place I suppose all actors here are already registered users.
What I aim is that the user who is „owner” of the private study (let say referring physician or requesting physician) should be able to select a reading physician from the users list (or maybe she just know that reading physician name beforehand). Then the reading physician would write his notes and „send” the study back to the main doctor.
Moreover, it should be possible to repeat the process with another reading physician, and another and so on.
From security point of view we need to allow the currently selected reading physician temporary access to the private study
Maybe this functionality is already there and I just do not know how to use it...
What I aim is that the user who is „owner” of the private study (let say referring physician or requesting physician) should be able to select a reading physician from the users list (or maybe she just know that reading physician name beforehand). Then the reading physician would write his notes and „send” the study back to the main doctor.
Moreover, it should be possible to repeat the process with another reading physician, and another and so on.
From security point of view we need to allow the currently selected reading physician temporary access to the private study
Maybe this functionality is already there and I just do not know how to use it...
Yes, there's an existing feature called group user that you can use for such purposed you described above. For example, you can define a group user and assign all the interested doctors to the group, e.g., the referring physician, requesting physician, performing physician, reading physician, etc. Then you can assign this study to that group user so that all members of that group will be able to access that study stored in the PacsOne Server database.
Then if I create a group and link it to some sending AE station I can make sure everything loaded from that station is readable by all members of the group.
I tested this and it works OK. Unfortunately MedDream web client does not implement groups security, still I managed to use the Show button to display the study in meddream.
I tested this and it works OK. Unfortunately MedDream web client does not implement groups security, still I managed to use the Show button to display the study in meddream.
The web-based Dicom image viewers (such as MedDream) should NOT have any security policy at all, as they should leave it to the browsers from which they are running. In other words, the web pages should be implementing/enforcing the security policies if any, and the viewers should be concerned with the presentation/display of the subject images and nothing else.
After studying for a while I saw that MedDream is using a long SQL query constructed to fit several PACS systems as backend in order to search accesible studies by the current user.
In this query they only compare current user's firstname and lastname with records in studies profiles.
I was able to come up with a hack and add some group security things there.
If someone is interested please modify the if section starting at line 220 in search.php from meddream installation to this:
This code does not count for group description matching institution name thing. I would like to add this one too but I still need to understand it before I can attempt it.
In this query they only compare current user's firstname and lastname with records in studies profiles.
I was able to come up with a hack and add some group security things there.
If someone is interested please modify the if section starting at line 220 in search.php from meddream installation to this:
Code: Select all
/* PacsOne, an user without 'viewprivate' privilege: study.private=1
are to be viewed only by a corresponding Referring Physician or
Reading Physician
*/
if (!$actions && !$authDB->isAccess("view"))
{
$where .= " AND (";
$where .= "study.private=0";
$firstName = addslashes($authDB->firstName());
$lastName = addslashes($authDB->lastName());
$where .= " OR ";
$where .= "referringphysician LIKE '%$firstName%$lastName%'";
$where .= " OR ";
$where .= "referringphysician LIKE '%$lastName%$firstName%'";
$where .= " OR ";
$where .= "readingphysician LIKE '%$firstName%$lastName%'";
$where .= " OR ";
$where .= "readingphysician LIKE '%$lastName%$firstName%'";
//adding PACSONE group security
$currentusername = $authDB->user;
//multidimensional array to store users and groups with shared permissions via group security
$userslist = array();
//retrieve groups details for current user (username, firstname, lastname, matchgroup)
$groups = $authDB->query("SELECT username, firstname, lastname, matchgroup FROM privilege WHERE firstname='_GROUP' and username IN (SELECT groupname FROM groupmember WHERE username = '$currentusername')");
$myi=0;
while($row = $authDB->dbfetch($groups)) {
//add group firstname and lastname to the filters list in case studies are assigned to groups
$userslist[$myi]['firstname']=$row['firstname'];
$userslist[$myi]['lastname']=$row['lastname'];
$groupname = $row['username'];
//if matchgroup = 1 then find all users related to the group, retreive their firstname, lastname
if ($row['matchgroup'] == '1') {
$usersfromgroup = $authDB->query("SELECT username, firstname, lastname, matchgroup FROM privilege WHERE username IN (SELECT username FROM groupmember WHERE groupname = '$groupname')");
//add all these users firstname and lastname to the filters list
while ($userrow = $authDB->dbfetch($usersfromgroup)) {
$myi = $myi + 1;
$userslist[$myi]['firstname']=$userrow['firstname'];
$userslist[$myi]['lastname']=$userrow['lastname'];
}
}
$myi = $myi + 1;
}
//remove duplicates in filters list
$userslist = array_map("unserialize",array_unique(array_map("serialize",$userslist)));
//apply additional filters by groups
foreach ($userslist as $additionaluser) {
$firstName = $additionaluser['firstname'];
$lastName = $additionaluser['lastname'];
$where .= " OR ";
$where .= "referringphysician LIKE '%$firstName%$lastName%'";
$where .= " OR ";
$where .= "referringphysician LIKE '%$lastName%$firstName%'";
$where .= " OR ";
$where .= "readingphysician LIKE '%$firstName%$lastName%'";
$where .= " OR ";
$where .= "readingphysician LIKE '%$lastName%$firstName%'";
}
//ending PACSONE group security
//close the query section
$where .= ")";
}
We don't really have a search API as all search related functions are implemented in the Search menu. Also, all source PHP scripts and database schema are distributed open-source along with the PacsOne Server installation packages, so please feel free to check them out if you have any questions about how the search functions are implemented.