FHIR Chat · Connectathon 24 · patient empowerment

Stream: patient empowerment

Topic: Connectathon 24


view this post on Zulip Mikael Rinnetmäki (Apr 30 2020 at 15:33):

Ah, what a task it is for a newcomer to HL7 FHIR to browse through all the tracks and find out what they are about! I just did that.

I wanted to share my notes with the Patient Empowerment Work Group, as some of you may be in a similar situation as I was in, and appreciate something like this being available. Take a look at https://docs.google.com/document/d/16M5OdFmde_9IUPRneCGwcrpzEuPyl3yqyJszyUONIGA/edit?usp=sharing. The document lists the Connectathon tracks and my views and guesses on how the Patient Empowerment Work Group could potentially get involved.

view this post on Zulip Mikael Rinnetmäki (Apr 30 2020 at 15:35):

Please note that I did this first for myself, and from my own perspective. Most notably, due to lack of time, I did not get into details of the tracks that seemed too US specific for me. I would still find it really valuable if someone could outline the contents of (some of) those tracks in "plain English".

view this post on Zulip Lloyd McKenzie (Apr 30 2020 at 15:42):

@Sandra Vance Something for us to perhaps consider for next round - a high-level "newbie" description of the purpose and objectives of the track before we jump into the gnarly details of the scenarios?

view this post on Zulip Sandy Vance (Apr 30 2020 at 15:57):

Lloyd McKenzie said:

Sandra Vance Something for us to perhaps consider for next round - a high-level "newbie" description of the purpose and objectives of the track before we jump into the gnarly details of the scenarios?

DO you mean for the track orientation template??

view this post on Zulip Mikael Rinnetmäki (Apr 30 2020 at 15:58):

I would have appreciated a separate page from the Connectathon main page, including a short, newbie-friendly description of what each track is about.

view this post on Zulip Mikael Rinnetmäki (Apr 30 2020 at 16:00):

Right now some of the tracks were quite well documented, some others less so (at least from the newbie point-of-view, and it took a while to dig though to get an idea of the contents.

view this post on Zulip Mikael Rinnetmäki (Apr 30 2020 at 16:00):

Even for the well documented tracks, there was quite a bit of clicking to go through them.

view this post on Zulip Mikael Rinnetmäki (Apr 30 2020 at 16:02):

I do understand it might be difficult to describe each track from each possible perspective. :) But a paragraph in the template "Short description for outsiders", which could then potentially extracted to a separate page?

view this post on Zulip Virginia Lorenzi (May 12 2020 at 22:05):

Zoom Info for each track: https://confluence.hl7.org/display/FHIR/2020-05+Zoom+Info+for+Each+Track

I know several were interested in this: SDOHCC and Care Coordination Connectathon 24 Schedule:
https://docs.google.com/spreadsheets/d/1hFmq2jvEwxLabb0dy3B09dZkwkDirfxH7XpYcR15Qpc/edit#gid=0

view this post on Zulip Terrie Reed (May 13 2020 at 13:39):

Checking in with the group to say that I've reached out to leadership of Bulk Data, SANER and Collaboration for Ophthalmic Care Tracks. I would like to spend time with Collaboration group but they will be woking mostly in Australia. I am anticipating I will spend most of my time with SANER. Should we be reporting in here to this stream as we learn of something interesting or have questions during a track?

view this post on Zulip John Moehrke (May 13 2020 at 14:40):

I too am working inside SANER. although my role is as testing, so might not always take that hat off and put the patient hat on.. so good to have another set of eyes. Note that SANER is got no patient interaction, doesn't mean there is no patient impact.

view this post on Zulip Terrie Reed (May 13 2020 at 15:33):

Thanks John. It's good you will be there to test. Maybe I can sneak you questions on the side! I will be looking for indirect patient impact. I am an expert on medical device reporting so I would like it to be included in the response. We certainly have seen the gaps in device tracking and the impact on patient care in the last few months.

view this post on Zulip John Moehrke (May 13 2020 at 15:41):

device tracking is not part of the use-cases SANER is addressing.

view this post on Zulip Terrie Reed (May 13 2020 at 15:43):

John,
I know but I want to understand what you are doing for future work.
Are you counting ventilators or beds as part of the reporting?
Also, is there a SANER confluence page or Zulip Stream?

view this post on Zulip John Moehrke (May 13 2020 at 15:43):

yes the supply of ventilators and beds is in scope

view this post on Zulip John Moehrke (May 13 2020 at 15:44):

the scope is the COVID-19 reports to the CDC and also FMEA

view this post on Zulip John Moehrke (May 13 2020 at 15:44):

all summary data about the location capability

view this post on Zulip Terrie Reed (May 13 2020 at 16:33):

ok. Great. Ventilators have UDIs that could be scanned for the reporting. Future use case !

view this post on Zulip John Moehrke (May 13 2020 at 16:41):

the reports are just counts. Not inventory

view this post on Zulip Terrie Reed (May 13 2020 at 17:03):

I know.

view this post on Zulip Virginia Lorenzi (May 13 2020 at 21:25):

Yes please report here! Good!

view this post on Zulip Virginia Lorenzi (May 13 2020 at 21:37):

I am starting out on questionaire track and Mikael is here as well. Things I learned (perhaps relearned because I am old):
-there is a Patient Reported Outcomes implementation guide that uses the FHIR resources questionaire and questionaire response: http://hl7.org/fhir/us/patient-reported-outcomes/2018Sep/index.html

  • questionaires have pretty fancy capabilities like conditional questions, etc.
  • key implementation guide is SDC - structured data capture
  • there will be specific presentations on the questionaire zoom onhttps://zoom.us/j/6192821589
    Planned Break-out sessions so far (from https://docs.google.com/spreadsheets/d/1YhFovZNNTABeNeBCKH8JUc5CKAnRp7Mo9mlZzH2D8UQ/edit#gid=0)
    Time URL Description
    Wed: 5:30pm Eastern Compositional Questionnaires
    Thur: 10:30-12 Eastern Intro to SDC
    Fri: 10:30-12 Eastern Overview of various form builders & renderers
    Thur: 5:00pm Eastern Regular SDC call

view this post on Zulip Virginia Lorenzi (May 13 2020 at 21:42):

In the main kickoff session, learned that the gotowebinar will be open the whole time, has some general education and announcements scheduled to take place there as well as track report outs Tracks are signing up for track report out times not all have yet.
Here is the main gotowebinar schedule: https://docs.google.com/spreadsheets/d/1P4EPT2Hi3PI9eB-TYPj5xYHzInZS4ixd/edit#gid=1512697744

view this post on Zulip Virginia Lorenzi (May 13 2020 at 21:45):

We will be holding our regular conference call but postponing one hour: May 14th, 2020, 2PM Eastern.
Web Meeting Info
https://global.gotomeeting.com/join/322275573

You can also dial in using your phone.
United States: +1 (872) 240-3212

Access Code: 322-275-573

New to GoToMeeting? Get the app now and be ready when your first meeting starts:
https://global.gotomeeting.com/install/322275573

view this post on Zulip Terrie Reed (May 14 2020 at 21:16):

Wanted to share with the group that the SANER Virtual Tour that happened at 3pm today (right after our patient empowerment call) was really helpful to make their goals clear. My take on it is that they are trying to get together as many IT partners as possible to collaborate on collecting and transmitting the data coming from various internal applications so that this can be reported once (via FHIR?) to many public health agencies. I know requirements to report the same information multiple times has been a burden on hospitals for a long time so I'm glad to see this is happening. As I mentioned on the call, hospital procurement/supply chain is missing from the connectathon but, one of my takeaways is to reach out and advocate for them to join this work. Patient perspective is what Virginia mentioned on our call - if the numbers generated here are accurate, then it will help supply chain, biomedical engineering and clinical teams to have the resources needed to treat patients more effectively.

view this post on Zulip Dave deBronkart (May 14 2020 at 21:18):

Thanks! Would this be of value for certain of us to listen to, if it was recorded, or did you pretty much sum it up?

view this post on Zulip Virginia Lorenzi (May 14 2020 at 21:55):

#Vital Signs I think this track is interesting to patient empowerment. Their scenario includes patient obtained vital sign measurements being sent from patient to clinician. In addition, I think that app developers have expressed frustration in the different ways each ehr vendor represents vital sign details.

view this post on Zulip Grahame Grieve (May 14 2020 at 22:03):

amen. but it's also institutionally dependent which is a bigger mountain to climb. Since what hospital is going to change the way they record vital signs to make patients happy?

view this post on Zulip Dave deBronkart (May 15 2020 at 10:25):

I'm surprised to hear that FHIR doesn't have a normalized way to express vital signs. Wouldn't that be a show-stopper? I don't know any details but in my ignorance I'd hope there could at LEAST be some sort of transform to a norm for incoming data.

@Virginia Lorenzi by app developers, do you mean the developers of personal health apps and device apps, like Apple heart rate data vs the HR data from an Omron blood pressure cuff or a Fitbit?

view this post on Zulip Dave deBronkart (May 15 2020 at 10:34):

Going back two weeks ago: (Maybe you will require that I post this in a Confluence document or blog post)

Lloyd McKenzie said:

Sandra Vance Something for us to perhaps consider for next round - a high-level "newbie" description of the purpose and objectives of the track before we jump into the gnarly details of the scenarios?

YES!

Having said that, though, we'd have to think it through, because while "orientation for newbies" is good for growing participation ("democratizing"), the last thing I'd want to do is get in the way of people who are working hard to get things done. My impression is that HL7 is very much about getting things done.

Perhaps we'll develop some method or template a track can apply when it gets to a point where it wants to invite the world, or when the world comes knocking - but I wouldn't mandate that every track must do this. (Except, I do firmly believe there's no excuse to not have at LEAST a one-sentence description so that earnest browsers have SOME clue whether they should be interested.)

Socialization / explaining is real work (I've made a career out of it), so it must be budgeted for, with time or funds. My opinion is that in cases where HL7 wants strategically to broaden the public usefulness and usability of its work products, then this is something worth talking about. The discussion will require thinking thoughtfully (if you know what I mean), for some time.

view this post on Zulip John Moehrke (May 15 2020 at 12:38):

dave, there are implementation guides that do nail down vital signs. It is in implementation guides where these kind of constraints properly exist. US-Core is the usa example of this. And basic vital signs are already regulated in this US-Core form.

view this post on Zulip John Moehrke (May 15 2020 at 12:44):

on the readability of implementation guides... as we learn of good templating, we impose it. This was done by the security workgroup two years ago, when we required a Security Considerations section. I have recommended other sections, but mandates are hard to ( a ) get agreement on what the mandate means, ( b ) get agreement that it is needed in all cases, and ( c ) policing that it happens. Everyone should already be required to explain the "problem this specification is addressing", but often times even that is not said at all, as there are often specificaitons that just define their solution to an unmentioned problem... the method for stopping this, is your power as an HL7 member to submit ballot comments demanding that they explain the patient perspective. Then socialize that ballot comment to the others in the patient empowerment workgroup, they will likely agree and add their own constructive comment (vote = negative). And change happens

view this post on Zulip John Moehrke (May 15 2020 at 12:46):

emphasis: the method for changing this, is your power as an HL7 member to submit ballot comments demanding (vote=negative) that they explain the patient perspective. Then socialize that ballot comment to the others in the patient empowerment workgroup, they will likely agree and add their own constructive comment (vote = negative). And change happens

view this post on Zulip Lloyd McKenzie (May 15 2020 at 13:23):

FHIR does have a normalized way to express vital signs - at least the basic information. It's one of the few places in the spec where we mandate specific codes and the only place where we mandate units of measure at the 'international' level. - So it would be best to ask what was meant by 'normalized'. (We don't try to standardize things like cuff size, sitting or standing, type of thermometer, etc.)

view this post on Zulip Dave deBronkart (May 15 2020 at 16:25):

John Moehrke said:

dave, there are implementation guides that do nail down vital signs. It is in implementation guides where these kind of constraints properly exist.

Well then I'm puzzled because @Virginia Lorenzi said " I think that app developers have expressed frustration in the different ways each ehr vendor represents vital sign details" and @Grahame Grieve said " Since what hospital is going to change the way they record vital signs to make patients happy?"

view this post on Zulip Lloyd McKenzie (May 15 2020 at 16:42):

There's a difference between FHIR defining a standard and systems using it?

view this post on Zulip John Moehrke (May 15 2020 at 16:53):

what lloyd said....

view this post on Zulip John Moehrke (May 15 2020 at 16:54):

AND, many device vendors and app developers are not yet looking to FHIR or US-Core. Many statements you see like that are from their historic experience (and from some providers that have not yet rolled out FHIR based api.)

view this post on Zulip John Moehrke (May 15 2020 at 16:55):

in theory, there is no difference between theory and reality, in reality there is

view this post on Zulip John Moehrke (May 15 2020 at 16:57):

standards development tends to take a few years to come to the definition of a standard (US-Core took 8 years to be published for FHIR R4). It takes minimum of 5 years for a standard to be widely implemented in the real-world.

view this post on Zulip John Moehrke (May 15 2020 at 16:58):

Right? Give us the statistics on PostScript standard?

view this post on Zulip Dave deBronkart (May 15 2020 at 17:13):

John Moehrke said:

Right? Give us the statistics on PostScript standard?

Funny you should mention that. It was a real can of worms, complicated by the fact that Adobe (sole author of the standard) put hidden secret stuff in its own implementation that it wouldn't disclose, some of which didn't conform to the spec but became the de facto standard.

The power dynamic there, btw, is that Adobe / Apple / Aldus (Pagemaker) became what people used, and thus became the behavior that people expected clones to replicate. There was a black art in conforming to Adobe RIP behavior which was not just the spec.

view this post on Zulip Dave deBronkart (May 15 2020 at 17:16):

John Moehrke said:

standards development tends to take a few years to come to the definition of a standard (US-Core took 8 years to be published for FHIR R4). It takes minimum of 5 years for a standard to be widely implemented in the real-world.

Perhaps my disconnect in this sub-thread is that "app developers expressed frustration" shows that those app developers aren't savvy about what it takes to transform those different formats into a normalized one?

view this post on Zulip Dave deBronkart (May 15 2020 at 17:26):

Dave deBronkart said:

John Moehrke said:

Right? Give us the statistics on PostScript standard?

Funny you should mention that. It was a real can of worms, complicated by the fact that Adobe (sole author of the standard) put hidden secret stuff in its own implementation that it wouldn't disclose, some of which didn't conform to the spec but became the de facto standard.

And BOY am I sparing y'all a PILE of stories. There were some mighty frustrated people trying to conform to all that "warts and all" stuff, culminating in 1991 with Apple & Microsoft ganging up on Adobe over the "Type 3" vs "Type 1" font format (they created Royal, which went on to become TrueType), ultimately leading to the spectacle of John Warnock in tears on stage about the tragedy of his (secret) beautiful format not being adopted regardless of price. From this 2010 interview:

at the last minute, Apple proposed that Microsoft adopt its TrueType format and font library. By itself, Apple would have a hard time establishing a standard. But, together Apple and MS could establish an alternative standard. Common fonts and font technology on Macs and PCs. Adobe frozen out. That made sense to Microsoft.

Bill announced the deal at Seybold Seminars San Francisco. Adobe was completely blind-sided. This was devastating. Not only did the Apple/Microsoft deal threaten Adobe’s business model, it meant that typography—something very precious to John Warnock—would be in the hands of people he considered to be philistines.

Okay, enough... I told you I'm sparing tons of dirty details about graphic arts standards...

view this post on Zulip Dave deBronkart (May 15 2020 at 17:28):

Lloyd McKenzie said:

There's a difference between FHIR defining a standard and systems using it?

Yeahbut I figured perhaps naively that people who come to a connectathon about standard X would be wanting to USE standard X

Or maybe that is true but they still grumble about what it takes. (In essence, THEY may grumble about "You mean other people aren't already doing this?? It would make it SO much easier for ME to adopt, if everyone else already had")

view this post on Zulip Lloyd McKenzie (May 15 2020 at 18:00):

I didn't hear the grumbling, so I can't say for sure :)

view this post on Zulip Virginia Lorenzi (May 15 2020 at 22:31):

I was specifically talking about the fhir experience. In fhir implementations, I see this as an issue.

view this post on Zulip Virginia Lorenzi (May 15 2020 at 22:35):

Some other patient facing stuff I got out of these two days: PACIO included patient reported outcomes - questionaire. Gravity had numerous patient actors. Had need for a more person centered care plan. Virtual connectathon more attainable for patient participants and less intimidating to lurk. - lurking more effective too. Need a bit more help getting around but I think we figured it out OK. Was also nice to have presence on track(s).

view this post on Zulip Terrie Reed (May 18 2020 at 15:33):

Some quick feedback that I will put in the survey. I enjoyed participating virtually. I thought the organizers and team leaders did a great job having a Central ongoing webinar and individual zoom meetings for track leads. I was also grateful for this Zulip stream and the Zulip streams for Bulk Data and COVID-19 response. As an observer, I could check Zulip and the main schedule to know check in times for the two groups I was following (Bulk Data and SANER), could lurk and comment on conversations and could take educational sessions and see group presentations as needed. I think I got more value from this meeting than I would have in a physical experience given how dizzying it can be to attend any conference with multiple tracks.

Bulk Data - agree in need to monitor this group for impacts on consent and patient privacy - how to monitor groups that create implementation guides for specific use cases?
SANER - would be interested in debriefing on our patient empowerment call. I know that the specific case is for today's emergent situation. Seems like more discussion needed an opportunity for applying FHIR to systems within the hospitals that are not EHRs (e.g. ERP systems, internal monitoring) but have significant impact on information to ensure patient safety.

view this post on Zulip Virginia Lorenzi (May 19 2020 at 20:32):

Grahame Grieve said:

amen. but it's also institutionally dependent which is a bigger mountain to climb. Since what hospital is going to change the way they record vital signs to make patients happy?

@Debi Willis @Michele Mottini have you guys seen provider variances? I thought it was just the EHRs. Thinking US with Argonaut/US Core

view this post on Zulip Jenni Syed (May 19 2020 at 21:21):

Note that the vital signs profiles go well beyond the international profile that is in FHIR Core. EG: the core international profile allows for weight in kg, lb, g (and eventually oz) and the vitals profile restricts that further to kg. It also requires some specialized extensions and breaking up of a pre coordinated code to post coordinated.

view this post on Zulip Jenni Syed (May 19 2020 at 21:21):

Would be interested in the provider variance as well.

view this post on Zulip Michele Mottini (May 19 2020 at 22:58):

Don't have an easy way to analyze all the data we have - and we most definitely do not try to validate it against the vital signs profile when we import it.

view this post on Zulip Michele Mottini (May 19 2020 at 22:59):

Eyeballing some cases I can see respiratory rate with a unit br/min (instead of /min)

view this post on Zulip Michele Mottini (May 19 2020 at 23:00):

Blood pressure without a unit (not 100% that this is due to the data though)

view this post on Zulip Michele Mottini (May 19 2020 at 23:05):

(^ these two are from EAMC - Cerner)

view this post on Zulip Michele Mottini (May 19 2020 at 23:13):

Looked at one each of MEDITECH, NextGen, eCW, did not see anything out of line

view this post on Zulip Michele Mottini (May 19 2020 at 23:14):

..and one Epic, same

view this post on Zulip Jenni Syed (May 20 2020 at 13:16):

@Michele Mottini for the br/min is it that or {br}/min? Which is another question... are the annotations allowed since those don't affect computation in ucum?

view this post on Zulip Jenni Syed (May 20 2020 at 13:27):

If you can send me some x-request-ids in PM or email I can log something to investigate

view this post on Zulip Jenni Syed (May 20 2020 at 13:27):

or whatever info you can provide/if you have other info to try to pin down some of the source data :)

view this post on Zulip Michele Mottini (May 20 2020 at 13:51):

@Jenni Syed : the unit code is {Breaths}/min, the unit name is br/min

view this post on Zulip Jenni Syed (May 20 2020 at 13:56):

Ok, I may get clarification on if the annotations are allowed or not...

view this post on Zulip Josh Mandel (May 20 2020 at 13:57):

My "pure" take is that they should be allowed. They don't change the meaning... I think we don't have an easy way to express this in a FHIR valueset though :-)

view this post on Zulip Jenni Syed (May 20 2020 at 14:25):

That's what I would expect as well but it's not called out either way that I can see - asked over here since we already had an ongoing vitals unit conversation: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Core.20vitals.20Units

view this post on Zulip Lloyd McKenzie (May 20 2020 at 15:01):

It's very hard to express a value set that allows arbitrary bracketed content. It also makes life harder for the apps trying to match on the units. Given that the 'code' is for computation, not display, why are we injecting that complexity?

view this post on Zulip Debi Willis (May 20 2020 at 15:02):

Hey @Virginia Lorenzi . I am coming to the conversation late so not sure if i completely understand the question. I do know some EHRs have multiple choice on which units to use and the provider makes that choice when they enter the data. Where it becomes really confusing for a patient is when they are pulling their data from multiple sources and those sources use different units. For example, if one provider gives me my weight in pounds and another gives me my weight in kilograms, it is really difficult to view trends. I was also really surprised to see how many systems use kilograms for weight in the US.

view this post on Zulip Jenni Syed (May 20 2020 at 15:08):

@Lloyd McKenzie the argument I usually get from my terminologists is that you should try to be as precise as you can to still be accurate with codes

view this post on Zulip Jenni Syed (May 20 2020 at 15:08):

ucum is a bit different than most terminologies though with the annotation concept

view this post on Zulip Lloyd McKenzie (May 20 2020 at 15:23):

Annotations have no meaning - so there's no increased "accuracy" when you specify them.

view this post on Zulip Lloyd McKenzie (May 20 2020 at 15:24):

They're there to make the humans happy - but we have Quantity.unit for that purpose.

view this post on Zulip Bart Carlson (May 20 2020 at 15:37):

When we talk about the idiosyncrasies of the data across all the different EHR systems used by different providers and the challenges this presents to patients who are trying to aggregate and understand their clinical data via a variety of apps and/or desktops/laptops aren't we really talking about the need to normalize the data?


Last updated: Apr 12 2022 at 19:14 UTC