Could someone post the requirement for this section?
Here’s the barometer containing the required items:
https://www.open-emr.org/wiki/index.php/OpenEMR_Certification_Stage_III_Meaningful_Use#Completion_Barometer
Ideal way to look into this is from here:
https://www.healthit.gov/topic/certification-ehrs/2015-edition-test-method
Which can follow link to:
https://www.healthit.gov/test-method/family-health-history
(Read the regulation text first, then the Standards referenced and then all the clarifications below that; then can check out the Testing Procedure tab, note this is self-attestation, but there is a archived testing link there to get more clues as to what is needed)
When I ran through this the solution seemed like “low” amount of work (I have of course forgotten what the solution would entail by this point 
). Rec checking it out and seeing what you think is missing and what elements are needed to get it up to regulation.
Thank, I will steal some time this coming week to look into this.
@brady.miller
According to the language on this page
I can attest that this is covered and does not have any changes to be made. As we get to decide how the first line relative information is designed. We can keep it as is and attest to the functionality being available.
hi @juggernautsei ,
Check out the paragraph near bottom of this link:
https://www.healthit.gov/test-method/family-health-history
Noted following issues from there:
ISSUE 1:
At a minimum, the health IT must enable a user to record, change, and access information about a patient’s first degree relative within the said patient’s record.
Agree we can argue that is fulfilled since we have the labels father, mother, siblings, offspring in history,
ISSUE 2:
Our intent with “familial concepts and expressions” is to focus on the first degree relative’s diagnosis. For testing and certification, at a minimum, a system must be able to demonstrate that it can record, change, and access this diagnosis and the familial relationship in a codified manner using SNOMED CT®. The developer has the flexibility to determine how the system will represent the codified familial relationship, pre- or post-coordinated.
This one I think will require that we map the family member relationship (father, mother, siblings, offspring) in layout_options (may need something like we do in list_options for storing mapped codes.)
-brady
Hi @juggernautsei ,
Probably wouldn’t make the user map this in the form and would map it in the layout_options table. Basically would work and look like the codes sql column in the list_options table where can map codes to it in the lists editor. Then can map the snomed code for the family member relation in the new codes column of the layout_options table (ie. the snomed codes for father, mother, sibling, and offspring).
I am looking into this.
1 Like
This seems like a low hanging fruit. How about :
- Since we do not want to use SNOMED fully, create a list that reflects the constructs codified by SNOMED. As an example, the
Patient Relativeslist should have following entries -
SNOMED:125677006 |Relative|
SNOMED:394854006 |Immediate family member|
SNOMED:67822003 |Child|
SNOMED:40683002 |Parent|
SNOMED:66839005 |Father|
SNOMED:72705000 |Mother|
SNOMED:375005 |Sibling|
SNOMED:127848009 |Spouse|
Using the SNOMED:xxx as key would permit accurate reporting if ever needed.
- Modify the current layout that hard-codes the relationships to a more flexible layout where maybe upto 10 items can be entered by selecting a specific relation from the list setup in prior step.
- Potentially, the content of
Relativestab can be added toFamily Historyas well by making another list of conditions a practice wants to track. Cancer,TB,Diabetes etc. would just be the starter values for practices to make their own.
1 Like
Now that I have completed the Weno new build. I will carve time out on the weekend to get this done. Unless @mdsupport is taking this on?
1 Like
@juggernautsei, Not taking this on, but wanted to share something I tried in demo. Idea was to allow patient to describe issues by person rather than current approach of description which does not lend itself for categorized reporting.
Best.
__
You can check the idea by importing this config.
temp.sql (28.0 KB)
1 Like