FHIR Chat · Too Many IGs · patient empowerment

Stream: patient empowerment

Topic: Too Many IGs

Josh Lamb (Jan 28 2021 at 19:58):

There are too many IGs being developed to empower patients. We are using technical standards to limit behaviors. The model we are pulling data from is already standardized. We can use that model and allow application developers, consumers, and providers much greater freedom.

Josh Lamb (Jan 29 2021 at 00:18):

Does this make sense?

An application that can receive access from a consumer will be limited if it can only access use case specific functionality.

Instead use cases can emerge organically. Patients and providers should be able to choose how an application functions (and how to use their data).

Use case specific IGs seem to slow innovation. We can standardize on the patient and allow apps to meet use cases. I am not sure why we are trying to dictate standards around how data is used. Business agreements and consent should determine how data is used.

Josh Mandel (Jan 29 2021 at 00:22):

What specifically are you arguing against? The key implementation guides we have are not use case specific; SMART on FHIR provides a general authorization and integration method; US Core and CARIN BB together ensure access to two key data sets, with no specific use case limitations imposed. Of course the implementation guides each cover a certain technical scope, and there are some things you can build on top of this scope and other things you cannot (as a simple example, the CARIN BB implementation guide supports read access but some use cases require writing).

Josh Lamb (Jan 29 2021 at 00:23):

I am arguing against developing igs before the use cases.

Josh Mandel (Jan 29 2021 at 00:24):

You want to develop use cases first and then develop implementation guides.

Josh Lamb (Jan 29 2021 at 00:24):

And I am seeing that IGs that require subsets of data to be sent are limiting innovation. It sets barriers while we are still figuring things out.

Josh Mandel (Jan 29 2021 at 00:25):

Maybe it would help to provide some specific examples of activities or IGs you think are on the right track or activities you think are off base.

Josh Mandel (Jan 29 2021 at 00:25):

This discussion is a bit abstract for me.

Josh Lamb (Jan 29 2021 at 01:09):

CARIN and USCore are good examples of IGs that attempt to establish a minimum acceptable version of a resource. As things currently stand, all profiles sent to the consimer are in alignment. These IGs are also largely silent on how the data mist be used. This enables use cases to emerge.

An IG that says exactly how two parties must exchange data, and what fields to use may help with interoperability but I do not think we are ready. We should see how people use the data first.

We suggested a simple IG that allows the patient access api to accept task updates from patients and providers. This could be powerful in the hands of a clever developer.

Josh Lamb (Jan 29 2021 at 02:29):

Even for the suggested IG that includes task updates, it seems we were getting caught up in the specifics of how it would be used. I can think of numerous ways to use tasks but I would hesitate to provide implementation directions. Instead, I would like to see applications emerge that can take advantage of this capability (and hopefully the easy implementation and inclusion in the patient access API will increase adoption too).

I think that app developers if given some freedom, can develop use cases too.

@Michele Mottini what do you think as an app dev? Use case-specific IGs vs higher freedom (and consumer choice)?

Josh Lamb (Jan 29 2021 at 02:30):

Someone gave me a 2-hour speech about how limiting they found IGs for innovation. There are many more reasons that I know others have come across too.

Josh Lamb (Jan 29 2021 at 02:35):

If we focus on core functionality (complete data, how to trust, how to exchange) app devs can be leveraged to solve problems. Instead of using an IG to tell us how things will function, I trust that an app can eventually come along that people can agree to trust to perform some meaningful interactions. I do not see the need to trust the IG.

Again, this is specific to use-case specific IGs.

Lloyd McKenzie (Jan 29 2021 at 04:45):

IGs that specify subsets are setting minimums, they're not prohibiting other information from being shared. Certainly, you can expect certain systems will only do the minimum of what regulation-referenced IGs demand. However, the reality is that if those IGs didn't exist, the systems probably wouldn't share anything at all. Every IG has an underlying use-case or set of use-cases. As much as possible, we try to make sure that the IGs leverage the same interfaces and approaches, allowing re-use. Also, once the interfaces exist, extending them to support additional data elements - either demanded by other IGs or just because some of the sharing parties mutually find them useful should be easy to do. In general, FHIR takes the approach of "build simple useful things first and make it easy for them to grow and support new use-cases not initially contemplated" rather than "ask people to build global interfaces that support everything" - to which the typical reaction is "too expensive, no business case, no thanks".

Josh Lamb (Jan 29 2021 at 13:55):

I agree with this @Lloyd McKenzie. I know it's not black and white.

We will continue to discuss in this group. Basically I would like to see PE IGs allow patient and provider freedom.

Michele Mottini (Jan 29 2021 at 14:41):

I am all for more generic profiles, but 'generic task' does not seem that useful (having said that I don't think that the patient correction ones will ever be actually implemented)

Josh Lamb (Jan 29 2021 at 15:49):

If we ever get the ability to save tasks we can brainstorm some cool ways to use it.

Josh Lamb (Jan 29 2021 at 15:50):

We can define possible use cases too. Like the 4 patient correction ise cases.

Josh Lamb (Jan 29 2021 at 15:55):

@Michele Mottini do you imagine one app for the provider and a different app for the patient? We can do a lot more if the application is the same. You cannot use two apps with a vague IG. I agree with that.

Michele Mottini (Jan 29 2021 at 16:32):

. . .are you asking about patient correction? That should have apps only for the patients, provider would use their internal tools I assume

Josh Lamb (Jan 29 2021 at 21:01):

I am proposing that an app can be owned by a provider and used by a consumer. This enables more powerful interactions to occur (and removes the need to define interactions between the front end and backend, since one app owns both).

Lloyd McKenzie (Jan 29 2021 at 21:01):

Keep in mind that even if the FHIR interface is "store a Task", that doesn't mean that from a back-end perspective the data always ends up in a generic store (or even the same store). As an example, a system might expose an Observation endpoint, but only support vitals but not labs or vice versa (even though its internal data store contains both). Asking for systems to expose a 'generic' Task endpoint may be exceedingly hard to realize in practice. IGs with tightly defined scopes are easier to embark on.

Josh Lamb (Jan 29 2021 at 21:04):

The IG i am proposing will not work well if we have two apps trying to communicate (without an IG for guidance).

If a provider trusted an app, and the app found a cool way to utilize fields on the Task to perform meaningful interactions (that are controlled on both ends by app and data) I can see possibilities emerging without strict guidance.

Josh Lamb (Jan 29 2021 at 21:04):

The provider would need to see a demo and agree to the apps behaviors before installing and making it available to consumers though.

Josh Lamb (Jan 29 2021 at 21:05):

This IG would be attractive for implementers who wanted to create an app that allows the consumer to report/interact with FHIR related stuff, for example.

Josh Lamb (Jan 29 2021 at 22:27):

The task model needs must support flags for things we think will have value to save and retrieve. We can define basic search too. I am recommending to stay silent outside of this (maybe mention auth method required too).

Brendan Keeler (Jan 30 2021 at 00:33):

Generalized IGs like CARIN are good to raise the maximum possibilities (the ceiling). Prescriptive guides are good to raise the minimum acceptable capabilities (the floor)

Josh Lamb (Jan 30 2021 at 00:46):

I can get behind this @Brendan Keeler as long as the specialized guide does not collapse the ceiling.

Lloyd McKenzie (Jan 30 2021 at 14:39):

IGs should not prohibit behavior unless it's clearly wrong in the use-case. (So, for example, constraining max cardinalities is something that should be done only with considerable caution.)

Lloyd McKenzie (Jan 30 2021 at 14:40):

Are you finding IGs that are unreasonably constraining things?

Josh Lamb (Jan 30 2021 at 14:56):

There are open discussions about creating IGs that remove fields (set max cardinality to 0) but these have not made it past the idea stage and do not think they will gain momentum.

For PE, I am worried about use-case specific workflow IGs being too restrictive, for day one. We are essentially defining a sequence of Task states that must be followed to achieve an outcome. For the first IG, I think we can allow Devs to define how to interact with the Task.

The IG should also avoid assigning actions to the data producers based upon the Task states (e.g. if the Task status is "x" you must do "y").

Josh Lamb (Jan 30 2021 at 15:08):

This will be attractive for implementers because of the low burden (just allow consumers to post/put task). They will also keep freedom regarding how the Task is used via app choice.

Brendan Keeler (Jan 30 2021 at 15:33):

One possibility: you're overestimating drastically how well servers (EHRs) support Task or similar data structures today. Most inherently lack that concept (or have many user specific workqueues), so it's a big lift to implement, given how it spans a lot of ground. Perhaps that restriction is the tension of compromise between your desires (thinking from a creator/developer/app perspective) vs those other stakeholders.

Brendan Keeler (Jan 30 2021 at 15:34):

"just support Task generically!" turns into thirty mini projects for the server if they have multiple workqueues in their system today.

Josh Lamb (Jan 30 2021 at 15:40):

I agree @Brendan Keeler that task and workflow interactions between server and client open a can of worms.

I am proposing the server does nothing. Applications can handle saving the data and facilitating meaningful interactions. From the server's perspective, it's a blob (since we did not define a use case).

Josh Lamb (Jan 30 2021 at 15:50):

This is important because we need a common interface for third party applications to act against. Currently, we cannot share information between patients and providers (using the widely available interop interfaces).

Josh Lamb (Jan 30 2021 at 19:26):

The EHRs who have complex workflow systems already can ignore this task, by meta.profile[]. Will this increase compatibility @Brendan Keeler ?

Virginia Lorenzi (Jan 30 2021 at 21:10):

This is a serious problem - patients want their information corrected. Incorrect data impacts quality, safety, cost, and research for a better tomorrow.
And interoperability makes it worse because we spread the wrong data. And patients want to be heard - this provides a voice. They also just want their information and often times they want information not available on APIs and wont be for awhile. There are other patient requests like for appointment and refills or a callback from the doctor or just a question. So for example another use case could be patient request for release of information.
So we need to find a solution for patient corrections. I feel that there is functionality that will need to be developed on the server side, not just the API. EHRs are all about workflow. Orders of all types, med admin request, med supply requests, transfer order, pt order, order for diagnostic service, order for chaplain visit, request for use of a room, orders for a wheelchair, order for a room to be cleaned, release of information request, etc. It is my opinion that with the new information blocking rule, we can expect the request for data in electronic format to increase as well as requests for corrections. I do think that if we design this right, the same Task functionality could be used for other requests. We accomplished alot of work on this this week at the WGM and I refer you to the minutes for some of the design discussions. I will start a new thread in a little bit pointing out where you can find it also always appreciate the feedback

Virginia Lorenzi (Jan 30 2021 at 21:18):

As far as too many or too few IGs I was very tempted to say how about just right? That is the art of interoperability standards and that friction will always exists and we always have to think about rightsizing. I think a problem in the FHIR space is that an IG does not map to a server's capabilities. In V2 or messaging interfaces, you would have a messaging specification and you would implement those messages on that feed. With a server, you have end points for resources and I believe layered into how those endpoints are implemented is guidance from a multitude of IGs. It could be just one big IG and that would certainly make it easier to find. But IG work is use case and community driven so the work isnt done that way. We had this problem with CDA. Lots of people created different templates and IGs for CDA and finally someone created CCDA which through a whole bunch of them together so people could at least find them all which is why that document is huge and unweildy (I hope the CDA folk out there do not kill me for my description here and they can correct me). We might, with FHIR, be heading for that same place. However, we have that experience so we can look for it and address it.

Josh Lamb (Jan 30 2021 at 21:20):

To level-set on my goals (I promise they align with this groups):

1.) To develop a patient empowerment specification that can eventually be incorporated into policy.
2.) To empower patients and providers to interact, in a consistent manner, regardless of the EHR used.
3.) To allow patients and providers to maintain freedom of choice to choose how they interact with their health data
4.) To leverage the application developer community to help solve the problems facing the healthcare ecosystem
5.) To enable the transfer of information between payer and provider.

A generic task can meet all of the use cases specified. I posted a diagram earlier that details this process. The trick is to get an application developed and to enable economy of scale—the more, the merrier, for many reasons.

Josh Lamb (Jan 30 2021 at 21:25):

The push back against a generic task, that the server is NOT ALLOWED TO TOUCH, is that it allows for third party applications to participate, currently it requires a specialized integration into each EHR (because we specify the server behavior).

Virginia Lorenzi (Jan 30 2021 at 21:28):

@Josh Lamb I will go back and review your picture. The problems we have unearthed this week were generic I believe. Have you been looked at #workflow as well? I think that we need to look at it as an external request. Requests are only that - requests. If you order me to clean my room that doesn't mean I will do it or that I will do it how you want me to or when you want me to and I may have lots of questions about what exactly you mean by room cleaning. We should be doing this on #workflow. I hear FHIR I has Tuesday Workflow calls.

Virginia Lorenzi (Jan 30 2021 at 21:28):

save me time - post it again please @Josh Lamb

Josh Lamb (Jan 30 2021 at 21:29):

I have 10 great app ideas for how to utilize a generic Task (we can now share information, and we are computer people, an ID can carry a lot of information).

Lloyd McKenzie (Jan 30 2021 at 21:54):

I think a "patient empowerment" specification is way too generic a concept to ever see implementation. Start small and design to allow to expand. If you design too big, nothing happens. The reality is that right now, there are no interfaces to allow patients to initiate requests. Each interface that gets enabled will have to be specifically enabled by the EHRs. And each interface may well talk to a different system (even if from an external patient perspective it may seem to be the same black box). Some IGs involve freedom to choose. Others nail things down to ensure interoperability and to make the 'ask' small enough that there's a decent chance of it being built. Keep in mind that there's no "generic Task" on the EHR side and there probably won't ever be. Just as there's no "generic Observation". Labs, vitals, smoking, etc. are all completely different back-end systems, that just happen to all be surfaced using the same FHIR resource.

Josh Lamb (Jan 31 2021 at 00:02):

How does a specification that requires no action from the server limit implementation? The goal is to allow third-party applications to meet needs, regardless of the EHR used.

Josh Lamb (Jan 31 2021 at 01:01):

I was thinking a base specification, that use case specific igs can derive from. I am not married to any particular fhir resource either. It should be trivial to implement, since applications can perform the meaningful work.

Lloyd McKenzie (Jan 31 2021 at 01:23):

But we do require action by the server. We need to drive behavior in EHR and affiliated systems. The requested actions need to be persisted somewhere - and the only place we have to persist them is in the EHR

Josh Lamb (Jan 31 2021 at 01:57):

If we need the EHR to perform a series of actions to update a specific fhir resource in a predictable way I agree.

Josh Lamb (Jan 31 2021 at 01:59):

I think this approach is limiting. I feel it's necessary to demonstrate how a generic approach can provide the foundation needed to support a wide variety of use cases. Perhaps use cases can be done through certification instead of through pre-planning app code?

Josh Lamb (Jan 31 2021 at 01:59):

Until systems are certified there is not inferop anyway.

Josh Lamb (Jan 31 2021 at 02:00):

Again, the allure of this approach is that it requires servers to leave data alone (acting as repository or middleman). If an ehr wants to create an app to utilize this, that works too.

Lloyd McKenzie (Jan 31 2021 at 03:30):

We're not pre-planning app code. We're defining an agreed interface. The interface will be 'standard' from a client perspective. The back-end implementation may be widely different. The server isn't going to leave the data alone - the EHR users are going to need to change it. The EHR isn't going to want to be a middleman for itself.

Josh Lamb (Jan 31 2021 at 04:31):

The EHR can do whatever it wants, today, including all of the PE use cases.

Josh Lamb (Jan 31 2021 at 04:32):

The interface is defined as a structure definition. The use cases and prescriptions for how servers should behave is my issue.

Josh Lamb (Jan 31 2021 at 04:38):

If you were writing an application, would you like to be told exactly how it should function?

Lloyd McKenzie (Jan 31 2021 at 04:47):

I'm not understanding. How the EHR handles the Task, how it transitions states, etc. is up to it. But we definitely need to define that it has to accept POST and perhaps PUT and search.

Lloyd McKenzie (Jan 31 2021 at 04:48):

There are some basics about what the inputs will look like and what the output will look like - that's fundamental to defining the interface

Lloyd McKenzie (Jan 31 2021 at 04:48):

How the EHR actually manages the process of deciding on the change is up to it.

Lloyd McKenzie (Jan 31 2021 at 04:49):

The interface is the CapabilityStatement that defines the RESTful behaviors along with a profile that describes the data structure manipulated.

Josh Lamb (Jan 31 2021 at 04:50):

I 100% agree we have to define post, put, and search, including the fields we require the server to support.

Lloyd McKenzie (Jan 31 2021 at 05:06):

Ok - so what behavior is it that you feel we're over-defining?

Josh Lamb (Jan 31 2021 at 16:02):

We were requiring the server/EHR to take action. As @Virginia Lorenzi said, we can separate the request, fulfillment, and repository(server). A profile that the server cannot touch (unless they take on the fulfiller role) will ease the implementation burden and allow third-parties to develop apps to meet the PE use cases without involvement from EHRs. This also allows for a single app to meet a wider range of needs (more users and a wider range of functionality).

Josh Lamb (Jan 31 2021 at 16:08):

We can separate the fulfillment of a use-cases from the CRUD.

Lloyd McKenzie (Jan 31 2021 at 16:34):

We're requiring people to take action - and we're expecting some component of the EHR to expose the request to the right people. The reality is that EHRs aren't monolithic and there are multiple pieces of software that hospitals and clinics use - and the one used to manage interactions with patients (including logging requests for change) might not be the same as the ones used to store the clinical data that needs correcting. However, I'd be cautious about suggesting that introducing a third-party is going to make things easier. Our fundamental objective is to get information in front of the individuals that are responsible for resolving correction requests. The organizations responsible for managing software in those organizations are going to be a whole lot happier and are more likely to adopt if the functionality shows up in their existing solutions than if they have to use something external. Keep in mind that there's no regulation here that requires organizations to change from their existing paper-based processes, Requiring installation of some new set of software (whether app or not) and forcing reliance on some uncontrolled intermediary doesn't seem like a winner to me...

Josh Lamb (Jan 31 2021 at 16:37):

I realize this may be seen as a way to open the doors for third-party applications to begin developing meaningful apps, without the blessing of the EHR vendors. The EHR vendors can and have always been free to create any apps that meet their needs (or the needs of PE).

Josh Lamb (Jan 31 2021 at 16:39):

This is for a consistent server-side implementation/functionality, regardless of EHR or application used. The applications can adopt the use-case specific IGs or develop their own workflows.

Josh Lamb (Jan 31 2021 at 16:40):

The consumer's right of access will drive application choice. The provider's will have similar freedom (driven either by consumer's access or with the blessing of the EHR with user access).

Josh Lamb (Jan 31 2021 at 16:41):

There are many EHRs, and a consistent mechanism to interface with every server will be powerful for PE.

Lloyd McKenzie (Jan 31 2021 at 16:48):

The point of the standard is to define consistent interfaces - implemented by the EHRs themselves, which are the holders of the data. I'm not seeing the business case for a hospital or clinic to bypass them here.

Lloyd McKenzie (Jan 31 2021 at 16:50):

In the end, the actual changes - and any "logging of disagreement" must be stored in the EHR. Third-party solutions seem like they'd just make that more complex - in addition to the complexity to the healthcare organizations of having yet one more player in an already complex space.

Josh Lamb (Jan 31 2021 at 16:52):

A large EHR may develop their own apps (and implement the use cases this group will define) themselves. The EHR can also meet many use cases without an IG (which they do readily). Currently, third-party apps can ONLY meet use cases through an IG, and they cannot innovate. Third-party apps can reach a wider range of people (hit all of the patient access APIs instead of going through a site-specific open.epic or open.cerner instance).

Josh Lamb (Jan 31 2021 at 16:53):

It is important that a consumer can use an application of their choice to interface with their healthcare data. If we require EHR integrations with the app, this will be impossible.

Josh Lamb (Jan 31 2021 at 16:55):

The consumer can currently use the Patient Access API to view data using an application of their choice. We can expand the Patient Access API to allow the application to directly facilitate meaningful interactions between patients and providers. This could also enable HIPAA exchanges to occur at the consumer's request (currently not an option through an Patient Access API).

Josh Lamb (Jan 31 2021 at 16:56):

Focus on Patient Access API is important because it will be widely available and we should develop solutions that do not skip large portions of the population.

Josh Lamb (Jan 31 2021 at 17:41):

Alignment-of-Interests-1.png Here is the conceptual map of why I think this is important. We can continue to dig into the details during our conference and WG sessions.

Lloyd McKenzie (Jan 31 2021 at 18:11):

I don't know what you mean by 'consumer'. If we're talking employees of a health system, they don't have "choice" - they use what their organization dictates/permits. And the functionality needed on the patient correction side is for integration with EHR software to support making corrections, linking to the data corrected, propagating "notices of disagreement" into the record, etc. What is the evidence for the belief that this will work better with 3rd party apps or be more likely to be adopted by healthcare organizations in third party apps than if the features are directly supported by the EHR? Note that choice by patients isn't relevant here. There can be all kinds of apps for them. The question is what's going to run inside the healthcare organizations.

Josh Lamb (Jan 31 2021 at 18:14):

Lloyd McKenzie said:

If we're talking employees of a health system, they don't have "choice" - they use what their organization dictates/permits.

Josh Lamb (Jan 31 2021 at 18:14):

Lets give them a choice then

Josh Lamb (Jan 31 2021 at 18:16):

Can we schedule a time to discuss @Lloyd McKenzie? We can probably come to a consensus without making the communities eyes bleed.

Lloyd McKenzie (Jan 31 2021 at 20:44):

Providers don't have a choice because their organizations make the decisions about what technical solutions they're allowed to use - and that's not something we can wish away. (And the security side of me says we shouldn't wish it away.) The decision-makers here are going to be the folks who run the IT shops of the health organizations and the health organization leadership who tells them what to do. What are the selling features of this approach to them? (Because "more choice" probably isn't it...) We can take this offline to PMs if you feel that would be more productive.

Dave deBronkart (Jan 31 2021 at 21:47):

I come back from a couple of days under the weather and my Zulip badge's alerts counter says "214".

Well, we WANTED to stir up participation...

Josh Lamb (Jan 31 2021 at 22:37):

Some providers operate out of private practice. I do not see why the FHIR community has input into what can occur in a care setting. The patient and provider are capable of selecting applications that meet their needs (assuming we provide an ecosystem that allows this to occur).

Josh Lamb (Jan 31 2021 at 22:42):

@Dave deBronkart We can just always go with the popular opinion and never make noise. But that is not what PE is about.

Josh Lamb (Jan 31 2021 at 22:45):

What I am basically hearing is that we will not allow patient and providers to use an application of their choice to assist with care.

Josh Lamb (Jan 31 2021 at 22:45):

This is a HUGE problem for me, and I hope this entire community.

Lloyd McKenzie (Feb 01 2021 at 00:51):

It's not about what "we" allow. It's a question of how the market works. Typically, individual care providers are not in charge of making those decisions. Exactly how things work vary from country to country. If we're going to define interoperability solutions (which is HL7's role), we need to take into account how the market dynamics function in the environments where we need adoption. In general, we don't define solutions that are predicated on any significant change to market dynamics - because that isn't typically very productive. It's not like we have much in the way of leverage...

Josh Lamb (Feb 01 2021 at 01:03):

We can create an applicatino today, without the EHRs blessing, and use the consumer's right of access to view healthcare information and to use that information to communicate between patient and provider. Again, this can be done today, but no one is. So the worries you are putting forward may not be warranted. The ability to save data to a FHIR server is needed regardless of the approach taken. I am not yet convinced that allowing an option for a "no-op" from a server somehow increases complexity, risk, or burdens EHRs anymore than a use case driven model. Use case-specific patient correction models will need a model to derive from anyway, to ensure alignment.

Lloyd McKenzie (Feb 01 2021 at 01:08):

How does a right to view information provide any mechanism to enable communication between patient and provider? That only builds a read-only interface and doesn't drive any change in what providers can see. Keep in mind too, that we can't make servers do anything. There has to be a business case for both the software vendor and for the customers who purchase those solutions. The biggest question for us is "how do we interact with the healthcare professionals who control health record corrections?" By and large, those users are restricted to using EHRs or other systems specifically approved by their organizations. Saying "we'd like there to be choice" doesn't change that dynamic.

Josh Lamb (Feb 01 2021 at 01:26):

So the EHRs are the product owners for the patient empowerment workgroup? @Dave deBronkart

Josh Lamb (Feb 01 2021 at 01:27):

An application can have its own backend and share information. I am just saying it's possible but it would be much easier (and better) to have the data producer act as the repository. This also enables more meaningful interactions to occur.

Dave deBronkart (Feb 01 2021 at 01:29):

Josh Lamb said:

Dave deBronkart We can just always go with the popular opinion and never make noise. But that is not what PE is about.

Josh, would you like to dive over to PMs? I honestly don't know where any of this is coming from. You're being kind of weird, reading other people's minds. Not to mention, mid-discussion, asserting what "we" "will not allow."

Please try to be more collaborative, less combative. (And I'm speaking only as Dave, not in any official capacity. I've been co-leading online discussions since 1989 and this is just not the way to create community progress.)

Josh Lamb (Feb 01 2021 at 01:31):

ill send a pm

Josh Lamb (Feb 01 2021 at 01:52):

Great points Dave. I hope something good can come if we can get on the same page. I will not push so hard! I am approaching this from a different perspective but the same goals.

Lloyd McKenzie (Feb 01 2021 at 02:27):

There are no "product owners" - there are specific stakeholders that realistically need to be engaged to get to a solution. Some are easier to engage, some harder. PE doesn't drive what happens in industry. No HL7 work group drives what happens in industry. We help facilitate discussions amongst various industry stakeholders, each with their own business drivers. We try to find a solution that works for those drivers. Sometimes, there's no solution to find. Often there is. But we absolutely don't dictate what happens.

Josh Lamb (Feb 03 2021 at 16:46):

An IG that can apply to all sources is more attractive to me. For example, a task that will result in a patient identifier being added to the patient resource seems like it would have universal value. This would allow a consumer to begin building connections between their data sources. I see the PASS ID as a great candidate for this task.

Lloyd McKenzie (Feb 03 2021 at 17:55):

But if the back-end processing is going to be completely different for different tasks, it's not going to be possible for systems to comply with a generic IG. Also, there's a need to nail down what the Task.code values are, what the Task.input and Task.output values are, etc. Sure, you can have a system that knows how to store and permit search on arbitrary Tasks - no need for an IG at all for that, as the FHIR core spec covers what's needed. But as soon as you need to mandate support for certain elements and constrain the terminology to enable a specific use-case to function interoperably, you need an IG to establish those rules - and the rules are use-case specific. For some systems, the incremental add of a new Task.code and a few new input or output types will be minor because it's just a small extension of existing capability. For others, it represents a major set of work because it involves routing data to a completely different sub-system and a whole new set of mapping.

Josh Lamb (Feb 03 2021 at 20:46):

I agree, a use case-specific IG, like adding/updating a custom patient identifier, will require interaction with the source data. I am attempting to define a use-case specific IG that would have a lower implementation burden and a high degree of utility (to empower patients to build connections).

Josh Lamb (Feb 03 2021 at 20:54):

Regarding a generic IG, good points about the maintenance challenges. Can we allow the servers to omit terminology validation for this generic task?
A principal component of this approach is that the server is unaware of the meaning of the task, or its contents. The server would probably not allow an application to register for this use case until this information is known. It may create an option for innovation to occur though.

If we had a generic Task 1 year ago that was part of the Patient Access API a single application could have been universally used to coordinate COVID tests and vaccines. I can flow this use case out if it's useful.

Lloyd McKenzie (Feb 03 2021 at 21:05):

It's not about terminology validation, it's about agreement on how to interoperate. If I send code X, I expect you to do Y. That needs to be nailed down if we're going to get interoperability. Saying "If I send you codes, I expect you to do 'stuff'" isn't something anyone can meaningfully implement. We don't expect all back-end systems to have a 'generic' place to store these. They need to know what the requests can correspond to so they know the place (places) to map to in their system. If the system is unaware of the meaning of the Task, what subsystem do they route it to? What table to they stick it in? If back-end systems don't support "generic" Tasks, we can't have an IG that demands that they do - at least not if we want a hope of implementation.

Josh Lamb (Feb 03 2021 at 22:27):

I have gone through thought experiments where imagine ways to provide maximum freedom to app developers, patients, payers, and providers while requiring as little involvement/effort from the server as possible (save only), but it sounds like even the save operation is a burden for the larger EHRs. Any suggestions or is the premise of a requester/repository/receiver pattern a non-starter?

I am hearing that standards and agreements occur outside of HL7 too. Maybe this will allow other communities to contribute?

Lloyd McKenzie (Feb 03 2021 at 22:34):

It's not always a given that an intermediary is a non-starter, but that pattern requires a business model for the intermediary. Who pays them? Is there a reason someone would want to pay them (and do so for a sufficiently long period of time to justify setup)? Is there trust in the intermediary by both sender and receiver? Is there one intermediary or can there be more than one? If one, can they operate such that they can talk to all possible senders and receivers? If more than one, who decides what intermediary contains what stuff - and is the complexity of senders and receivers needing to support talking to multiple intermediaries worth it?

Typically, intermediaries work best for registry type stuff (providers, organizations, drugs, etc.), and even there only if there's a 'sponsor'. I have trouble visualizing it being successful in this space.

Josh Lamb (Feb 03 2021 at 22:38):

Correct, the business use cases would need to be justified, or this would be dormant functionality. I saw an opportunity to track vaccines and to provide a consistent way for consumers to place requests (a HHS portal, for example, could have met this use case). Sometimes we have people available to solve a problem and the technology is lagging behind. I see these cases as opportunities to go app first, instead of use case first.

Lloyd McKenzie (Feb 04 2021 at 01:19):

Given that implementation is use-case driven, not general capacity driven, that's challenging. FHIR provides a façade that may make lots of functionality appear to be the same. But the back-end code is frequently quite different.

Josh Lamb (Feb 04 2021 at 03:04):

Thanks for that insight @Lloyd McKenzie. When the use case is not defined, it is beneficial to think of all implementations as a facade. What happens below the interface (including outcomes) is a black box. Humans, acting upon directions received through an app of their choice, are required to bridge the gap between a third-party app and the underlying data. A standard interface (facade) can provide a consistent read-only view of the status of things. A vaccine for a person can be verified through the standard "facade" search for claims and clinical data. Same is true for a read-only view of a condition (covid) or a observation (antibodies). At the end of the day, if you send a task, and someone gets a vaccine, do you really have to know the mechanics (every single time)?

Lloyd McKenzie (Feb 04 2021 at 03:34):

You're presuming the existence of intermediaries that don't exist, and for which there's no business case. You're also assuming providers will be able to choose which apps they get to run, which isn't necessarily the case either. Also, apps (if you're talking about SMART apps) only run when launched, which isn't going to satisfy workflows where there's a need to push information in front of providers.

Josh Lamb (Feb 04 2021 at 03:36):

Thanks @Lloyd McKenzie , I will get back to you!

Josh Lamb (Feb 06 2021 at 22:45):

To close this thread out, I have a new thread in argonaut addressing the importance for the Patient Access API to accept a federated patient identifier (from HIPAA connections). This patient identifier will empower patients to access all of their healthcare data. This is also important for security reasons. The member id we submit in claims data is not a secure identifier.

Lloyd McKenzie (Feb 07 2021 at 01:24):

It might be 'desirable', but not sure we can say it's "important". Right now the requirement is that each hospital/provider have an ability to authenticate the patient and allow access to their data from that provider. Most, if not all, systems now have that (and those that don't are either going to have it soon or face penalties). Having a federated identifier isn't essential to making that happen - and for it to work, all of the various hospitals and clinics would need to agree to trust it and have the necessary legal paperwork in place with the identification authority to allow that to happen. Not sure it's realistic to expect that anytime soon.

Josh Lamb (Feb 07 2021 at 21:52):

@Lloyd McKenzie I agree with you. My current preference is to use an OpenID token that accepts multiple FHIR Patient.Identifiers[]. The federation (and choice to trust the authority) will be at the discretion of the consumer and data producer.

John Moehrke (Feb 08 2021 at 13:04):

FHIR Patient.identifier is not an authentication mechanism. It is just an identifier. A system that mints an Open-ID-Connect authentication token when given simply a Patient identifier would be a horrible idea for real-patients, and a money-maker for the black-market. As Lloyd points out, this is about Identity assurance and authentication assurance. See NIST 800-63 for discussion. This is not special in healthcare, but is special in that failures expose data that is highly sensitive, can't be revoked and re-issued, and can be deadly for the patient, family, and care-givers. Healthcare must build upon general-IT, I fully support Open-ID-Connect. But the identity proofing and authentication strength are still the most important aspects.

Josh Lamb (Feb 08 2021 at 14:08):

HIPAA covered entities create identifiers not random apps. They can produce a federated ID (trust relationship).

Josh Lamb (Feb 08 2021 at 14:10):

We do this today with X12, which results in an identifier being added.

John Moehrke (Feb 08 2021 at 14:14):

but it is an identifier. it is not an authentication statement / assertion / token. Creating identifiers is easy, and Patient.identifier can hold an infinite number of them.

Josh Lamb (Feb 08 2021 at 14:16):

creating identifiers is an important component of the puzzle though!

Josh Lamb (Feb 08 2021 at 14:17):

getting people fhir endpoints to accept an open id is another. Payers can helps solve the identifiers issue already in a huge way.

John Moehrke (Feb 08 2021 at 14:17):

I just went to https://www.guidgenerator.com/ and created 10 identifiers that are globally unique... do you want 10 more?

aed3ca39-e92a-4c9e-8b37-124e4931f494
0902ca41-cc3b-4910-810e-0af7b1cfa815
145377eb-6176-4bf2-b6fe-988ef06d5fe4
f56b8d3e-3e0c-4040-a0f5-6fbb28bc1d09
26f0cbfd-73d2-4371-a1ca-90b1134daafd
5e641e5f-2e38-43d6-a1dc-2f1519811ec4
77b75216-a608-4302-94e1-7858fa3eaa37
62037319-0434-4433-b941-c85e557d1571
073d0880-030b-4cf1-a54a-de87ef349d57
372ea8d7-0e32-4273-858b-f254d3014c11

Josh Lamb (Feb 08 2021 at 14:20):

The patient's connection is not used for B2B since the consumer will not be able to engage. The ID is proof on the requesting side and payer/provider apps enable meaningful use under HIPAA. The consumer's device can not directly exchange data for B2B. In cases where a patient requests data from another data producer we do not require them to login and the connection used between businesses does not require engagement.

Josh Lamb (Feb 08 2021 at 14:28):

If payers wanted to create an ID sharing network (via trust relationships) the network will grow exponentially.

John Moehrke (Feb 08 2021 at 14:37):

The context of B2B provides the identity proofing and context of the meaning of the identity. This is quite common. There are plenty of models for cross-referencing one business identifier for a patient with another businesses identifier for the same patient. For example IHE has a family of these implementation guides that give the same use-cases and define how to manage patient identity cross-references when the technology layer is HL7 v2, HL7 v3, or HL7 FHIR; and companion implementation guides for query against demographics.
Here is the FHIR based Patient Master Identity Registry specification https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_PMIR.pdf

John Moehrke (Feb 08 2021 at 14:38):

Here is the HIE-Whitepaper from IHE at the sub-section on Patient Identity management https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#5-patient-identity-management

Josh Lamb (Feb 08 2021 at 14:42):

Great stuff @John Moehrke !

Debi Willis (Feb 08 2021 at 18:01):

@Josh Lamb Have you looked into what CARIN is doing in this area? If not, you should contact them to see what they are doing.

Josh Lamb (Feb 08 2021 at 18:20):

Yes @Debi Willis thanks for calling out CARIN. I found an option for data exchanges and am not sure what other options people have found.

Last updated: Apr 12 2022 at 19:14 UTC