Provenance register elements can probably be covered by standards

[jpriebe-epic]

Provenance

Register-type-code Register-specifier

These two elements I'm pretty sure can be handled in the standard FHIR models. I think this could be covered by a link to the register via onBehalfOf

The larger question is probably how to represent a "register" in Finland. Probably extensions in each resource aren't the right way, but maybe a profiled Organization resource can handle this?

[mrinnetmaki]

Epic currently supports this in Apotti with Locations, through a tree structure.

[mrinnetmaki]

@mikajylha to provide the links to the definitions of the required specifiers.

[mrinnetmaki]

Use case is SMART App Launch between Esko and Una. Una requires this info in launch.

[mrinnetmaki]

This might be useful: https://yhteistyotilat.fi/wiki08/pages/viewpage.action?pageId=64433645

[jpriebe-epic]

For Provenance use case of doing a SMART - do you have an example of how FHIR Provenance data would look from both perspectives, client and server?

|

Actor Requests Patient Resource from Custodian

|

Actor

GET fhir.com/Patient/ID1234

In HTTP-land, a GET is not supposed to have a body, so doesn't really make sense to send Provenance FHIR data here generically for FHIR read operations. But the server needs to know who's querying and their justification right, that's the point of the register stuff? I guess if you're bundling FHIR Resources in some application later it can just be a POST or something.

Also, Isn't there a bunch of user info in the OAuth2 token? And the goal is checking the client to make sure they can access the server's register, could that be handled upstream of FHIR like in the authorization flow (e.g. in Oauth2, you request access to a SCOPE of X register that gets included in the JWT token)?

But if you did include Provenance resource here on the query side, it'd something like this:

{provenance... ...AGENT...= Actor identifiers (etc etc)" ...REGISTER/Target...=Register you're requesting access to /provenance}

|

Custodian

Serves data from .../Patient/ID1234

{patient ... /patient}

|

"Query of Register Custodian" is a use case that I have a hunch will be repeated all over for queries to Kanta data/other patient data accessed through integration. In Apotti we see it all over in in Kanta queries, Radiology image queries from Kvarkki, and document management stuff. So important we get it right.

[jpriebe-epic]

Ping, maybe we can talk about this in a meeting - very curious about what this will look like (I might have it wrong in my example above)

[jpriebe-epic]

@mrinnetmaki any update, can we have a meeting to discuss this? Very curious about how this regulation will get implemented in the standards

[mrinnetmaki]

@jpriebe-epic sure! Most of Finland is on summer holidays right now. We could schedule this for our meeting on August 24. If that's too late for you, we can have an offline discussion sooner.

[mrinnetmaki]

To me, the use case is not so much access control (GET requests). I believe that will be handled differently.

What we mainly need this custodian info for is the peculiar Kanta. We store a lot of data there, but Kanta is usually not considered a custodian of the data. Therefore, it is important to store, together with the data, information on the actual custodian. So that if you for instance find some errors in the data you know whom to contact to get it corrected.

It's more about "who's responsible for maintaining this data" rather than "who has justified access to this data under these circumstances."

This is just my own view and does not necessarily reflect the view of the whole Finnish FHIR community, though.

[mrinnetmaki]

The same with Apotti, I guess. The system stores data from multiple register custodians, and it is useful for apps to be able to find out where a piece of data originates from.

My own hunch would be that access control would live on a different level (more generic, which practitioner in which role has access to which data) and that information could be reflected on integration layer too. You may want to implement that with the Provenance resource for any FHIR resources, but I don't think you'd be expected to. The same rules govern access to all data, not just the data that's available as FHIR resources.

And again, for both patients and practitioners it is sometimes useful to know where a piece of data originates from and who is responsible for maintaining it.

[mrinnetmaki]

It's of course plausible that you want to limit a query (A kanta query, for instance) to data from a certain register custodian. I don't know whether Kanta people already have a view on how this would look like. Perhaps @mikatuomainen does?

[jpriebe-epic]

Ah I see - Provenance just represents ownership/authorship. This seems pretty close to how Epic's implemented it. already, I should have reviewed this first.

See this bit of documentation - it's found using the _revinclude search parameter, which searches for link pointing towards your resource.

For example, querying against a patient resource like this: GET https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Patient?_id=TnOZ.elPXC6zcBNFMcFA7A5KZbYxo2.4T-LylRk4GoW4B&_revInclude=Provenance:target

Will return:

<Bundle xmlns="http://hl7.org/fhir">
    <type value="searchset" />
    <total value="1" />
    <link>
        <relation value="self" />
        <url value="https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Patient?_id=TnOZ.elPXC6zcBNFMcFA7A5KZbYxo2.4T-LylRk4GoW4B&amp;_revInclude=Provenance:target" />
    </link>
    <entry>
        <link>
            <relation value="self" />
            <url value="https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Patient/erXuFYUfucBZaryVksYEcMg3" />
        </link>
        <fullUrl value="https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Patient/erXuFYUfucBZaryVksYEcMg3" />
        <resource>
            <Patient>
                <id value="erXuFYUfucBZaryVksYEcMg3" />
                <extension url="http://hl7.org/fhir/us/core/StructureDefinition/us-core-race">
                    <extension url="detailed">
                        <valueCoding>
                            <system value="urn:oid:2.16.840.1.113883.6.238" />
                            <code value="2131-1" />
                            <display value="Other Race" />
                        </valueCoding>
                    </extension>
                    <extension url="text">
                        <valueString value="Other" />
                    </extension>
                </extension>
                <extension url="http://hl7.org/fhir/us/core/StructureDefinition/us-core-ethnicity">
                    <extension url="text">
                        <valueString value="Unknown" />
                    </extension>
                </extension>
                <extension url="http://open.epic.com/FHIR/StructureDefinition/extension/legal-sex">
                    <valueCodeableConcept>
                        <coding>
                            <system value="urn:oid:1.2.840.114350.1.13.0.1.7.10.698084.130.657370.19999000" />
                            <code value="female" />
                            <display value="female" />
                        </coding>
                    </valueCodeableConcept>
                </extension>
                <extension url="http://open.epic.com/FHIR/StructureDefinition/extension/sex-for-clinical-use">
                    <valueCodeableConcept>
                        <coding>
                            <system value="urn:oid:1.2.840.114350.1.13.0.1.7.10.698084.130.657370.19999000" />
                            <code value="female" />
                            <display value="female" />
                        </coding>
                    </valueCodeableConcept>
                </extension>
                <extension url="http://hl7.org/fhir/us/core/StructureDefinition/us-core-birthsex">
                    <valueCode value="F" />
                </extension>
                <identifier>
                    <use value="usual" />
                    <type>
                        <text value="EPIC" />
                    </type>
                    <system value="urn:oid:1.2.840.114350.1.13.0.1.7.5.737384.0" />
                    <value value="E4007" />
                </identifier>
                <identifier>
                    <use value="usual" />
                    <type>
                        <text value="FHIR" />
                    </type>
                    <system value="http://open.epic.com/FHIR/StructureDefinition/patient-dstu2-fhir-id" />
                    <value value="TnOZ.elPXC6zcBNFMcFA7A5KZbYxo2.4T-LylRk4GoW4B" />
                </identifier>
                <active value="true" />
                <name>
                    <use value="official" />
                    <text value="Camila Maria Lopez" />
                    <family value="Lopez" />
                    <given value="Camila" />
                    <given value="Maria" />
                </name>
                <name>
                    <use value="usual" />
                    <text value="Camila Maria Lopez" />
                    <family value="Lopez" />
                    <given value="Camila" />
                    <given value="Maria" />
                </name>
                <telecom>
                    <system value="phone" />
                    <value value="469-555-5555" />
                    <use value="home" />
                </telecom>
                <telecom>
                    <system value="phone" />
                    <value value="469-888-8888" />
                    <use value="work" />
                </telecom>
                <telecom>
                    <system value="email" />
                    <value value="knixontestemail@epic.com" />
                    <rank value="1" />
                </telecom>
                <gender value="female" />
                <birthDate value="1987-09-12" />
                <deceasedBoolean value="false" />
                <address>
                    <use value="old" />
                    <line value="3268 West Johnson St." />
                    <line value="Apt 117" />
                    <city value="GARLAND" />
                    <district value="DALLAS" />
                    <state value="TX" />
                    <postalCode value="75043" />
                    <country value="US" />
                </address>
                <address>
                    <use value="home" />
                    <line value="3268 West Johnson St." />
                    <line value="Apt 117" />
                    <city value="GARLAND" />
                    <district value="DALLAS" />
                    <state value="TX" />
                    <postalCode value="75043" />
                    <country value="US" />
                    <period>
                        <start value="2019-05-24" />
                    </period>
                </address>
                <maritalStatus>
                    <text value="Married" />
                </maritalStatus>
                <communication>
                    <language>
                        <coding>
                            <system value="urn:ietf:bcp:47" />
                            <code value="en" />
                            <display value="English" />
                        </coding>
                        <text value="English" />
                    </language>
                    <preferred value="true" />
                </communication>
                <generalPractitioner>
                    <reference value="Practitioner/eM5CWtq15N0WJeuCet5bJlQ3" />
                    <type value="Practitioner" />
                    <display value="Physician Family Medicine, MD" />
                </generalPractitioner>
                <managingOrganization>
                    <reference value="Organization/enRyWnSP963FYDpoks4NHOA3" />
                    <display value="Epic Hospital System" />
                </managingOrganization>
            </Patient>
        </resource>
        <search>
            <mode value="match" />
        </search>
    </entry>
    <entry>
        <resource>
            <Provenance>
                <target>
                    <reference value="Patient/TnOZ.elPXC6zcBNFMcFA7A5KZbYxo2.4T-LylRk4GoW4B" />
                </target>
                <recorded value="2019-05-28T14:07:06Z" />
                <agent>
                    <type>
                        <coding>
                            <system value="http://terminology.hl7.org/CodeSystem/provenance-participant-type" />
                            <code value="author" />
                            <display value="Author" />
                        </coding>
                        <text value="Author" />
                    </type>
                    <who>
                        <reference value="Practitioner/eyMDh2ar2p-6j4VssVTtgMqVgfHBUsoKWlw7pdR-8VWo3" />
                        <display value="Ed Registrar Adt" />
                    </who>
                    <onBehalfOf>
                        <display value="Epic USCDI on FHIR" />
                    </onBehalfOf>
                </agent>
                <agent>
                    <type>
                        <coding>
                            <system value="http://hl7.org/fhir/us/core/CodeSystem/us-core-provenance-participant-type" />
                            <code value="transmitter" />
                            <display value="Transmitter" />
                        </coding>
                        <text value="Transmitter" />
                    </type>
                    <who>
                        <display value="Epic USCDI on FHIR" />
                    </who>
                </agent>
            </Provenance>
        </resource>
        <search>
            <mode value="include" />
        </search>
    </entry>
</Bundle>

I'm interested in what the Kanta implementation would look like though since this will inevitably be a big project for Epic to support.

[jpriebe-epic]

Reading this again with your information and the goal of Provenance to represent the register ownership of data:

Similar to my comment in the other issue - I think "registers" can be represented as Organization resources linked to from Provenance. This is close to how this data exists in Apotti today and how we support Finland's register privacy requirements.

provenance-participant-type specifically supports a participant type of "custodian" which sounds like exactly what we want to represent here.

So register should be represented an Organization, pointed to via Provenance.agent.type(custodian).who

An example Provenance of a patient returned to accomplish the goal of Finnish register custodians:

         <Provenance>
              <target>
                  <reference value="Patient/TnOZ.elPXC6zcBNFMcFA7A5KZbYxo2.4T-LylRk4GoW4B" />
              </target>
              <recorded value="2019-05-28T14:07:06Z" />
              <agent>
                  <type>
                      <coding>
                          <system value="http://terminology.hl7.org/CodeSystem/provenance-participant-type" />
                          <code value="custodian" />
                          <display value="custodian" />
                      </coding>
                      <text value="custodian" />
                  </type>
                  <who>
                      <reference value="Organization/eyMDh2ar2p-q23sgasddhd61831083-8VWo3" />
                      <display value="VAKE Register" />
                  </who>
              </agent>
          </Provenance>

In this example I assume the register is the FHIR server generating the resource , so it's represented as Provenance.who. But an EHR FHIR client such as Epic might use Provenance.agent.onBehalfOf to represent archiving data to the register, with Provenance.agent.who being representing the submitting organization.

Both already link to FI Base Organization, it's just a matter of moving the RegisterTypeCode and RegisterSpecifier to content in the Organization resource. RegisterTypeCode can probably be an identifier slice, RegisterSpecifier might need to be an extension.

If we decide to go this direction, I think example Organization resources representing each of the types would be helpful (Organization as Municipality, Organization as Register, Organization as Hospital).

Also I would like to hear what the Kanta and THL folks think about this, since it's their implementation that matters.

[jpriebe-epic]

Looks like Kela folks might agree with this change: Issue 141

[mrinnetmaki]

Thanks @jpriebe-epic!

What we want to reference here is not just the organization. An organization may have several different registers.

The information required for Kanta includes

• the organization (rekisterinpitäjä)
• the register (rekisteri, might be "työterveyshuolto", person information register for occupational healthcare)
• the register specifier (tarkenne, the employer of the patient in the case of occupational healthcare)

To me, it feels a bit funny to have these extensions be in the Organization, because then you'd need several instances of the organization, one for each register they are maintaining and for each customer in their register for occupational health...

It also makes it a bit more tricky for a client to get this information...

[mrinnetmaki]

See some further discussion in https://chat.fhir.org/#narrow/stream/179247-Security-and-Privacy/topic/Specific.20register.20in.20Provenance/near/385441326.

[jpriebe-epic]

Pull request: https://github.com/fhir-fi/finnish-base-profiles/pull/166

Talked with Mikael - the new model seems to make more sense

I think this change satisfies me, but I want to do a deeper review to make sure I understand.

[mrinnetmaki]

Thanks Josh!

[mrinnetmaki]

We got pretty close to a solution, but failed to reach consensus. Register type and register specifier were left out of the v1.0.0. The proposal for including the info in .entity is still there, but commented out. See #172.