...
- Feature to add/edit Relationships via FormEntry module using HL7 NK1 segments. -Brian
- We need more larger Projects /wiki/spaces/AR/pages/18515682 -Ben
- Retiring or deactivating of users? See #1725.
...
- Relationships via FormEntry
- Does the xslt make multiple hl7 messages from the formentry xml? -Darius
- It does not have to, nk1 segments are part of the R01 message (like a PID and PV1)
- Background: We need to create/update relationships through infopath forms
- Formentry module needs a place for the relationships
- The r01 parser in core needs to recognize this and create relationships
- Hl7 has "suggested" codes (not required) for nk1 segments
- We are proposing adding two 3 digit columns to relationship_type: aIsToBNk1 and bIsToANk1
- Sec 3.4.5 of hl7 manual, the length of seq 3 (relationship) the length is 250 -Darius
- Darius suggests using a fully specified name
- Ben says that only works within openmrs, not for sending or receiving outside hl7
- The nk1 is a triplet ID^NAME^CODE
- Paul proposes we use relationship_type_id instead of the aIsToBNK1, etc
- The proposal for the triplet is relationship_type_id^name^99REL
- But there are two sides to a relationship, so relationship_type_id
- Brian is concerned about two openmrs instances trying to send messages...the relationship_type_ids are different. If we used hl7 codes, then they could line them up beforehand
- Darius points out that we need a ConceptMap/ConceptSource for all objects
- Burke asks if this is an imagined or real need
- Darius would need it for datatypes, etc
- The nk1 code needs to be relationship_type_ida^name^99REL or relationship_type_idb^name^99REL e.g. 1a^Child^99REL or 1b^Parent^99REL
- The text portion can be either just one side of the relationship, both relationships, or some other random text. That decision is left up to the author
- The two columns are not needed with this solution
- How to put the person in there? person_id? identifier?
- nk133 has "identifier" and is a cx. It can have internal id, then patient identifiers if exists
- Remote formentry will need to be modified as well
- Paul: Should nk1's be creating new people? Should we have another hl7 message?
- Yes, nk1s have all the info needed for creating a person is in there
- The relationship lookup widget should create the person stub in the database. This allows the uuid and person_id to be created. When a second child comes along (with the same
- Does the xslt make multiple hl7 messages from the formentry xml? -Darius
- TODO: Ben: The remoteformentry preparsing should preserve the uuid of the patient that was created remotely
- We have several inquiries for projects based on openmrs for thesis'
- We need to have several big projects on the Projects /wiki/spaces/AR/pages/18515682 page
- We need a place for just putting project ideas or suggestions. Perhaps the Talk__Projects page is best. This will just be for one
- Should users be retirable instead of voidable?
- Retired means "this was valid up until a certain time". Voided means "this was never valid". According to this, the Users should be 'retired'
- Should users have an "active" flag to allow logging in?
- Should this just be a module?
- Paul: Someone should be able to be inactive but not retired.
- Darius: If retired is not meant to be used for "this user is suspended for a while", then 'retired' is not needed.
- Burke: active vs inactive is more about a lockout from being able to be logged in
- Darius doesn't like having both retired and a status/active flag
- TODO: Burke will create a ticket for changing users.voided to users.retired (Done: archive:TRAC-1725@ticket)
- TODO: Mike will make a ticket for creating a module to control user's creating their own accounts