I am currently trying to figure out how to generate data with Nelmio Alice and Faker. Here is the model I need to fill:
Let's say we need to match persons and their insurance policies. One person can have only one active insurance policy at a given time. Each insurance policy belongs to a single person.
This means that all the insurance policies of one person must not overlap. So when generating the insurance policy entities I need some way to tell Alice to generate begin and end in such a way that the new object does not conflict with the already existing objects.
How would I go about doing that? From looking at the Alice documentation, I have only found that it is possible to make attributes of an object depend on other attributes of the same object, but not how to make them depend on attributes of objects that are already there.
Related
Hi I am new to graph database modeling and have some doubts about expressing an endorsment for a service provided by a Person. The use case is the following. PersonA gives Endorsement to a Service provided by PersonB.
The key point is that If I am recipient of the endorsment, I would like to know who has endorsed me. I have come up with several scenarios on how I could potentialy do that, but because of my lack of experience I have doubts on what would be the best aproach.
Scenario 1.
Endorsment is expressed direcly as a relationship and the service falls as a property under the endorsment So it will look like:
PersonA-------ENDORSE{service}--->PersonB
Scenario 2
I model an entity named Service. The problem is that when I do the relationship "ENDORSE" to service I would loose information on who am I endorsing. So I would have to keep a property in the relationship on who am I endorsing. Then the PersonB would AQUIRE endorsment for the SERVICE but he would not know who has actualy givern the endorsment. So..... it will look like this:
PERSONA----ENDORSE{personB}--->Service------ENDORSMENT{personA}--->PERSONB
Does this make sense ?
Scenario 3:
I normalize the second relationship "ENDORSMENT" and exclude the personA as a property , but than I need to query all Person to find out who have they endorsed.
How would you model this kind of relationship ?
Two important principles for validating a data model for a graph database:
if an entity or fact can be used more than once, then it should be stored
as the node
if the relationship of two nodes requires to store node
identifiers, then this relationship must be transformed into a node
So #Raj pointed the right way, in which case the model might look like this:
I recommend you read this:
https://neo4j.com/graph-databases-book/
http://patterns.dataincubator.org/book/
The second approach looks good, you don't have to add these properties on relationships.
It's possible to get person A who endorsed person B for service S.
The only issue with this is there will be multiple nodes for any service S. If that's not acceptable.
You can replace the Service node in the second approach with Endorse node E and connect this E to service node S.
So there will be four types of nodes.
EDIT:
Adding an image for clarification.
Rename REL1 and REL2 as you wish.
#Stdob suggested some good names for these relationships.
While working with the DICOM study, series and media concepts, I wondered if these values are to be unique over all data, or only to the patient they belong to.
Phrased otherwise; can I have 2 patients having a study/series/sop instance uid that is the same value for both patients?
Or does the DICOM standard simply doesn't care about that and is that open to the implementor to decide?
In DICOM, a Study (identified by its Study Instance UID) is always associated with a single Patient. See DICOM standard part 3 for details.
To answer your initial question/thought: a Unique Identifier (UID) has to be globally unique, i.e. world-wide over all patients, devices, hospitals, etc.
UID in DICOM (no matter what UID) is always globally unique. So, as you asked in question, uniqueness is not limited to Patient level or something.
Following is from specifications:
2017a Part 5 - Data Structures and Encoding (9 Unique Identifiers (UIDs))
Unique Identifiers (UIDs) provide the capability to uniquely identify a wide variety of items. They guarantee uniqueness across multiple countries, sites, vendors and equipment. Different classes of objects, instance of objects and information entities can be distinguished from one another across the DICOM universe of discourse irrespective of any semantic context.
More details about DICOM UID can be found in this answer.
Your comment on question as below:
My question was more about what to do in case I choose to clone a patient in my system and attach the same dicom(s) to it. Should I regenerate the dicom-uid's or could I keep them as-is.
I am not sure what you mean by "clone". While cloning, if there is change in dataset, you should regenerate the SOPInstance UID. Even if you simply apply lossy transfer syntax to your dataset, you should regenerate the SOPInstance UID. Any action that differentiates/separates the the datasets from original require new SOPInstance UID. So, while cloning, if you are changing patient demographics, new UID should be generated. Whether new StudyInstance UID should be generated or not depends upon what is changed.
OTOH, if you are just copying your dataset at different location, it is still same dataset. You do not need to regenerate UIDs in this case.
Unfortunately although the standard states the UID should be globally unique you can not guarantee it at the series level in my experience. I have come across series with duplicate ids across studies. To protect yourself assume you have to use StudyUID +SeriesUID to ensure a unique series key.
I need to create a Secondary Capture Image representing a report related to radiopharmaceutical and dose injected to the patient during the medical examination.
I know Secondary Capture Image is not the right choice to accomplish the task but that is what the customer requires.
Following are the steps I thought to implement for developing the feature and I would like to read some opinions or suggestion from the community.
Assumption: MWL is implemented and the Study Instance UID is generated in the RIS
query the MWL (C-FIND) to get the requested procedure object
parse the result to get the StudyInstanceUID and patient related
informations (name, sex, birthdate etc.)
query (C –FIND) the modality looking for the specific Study
Instance UID
parse the result to get the Series Instance UID
create the image setting the three mandatory attribute Study
Instance UID, Series Instance UID, Modality (together with some type
2 attributes I got querying MWL and modality in the previous
steps)
C-STORE to persist the image to the storage archive
Commit of the image (do I really need?)
I really appreciate comments opinions or someone that can address me to a more solid architecture.
correct
correct. Do not forget about attributes that are not so obvious like Admission ID, Accession Number, Referring Physicians Name and others.
The majority of modalities does not support Query/Retrieve as an SCP. If you would really need to query for the images, send the C-FIND to the PACS rather than the modality. The Study Instance UID comes with the worklist. Even if the UID you find by Query differs from that, I would strongly recommend to use the one from the worklist. However, I do not see any sense in using attributes from other sources than the MWL and your own "acquisition".
Why would you want to add the image to an existing series? It would probably be more appropriate to create a new one. There are a lot of reasons for that, e.g. Modality and vendor/equipment information are series level information and probably different.
There are more mandatory attributes for SC (e.g. in the general image module). Not all come from the MWL.
yes.
You do not have to. However, suppose that your images are lost:
a) you have received a storage commitment from the PACS -> blame on the PACS
b) you have not received a storage commitment from the PACS -> blame on ...? ;-)
I have an interesting situation. I am allowing users to provide their own data sources to be imported into neo4j. The data sources could be the same across different users, but I would like cypher queries to only query nodes and relations specified by a particular user's sources.
I can think of several ways to do this:
Separate neo4j instances for each user
Tag nodes and relationships by user
Currently node duplicates are prevented by indexes so I would have to alter that approach since nodes which already exist simply cause a new relationship to that node. Number of relationships to a node are used in my analysis so separating relationships by user are important.
I will have to update an existing graph database to account for these new attributes. I'm thinking that tagging relationships might be the way to go. Any thoughts pro/con against this approach? This way I can include the user tag as a relationship parameter.
Thoughts?
Henry
You can tag all your users with labels and use these even to tag the source:
http://docs.neo4j.org/chunked/preview/query-match.html#match-get-all-nodes-with-a-label
I have two different databases that are not connected in any way. In fact, one is a public school database and one is a hud (housing) database. By law they are not allowed to share names and other specific identifying addresses. Birthdates and addresses are okay - along with zip codes and other more general ids. The uses need to be able to query the other database to get non-specific information so it would appear that they need to share the same unique id. I was considering such things as using birthdates and perhaps initials of name or perhaps last 4 digits of ssn along with the birthdate. The client was thinking of global positioning data but I'm concerned about apartments next to one another or moving of families. Any ideas?
First you need to determine what will be your measure of uniqueness. If there are two people in either database with more than one entry for your measure of uniqueness, you need to change your strategy. After that, put a constraint on both databases constraining that these properties(Birthday, SSN) are what make a Person record unique.