Snapshot Feature

[zbig01]

Used to store non-encounter based structured medical data and track it over time.

This feature as currently implemented is used to track 8 psychosocial and behavioral issues or domains.

They are - Financial resource strain, Education, Stress, Depression, Physical activity, Alcohol use, Social connection and isolation and Exposure to violence - intimate partner violence.

These eight domains together provide a comprehensive picture of the patient that can facilitate care management and coordination.

Fulfills one of the requirements for 2015 Edition Health Information Technology (Health IT) Certification Criteria.

Present on the patient Medical Dashborad

Designed to add any number of additional snapshots

There are 5 scripts that make up this feature:
snapshot.php
snapshot_1_dates.php
snapshot_detail_1.php
snapshot_detail_1_add.php
and of course
snapshot_help.php :)

main page

Add button

Adding

After adding

Edit

Delete

Additional help

Expanded additional help

Help file :)

below added by bradymiller:
Up for Grabs demo for this PR: https://www.open-emr.org/wiki/index.php/Development_Demo#Beta_-_Up_For_Grabs_Demo

[bradymiller]

Up for Grabs demo for this PR is here:
https://www.open-emr.org/wiki/index.php/Development_Demo#Beta_-_Up_For_Grabs_Demo

[mdsupport]

@zbig01 Have you considered leveraging the "Track Anything" feature for this? Just added one of your tracks in the demo. It provides similar functionality with an advantage of being a generic feature.

We agree that it seems a design constraint to track patient data. But in inter-connected world we are moving to, encounter needs to be seen as Patient Related Interaction. From legal perspective it will always be prudent to record how/why any of the record updates were made. E.g. in your tracks, wouldn't it be important to record in EMR the source of information about patient's financial situation at the time of change?

In any case, in the current format this should be an optional feature. It may be worth exploring possibility of providing track templates as yml or use of layouts.

[adunsulag]

@zbig01 We've been getting questions for MU3 and as you mentioned this is one of the requirements to meet 2015 MU3. While it seems that you could use the track anything feature as @mdsupport mentions it is problematic when people need this functionality out of the box for MU3.

I'm trying to understand if this data really does need to be tied to an encounter. As we are looking at implementing FIHR an encounter would be treated as an 'Appointment' and any forms that are connected in our own internal system being treated as 'Observations'. Your snapshot data would also be treated as an Observation. Now the HL7 FIHR group does not require a connection between an Observation and an Appointment. Instead they are connected via the CarePlan or the Patient, so I'm not sure it's a core requirement for this data to be connected that way. Any thoughts @zbig01, @bradymiller , @mdsupport?

If people are wanting this to be an optional requirement I'd like to take a stab at turning this into a zend module that can be enabled / disabled. It'd be another example of using the system's Event Dispatcher to extend the functionality of the system. It also lets people enable this functionality if they want it for MU3, or leave it off if it's considered a hindrance.

[mdsupport]

Having gone through several careplan audits, we can definitely say whether users like or not, emr needs to track everything. This is probably wrong place for discussion but fast evolving reporting requirements need emr at core to record all patient related events and assign multiple attributes to it. Input scripts probably change little but reporting is completely different.
BTW: Appointment is just that, a reservation for providers time. It does not have much significance from care perspective other than a line in reports. Encounters on other hand are attributes for observations with clinician and patient as sources of information. Contrast that with receipt of hl7 data from a lab (for test someone else ordered) or better yet, series of blood pressure readings from patient's home machine. These are also observations with patient as source of information.

[adunsulag]

Goes to show I should avoid making comments early in the morning haha. Not sure what FHIR reference I was looking at but I must have missed the context parameter: http://hl7.org/fhir/STU3/observation-definitions.html#Observation.context Which as Encounter as one the valid attributes.

In the context of this feature, I'm trying to understand how this skirts around recording patient related events. It seems from what I'm seeing that the data is tied to the patient and being recorded as part of that patient data set. Going through your comment again, I guess you are wanting to be able to have an audit trail record saying that this observation was tied to this encounter between the clinician and patient?

What I was saying is that where MU3 is a requirement for a certified EMR there has to be a way of having a consistent (and hopefully) easy setup for clinicians to use OpenEMR. If we go with the generic 'Track Anything' implementation at least right now every clinician would have to go in and create the same evaluations for the 8 psychosocial issues being covered here. Maybe that is what you were meaning @mdsupport with yaml default files to auto-create these tracks?

Is it problematic to take this feature and let other's implement the encounter auditing piece? Or is @zbig01 going to do that work?

[stale]

This issue has been automatically marked as stale because it has not had any recent activity within the past 90 days. It will be closed in 7 days if no further activity occurs.

[bradymiller]

bump

[stephenwaite]

https://www.healthit.gov/test-method/social-psychological-and-behavioral-data#ccg

not part of base ehr definition

hopefully updated test procedures will be released soon

[stale]

This issue has been automatically marked as stale because it has not had any recent activity within the past 90 days. It will be closed in 7 days if no further activity occurs.

[tywrenn]

bump @bradymiller

[stale]

This issue has been automatically marked as stale because it has not had any recent activity within the past 90 days. It will be closed in 7 days if no further activity occurs.

[stale]

This issue has been automatically closed because it has not had any recent activity within the past 97 days.