I’m working with an online consultation system and we add data collected by the patient to our medical record.
Which from a provenance point we say the patient performed the measurement which seems correct.
However we write back data to a GP system so wondering what is the best option?
I’m thinking we create a user ‘Patient Entered Data’ and store the data that way.
Data has been checked by a clinician but they didn’t perform the observation.
We probably will have other ‘PHR’ data like this but this is probably a devices like withings, etc. We can probably handle that and the performer again is likely to be oatient.
I think this might be a question for your Clinical Safety Officer. Technically it would work but any automated systems (eg QOF alerts, templates etc) which trigger from entered data may not be able to differentiate between clinician users and the ‘Patient Entered Data’ user. Depending on what type of measurement it is, this could cause havoc.
What measurements are we talking about, and what’s the view of the CSO?
BP, weight, pulse, etc.
They are reviewed by a clinician before being added our records.
Was wondering how home monitoring works, they must be doing something like this (or just sending a pdf via email to GP’s)
In all the practices I’ve worked in, home monitoring is done by writing BP readings on a piece of paper and passing this in to the surgery, where someone calculates the average BP over the weekly readings, and this average BP is entered (usually with a code like ‘Average Home Blood Pressure Reading’) into the electronic record.
If the readings can be coded with some code that makes it clear that it’s a home reading then all the better. GP templates and protocols are not usually able to differentiate between Users but they will differentiate between different types of coded data.
The codes should be an Observable Entity as per the linked one 413606001 |Average home systolic blood pressure (observable entity)|
If the readings are being reviewed by a clinician before being added to the record then hopefully this will help filter out some of the more wacko readings.
I still think it’s something that should be in your DCB0129 Hazard Log and the CSO should have worked on the mitigations to this risk. I know it seems a bit jobsworthy, but imagine if you’re a GP and in your record there could be vital sign readings which (erroneous or not) require IMMEDIATE action - for example if someone records a BP of 250/140 - it could be erroneous, but it could be real - and the patient needs immediate admission. But this could happen in the middle of the night when you as the GP are not looking at readings being added. It’s scenarios like this which scare GPs as the data controller, risk-carrier, and clinician in charge… Eventually one of these will end up in court.
I need to come back to this, its looking far more complex and this is just start of the issues. I’ll add notes later on. (Short version is we have several ways of getting data into GP systems, most are document formats. Structured is possible but has issues as I’m seeing here)
Re BP.
That coding is down to the GP supplier system.
As we have a more complex model, the home provenance part of that code is replaced with device and patient provenance.
So we follow NHS Clinical Observations and use the normal BP code 72313002
How GP systems handle this should really be down to them and not our responsibility (it adds a high level of complexity on us to understand the data models in GP systems). Plus other GP suppliers and GP’s may want this recorded differently.
However I’ve mocked up the format for other suppliers and the problem goes away (as we have to convert to pdf/html) - Obviously we don’t want to use this format.
Yes it’s far from simple, and it’s certainly possible to inadvertently cause problems with the QOF alerts and other automated systems in GP systems - which would not make you popular.
A single BP performed at home by the patient is not in itself massively helpful in managing hypertension anyway. We are much more interested in average home BP, and for this we are of course happy with patient-taken, home readings.
What would be awesome is if your system can let the patient do a home BP diary over a week, then send the whole thing to us in one document at the end of the week, with all the BP values batched and formatted nicely and averaging the BPs for us. This would save some time for practice staff, so would be very helpful. We would only code and store the average BP.
I fully welcome this development, but as Marcus has pointed out even a simple measurement like BP can end up going down a rabbit hole.
Ideally any data coming into the EHR should have a validated snomed code that identifies it as a home/patient supplied reading and that it is vetted by somebody clinical, doesn’t have to be a GP. Bits of info from pts as attached documents just adds clutter to the EHR and means clicking in and out of different bits of information.
Look forward to see how this is developed
Slightly amused Observations entered into this recent topic Interoperability with open standards: let's kindle a discussion about FHIR | Digital Health
If we combine threads we’ve got Observations being recorded as:
- record provenance and event = e.g. SNOMED coding with home provenance and the BP event. (e.g. TPP version or is this also EMIS?). Model is roughly HL7 v2 (believe this was behind the original EMIS model)
- Non GP EPR e.g. community or PHR- following FHIR. Code is again SNOMED but base event type but provenance is in the model (HL7 FHIR leans more to model to differentiate Obs)
- openEHR - code is probably SNOMED, model probably includes FHIR model and adds some extra bits. Do you get a different archetype per observation?
So it does sound like some mapping is required. Tending to lean on the ideal solution being GP systems accepting FHIR and they do the code conversions - it won’t be practical to get all suppliers of data mapping to home BP code, don’t think it’s robust.
I will question our use of BP with our clinicians.
I’m wondering about this also.
Writing back data just seems to be a total mare. If possible I would prefer allowing GP Systems to access our openAPI and pull in data as required. I think that is going to be a lot easier and I believe some other suppliers in our sector have the same capability (using the same openAPi)
