Centralized data front end.accdb Change Request: Difference between revisions

m Text replacement - "[[Category: " to "[[Category:"
 
(245 intermediate revisions by 4 users not shown)
Line 1: Line 1:
''see the [[:Category: Development Documentation | Development Documentation Category]] for other development logs''
''see the [[:Category: Development Documentation | Development Documentation Category]] for other development logs''


This article contains requested changes for [[Centralized data front end.mdb]]. See [[Centralized data front end.mdb Change Log]] for it's change log.
This article contains requested changes for [[Centralized data front end.accdb]]. See [[Centralized data front end.accdb Change Log]] for it's change log.


== Requested Changes ==
<big>'''Generally items should be discussed and flagged for change on their own page, and not here. Only changes that don't have wiki pages yet should be listed here.'''</big>
Confirm [[Date_of_Birth#Age]] is right. Ttenbergen 12:18, 2014 January 13 (CST)


=== automate re-linking of tables ===
==New change request==
Ask for the phi and centralized directories and reconnect.
<big>'''Generally items should be discussed and flagged for change on their own page, and not here. Only changes that don't have wiki pages yet should be listed here.'''</big>


=== Error Checking Queries required ===
{{Todo
we should probably revisit [[:Category:Cleaner.mdb Data Integrity Checks‏‎]] in this context. 
| who = Tina
| todo_added = 2021-07-15 
| todo_action =  
| question = _dev_CFE
* CCI and ICD10 make button for Pagasa}}


=== SAS Views ===
=== Move Linked Pairs ===
* implement [[Created Variables in TMSX or Med TMS]]
{{Todo
| who = Tina
| todo_added = 2021-07-15 
| todo_action =
| question =  _dev_CFE
* Linked pairs, better storage }}
As discussed with Julie to prevent her having to rerun it and to insure that what Pagasa queries against is same as what Julie uses.
* need to change the query and process from one that re-does all, every time, to one that only updates new.
** How will that work for individual older records that were edited?


=== Automate PseudoPHINs ===
== Related articles ==
As per email from Julie Mon 2013/Mar/18 15:27:
{{Related Articles}}
1. first search the database for that patient
2. if she finds a match in  patient name and DOB  and found out that the patient has  already been assigned with a pseudo phin, she uses the same pseudo phin.  If she finds that there was a PHIN instead of pseudoPHIN, she checked in other sources –KEAH / MB Health/ TISS addressograph to verify if indeed correct and then decide whether to use that PHIN.
3. If she can’t find a match, she assigns the next pseudo PHIN number in her booklet to that patient. 


Propose we integrate this with the "PHIN Blank" check we are working out as part of [[Query for centralized‎]]. If blank PHIN is found, check if the name/dob/chart match elsewhere. If so, use that PHIN. If not, find highest previous Pseudo-PHIN and assign x+1.
[[Category:Development Documentation]]
This would mean that "blank PHIN" should be the first check applied so that all others don't trigger for this. Also, since the assignment of a new PHIN is a known and frequent process, this would likely benefit from automation. Any thoughts? Ttenbergen 12:45, 2014 January 13 (CST) {{discussion}}
[[Category:2013 data upgrades]]
 
[[Category:Centralized data front end.accdb]]
==== column headers ====
Variables headers for Registry, APACHE,SAPS, ADL elements – you may not necessarily make them in separate tables to be consistent with Ed’s output tables.    Putting them together as in the L_Log but using  the same headers as ED’s ( can be called as L_log of front end) are just fine.  This will be less work  in my end because I don’t need to merge these individual tables together.   
 
==== Data formats ====
Data type/values  for VERBAL, CHRONIC , ADMIT TYPE , RENAL, ADL -  these need conversion as we had agreed and they are included  under the L_Log of Front end.
 
 
[[Category: Development Documentation]]
[[category:2013 data upgrades]]