XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • R5
    • Patient Administration
    • Practitioner
    • Hide

      Rationale: Device is the most appropriate resource to represent any sort of automated system performing or participating in activities.  Device implements the Participant pattern, and is listed as an actor in the Event pattern and a performer in the Request pattern.

      Some workgroups (incl PatientCare) have already updated their resources to allow references to Device in places when recording participants.  We suggest that each WG review their references and ensure that Device is listed as an allowed participant type if appropriate.

       

      We will update the Practitioner resource "Boundaries and Relationships" section to clarify this position (change highlighted in bold):

      Boundaries and Relationships

      ...

      Practitioners are also often grouped into CareTeams independently of roles, where the CareTeam defines what specific role that they are fulfilling within the team, and might or might not have actual practitioner role resources created for the practitioner (and in the care team context, the organization the practitioner is representing)

      When an autonomous system or machine is an actor or participant, the Device resource should be used to represent that system.  This would include artificial intelligence or machine learning (AI/ML) systems, as well as other automated systems. 

      Show
      Rationale: Device is the most appropriate resource to represent any sort of automated system performing or participating in activities.  Device implements the Participant pattern, and is listed as an actor in the Event pattern and a performer in the Request pattern. Some workgroups (incl PatientCare) have already updated their resources to allow references to Device in places when recording participants.  We suggest that each WG review their references and ensure that Device is listed as an allowed participant type if appropriate.   We will update the Practitioner resource "Boundaries and Relationships" section to clarify this position (change highlighted in bold): Boundaries and Relationships ... Practitioners are also often grouped into  CareTeams  independently of roles, where the CareTeam defines what specific role that they are fulfilling within the team, and might or might not have actual practitioner role resources created for the practitioner (and in the care team context, the organization the practitioner is representing) When an autonomous system or machine is an actor or participant, the Device resource should be used to represent that system.  This would include artificial intelligence or machine learning (AI/ML) systems, as well as other automated systems.  
    • Brian Postlethwaite/Daniel Rutz: 17-0-1
    • Clarification
    • Non-substantive

    Description

      One aspect of interoprability of FHIR is not only the more common use-case of FHIR for training AI/ML models but the use of AI/ML agents in an interoperable way. Babylon would like to model their AI/ML agents as "machine practitioners", and perhaps model the different AI/ML models/versions as "practitionerRole"s.

      Babylon as a provider would like to be able to attribute FHIR resources created to these "machine practitioners" and be able to use them for interoperability in cases providers exchange their electronic medical records  or if providers want to offer their AI/ML agents to partners.

      It would reflect correctly in an EMR what a human and what a machine practitioner performed and is essential for evaluating clinical safety and so on.

      Supporting "machine practitioner" in HL7/FHIR wouldn't need any additional work by HL7/FHIR implementors but would need an update on the documentation of the FHIR Core Spec (v5) on http://www.hl7.org/fhir/practitioner.html and https://www.hl7.org/fhir/practitionerrole.html which are both managed by the patient working group.

      During integration work I noticed that EMRs (like Athena) already model "machine practitioner" in the wild which Cooper confirmed for Epic, too, and such a documentation step in the standard would only reflect what is already used by providers.

      Attachments

        Activity

          People

            brian.postlethwaite Brian Postlethwaite
            artur_ortega Artur Ortega (Inactive)
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: