Stream: patient empowerment
Topic: HL7 PHR-S Functional Model
John Moehrke (Jan 13 2020 at 20:46):
We should review the HL7 defined PHR-S FM -- Personal Health Record System Functional Model -- https://www.hl7.org/implement/standards/product_brief.cfm?product_id=88
Abbie Watson (Jan 13 2020 at 21:34):
Heh... this is like 200+ pages of PHR specs. Amazing. And wow... really, really interesting to see the names credited on this documents. And how many people were digging into this issue 5 years ago. Ah, this is perfect.
Abbie Watson (Jan 13 2020 at 21:47):
So, my first thought is that we ought to clone the Functions tab in the excel spreadsheet, and create separate tables for the SHALL functions and the SHOULD functions. My second thought is to ask the following question: how much of the SHALL functionality is currently supported by the FHIR spec? What's the surface area overlap? And what's the differential that's missing? Sort of driving towards the idea of a 'PHR-S FM on FHIR' interpretation of this document.
John Moehrke (Jan 13 2020 at 21:54):
I think we need to test the PHR-S FM first among ourselves... as it is unclear to me who was involved in reviewing this work when it was ballotted. It might be perfect, slightly-off, or totally missing.
John Moehrke (Jan 13 2020 at 21:55):
I agree that there are functionality that are built into FHIR.. but wouldn't the PHR product still need to expose that before it gets a passing grade? Or is your thinking that we use these gaps as opportunities to improve the FHIR spec?
Josh Mandel (Jan 13 2020 at 21:57):
Was the functional model built based on existing PHR implementations?
John Moehrke (Jan 13 2020 at 21:57):
this Functional Model concept was first designed to drive standard functions into EHR... but people then realized it could be used for PHR. Here is the whole list of types of systems derived from the same model https://www.hl7.org/implement/standards/product_brief.cfm?product_id=269
John Moehrke (Jan 13 2020 at 21:58):
Was the functional model built based on existing PHR implementations?
Good question... I wonder if we could get @Gary Dickinson to comment. He drove most of this. (I added him to this stream)
Josh Mandel (Jan 13 2020 at 21:58):
I see a list of target system types, but I was interested in whether the model itself reflects real-world system design
John Moehrke (Jan 13 2020 at 21:58):
I think it was intended to represent 'best case'
Josh Mandel (Jan 13 2020 at 21:59):
Ok. I just want to call out that this sounds a bit different than how we drive most design in FHIR.
John Moehrke (Jan 13 2020 at 22:01):
yes, this is a Functional-Model
John Moehrke (Jan 13 2020 at 22:01):
and yes that is a different kind of standard...
Lloyd McKenzie (Jan 13 2020 at 22:10):
Because of that different approach, the functional models haven't necessarily seen as much daylight (or had as much influence) as some of the other specifications we've put out. There's actually an IG that maps a bunch of the EHR functional model stuff to Provenance and AuditEvent, but few if anyone has looked at it, and I don't know of anyone who's implemented it.
Abbie Watson (Jan 13 2020 at 22:19):
Yes, I'm thinking the gaps are opportunities to improve the FHIR spec. Or rather, I suspect the differential will result in a concrete bit of functionality that's similar in scope to SMART on FHIR... but focused around PHRs.
Abbie Watson (Jan 13 2020 at 22:19):
(deleted)
John Ritter (Jan 15 2020 at 05:50):
No, the PHR System Functional Model was not intended to represent the "best case". Rather, it was intended to envision (and accommodate) "all cases" -- both functionally, and architecturally (that is, irrespective of any given architecture -- past, present, or future) .
John Ritter (Jan 15 2020 at 06:11):
The PHR System Functional Model authors examined all types of PHR systems (and approaches) worldwide and generalized (and normalized) the various approaches. Those functions that appeared in all systems were deemed to be at the "SHALL" level of necessity. Those functions that appeared in some systems were either deemed to be at the "SHOULD" or "MAY" level of necessity. To be specific as to the question, a conformance criteria could only be designated as a "SHALL" if it was capable of being implemented "now"; and there is at least one SHALL in the PHR-S FM. For example, the statement: "The PHR-S SHALL capture the PHR Account Holder's demographic information" conveyed the notion that at least one PHR system in the world was already capable of capturing demographic data -- and that any system that hoped to claim to be a PHR system needed to be able to capture demographic data about the PHR-Account-Holder.
John Ritter (Jan 15 2020 at 06:22):
The PHR System Functional Model was designed to accommodate the capture, use, and export of ANY type of data and in ANY type of format (even data types yet-to-be-created). For example, a PHR-Account-Holder could be identified (or distinguished) via a Social-Security-Number, GUID, photograph, eye-print, voice print, facial scan, fingerprint, implanted RFID chip, random number, medical-record-number, et cetera. And the method of conveying the data could be via paper, keyboard, mouse, diskette, facsimile, Bluetooth, telephone wire, hard disk, microwave, audio file, electronic packet, et cetera. And the envelope could be via JPEG, CCR, CDA, C-CDA, an electronic form, a spreadsheet, an ad hoc message, a proprietary format, a TEXT message, FHIR, et cetera.
John Ritter (Jan 15 2020 at 06:32):
The PHR System Functional Model is a different kind of standard. It envisions and anticipates the use of both archaic and advanced functionality for managing information about a PHR-Account-Holder. For example, it accommodates the possible need for an entire document to be covered by a single, given consent -- or for portions of the document to be covered by "mini-consents" (so that certain parts of the document would not be disclosed to people or systems without proper authorization). The PHR-S FM also envisions the possibility of certain protections "accompanying" PHR data after it has been exported from the PHR system (though this feature is not yet common).
John Ritter (Jan 15 2020 at 06:34):
The PHR System Functional Model was balloted by folks from HL7, CEN, and ISO TC215.
John Ritter (Jan 15 2020 at 06:38):
The PHR System Functional Model was envisioned circa 2005 -- and followed closely behind the EHR System Functional Model. One standard targeted the needs of clinical professionals; the other targeted the needs of the citizen.
Abbie Watson (Jan 15 2020 at 06:45):
Yeah, it's fascinating how mature the industry is on some of these things. I feel like there were apps for Windows 95 that were floating around in the 90s that would qualify as a PHR nowdays. And they were just PC commercial rewrites of the VAX/MUMPS stuff being used in laboratories and clinics. But neither of those generations had mobile smart devices, nor the government giving any guidance to a standardized API or interoperability protocol. The industry has oscillated between centralized to distributed to centralized and now back to distributed again. Lots of opportunity to revisit some of that work, and see where things lead in this new regulatory environment and EHR ecosystem.
Abbie Watson (Jan 15 2020 at 06:49):
Regarding the SHOULD/SHALL, I'm sort of interpreting it as a venn diagram... SHALL are the overlapping shared features that most all systems need to support if they claim to be a PHR; and SHOULD features are the leaves of the diagram that have been observed in the wild as best practices but aren't seen as standard. And to your point... it's probably worth mapping the FHIR spec to the SHOULD features also!
John Ritter (Jan 15 2020 at 06:49):
With respect to the question of "seeing daylight" or "having influence", I ask which is more important: the data -- or the system that houses the data. That is, which one can we do without: the data -- or the system that handles the data? And to the underlying point of the question, which is more important: standards that support data -- or standards that support systems that house data?
John Ritter (Jan 15 2020 at 06:55):
Abigail: Hmmmm... For the amount of extra time that it might take the FHIR experts to review the "MAY" -level conformance criteria, I would recommend that the experts do so. For an item to be designated a "MAY", it was sometimes viewed as future-looking. Perhaps some of the newer FHIR resources might be able to envision or accommodate the types of PHR System functionality that was only being dreamed about in the past.
Abbie Watson (Jan 15 2020 at 06:56):
(deleted)
Dave deBronkart (Jan 15 2020 at 14:08):
I'll just note here that I bet <0.1% of the patient activist population has never heard of this model, or they/we might be pounding drums in the street wanting to know more.
Is there a tech-ish-consumer-friendly introduction to what this is? Has anything become of it in reality?
John Moehrke (Jan 15 2020 at 15:06):
Good topic to put on a joint meeting with the EHR workgroup. They are likely willing to open it up given our input. But I think we do need to come up with a set of questions to open the discussion... @John Ritter is a co-chair of that EHR workgroup.
Dave deBronkart (Jan 15 2020 at 21:54):
Well, just for the record, I'd have no clue where to start. Does any tool let someone ask a question that starts a VERY big discussion, in a way that's not just a flood of threads, but iteratively evolves an increasingly rich picture?
Abbie Watson (Jan 15 2020 at 22:37):
There's http://community.fhir.org/ which lets threads hang around longer than in the chat stream, and has better functionality for searching historical posts and retaining community conversations. We use the same forum software over in the Meteor.js community at https://forums.meteor.com/, and have countless threads that are hundreds of posts long, with links, images, supporting evidence, code snippets, etc. It's maybe the best place to start a very big conversation while keeping it public so patient advocates 'out in the wild' can find it. Also allows outbound linking to social media and blogs.
Abbie Watson (Jan 16 2020 at 17:48):
So, I went and broke down the PHR-S FM SHALL criteria into FHIR resources. By my count, there are 187 criterion with the word SHALL in them, incorporating the following three dozen resources.
AuditEvents
AllergyIntolerance
Appointment
Bundle
CapabilityStatement
CarePlan
Claim
ClinicalImpression
Consent
Contract
Communication
Composition
Device
DiagnosticReport
DomainResource
Encounter
ExplanationOfBenefit
FamilyMemberHistory
Immunization
Library
Media
Medication
MedicationOrder
MedicationStatement
NutritionOrder
Observation
Organization
Patient
Person
Practitioner
PractitionerRole
Provenance
RelatedPerson
Schedule
Slot
Sequence
ValueSet
Abbie Watson (Jan 16 2020 at 17:54):
Of these, many of them are already part of the Argonaut project (which now includes the Scheduling resources, as I understand). For the purposes of the Patient Empowerment group, I removed the Argonaut + Scheduling resources, since they're generally more normative and already have other people working on them. That leaves the following 15 or 16 resources which are relevant to PHRs, but which generally have a lower normative status and fewer users and need guidance and work input.
AuditEvents
Claim
ClinicalImpression
Consent
Contract
Communication
ExplanationOfBenefit
FamilyMemberHistory
Library
Media
NutritionOrder
Person
Provenance
RelatedPerson
Sequence
ValueSet
We have some BlueButton functionality in there, proxy accounts and family member in general, how communications and audit events are managed on the patient side, consent and management, and there's nutrition orders. Also, numerous PHR items around data provenance. And I don't think anybody has a clear idea on data heavy resources like ImagingStudy and Sequence.
Abbie Watson (Jan 16 2020 at 18:03):
Architecturally, I found criterion for probably 4 large system queues...
InboundQueue (Bundle)
OutboundQueue (Bundle)
NotificationsQueue (Communications)
AuditLog (AuditEvents)
References to probably two different directory services of some sort. Lets just call them Provider and Patient Directory.
ProviderDirectory
PatientDirectory
As a software engineer, I'd loosely describe a dozen APIs somewhat references throughout the 187 criteria. These aren't necessarily interoperability APIs, but recurring functionality.
AccountsServer
AccountsClient
Anonymization
Encryption
Filters
Mongo (Document DB)
Moment
Moment Timezone
PdfRendering
PdfViewing
Random
RulesEngine
Theme
Abbie Watson (Jan 16 2020 at 18:13):
I'd also identify the following software modules which these criteria reference or describe in some manner.
ADT
Argonaut
BlueButton
Blob Storage
CCDA on FHIR
FhirBlocks / Blockchain?
HIPAA,
IPFS
OperationalTransform
OAuth
OAuth Scopes
OpenID
PluginArchitecture
SMART on FHIR
Abbie Watson (Jan 16 2020 at 18:16):
Also, there are some specific user interfaces that are described throughout; two of which I feel might warrant having discussions around in the Patient Empowerment group. Specifically around how patients query terminology servers, and the problem list that they manage.
TerminologyQueryPanel
ProblemList
Abbie Watson (Jan 16 2020 at 18:18):
And lastly, there's references to SocialHistory, which in my opinion is a new resource that we may want to advocate for. Something to encapsulate anything on Facebook, Twitter, Instagram, etc. But also to model social worker interactions, community discussions, social determinants of health, mental health, patient diaries, etc.
SocialHistory
SocialPost
Lloyd McKenzie (Jan 16 2020 at 19:31):
We've talked about social history before. Thus far the consensus seems to be "use Observation" (reflecting how existing systems already manage such data)
Lloyd McKenzie (Jan 16 2020 at 19:32):
In terms of Audit and Provenance, there already is a guide aligned with the EHR record lifecycle events functional model: https://build.fhir.org/ehrsrle/ehrsrle.html
Lloyd McKenzie (Jan 16 2020 at 19:33):
As you can see, it hasn't had a lot of love and attention, but it's been around since DSTU2.
Last updated: Apr 12 2022 at 19:14 UTC
