Versions Compared

Old Version 2

changes.mady.by.user Paul Knowles

Saved on

compared with

New Version Current

changes.mady.by.user John Walker

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

- FHIR Working Meeting

Attendees:

John Walker

Topics:  Summarize feedback to the larger Working Group 

  1. No updates 

General Business: 

  • Any topics ...

- FHIR Working Meeting

Attendees:

John Walker

Topics:  Summarize feedback to the larger Working Group 

  1. No updates 

General Business: 

  • Any topics ...

- FHIR FG Working Meeting

- FHIR Working Meeting

Attendees:

John Walker

Burak Serdar 

Mukund Parthasarathy

Topics:  Summarize feedback to the larger Working Group 

  1. FHIR OCA  
    1. Update Burak's dynamic OCA schema development - Burak presented slides of his dynamic overlay generation approach, slide deck from the
    2. MP / JW update on JSON-LD context file leverage - discussion on the usage of FHIRcat JSON-LD context files.

General Business: 

  • Any topics ...

 - FHIR FG Working Meeting

- FHIR Working Meeting

Attendees:

John Walker

Burak Serdar 

Mukundan Parthasarathy

Jim St. Clair

Topics:  Summarize feedback to the larger Working Group 

  1. FHIR OCA Demo 
    1. Overview 
    2. Repo review

General Business: 

  • JW 



 - FHIR Working Meeting

Attendees:

John Walker

Burak Serdar 

Mukundan Parthasarathy

Topics:  Summarize feedback to the larger Working Group 

  1. OCA Core Data Types
    1. Will require a type mapping from FHIR 
    2. This work effort and team has concerns with this conversions on healthcare data
    3. We understand that the BIT attributes will remain OCA base schema
    4. Projection Overlays - Extensions - still WIP
      1. Projection overlay definition:  "The projection overlay should describe the transformation of external schema / data object representations into an OCA formatted schema instance. The projection overlay would require a source and destination schemas.
        1. Projection Overlay working notes

General Business: 

  • JW 

- FHIR Working Meeting

Attendees:

John Walker

Burak Serdar 

Mukundan Parthasarathy

Topics:  Summarize feedback to the larger Working Group 

  1. Following from  "Transformation of OCA Artifacts" discussion
    1. Feedback from presentation 
    2. Candidate RFC's
      1. Removal of BIT attributes from OCA base schema
        1. This approach would allow OCA to leverage existing / multiple BIT based schemas 
    3. Projection Overlays - Extensions 
      1. Projection overlay definition:  "The projection overlay should describe the transformation of external schema / data object representations into an OCA formatted schema instance. The projection overlay would require a source and destination schemas.
        1. Projection Overlay working notes

General Business: 

  • JW - In the conversion of the DSWG to ISWG, it seems the working notes from 2 meetings have been 'misplaced' - we'll inquire if they can be re-inserted?
  • Holiday Schedule - next meeting will be Thursday Jan 7, 2021

- FHIR Working Meeting

Attendees:

John Walker

Burak Serdar 

Topics:  Summarize feedback to the larger Working Group 

  1. Following up from Tuesday's WG working meeting and the "Transformation of OCA Artifacts" discussion
    1. Feedback from presentation 
      1. We've had no feedback other than what was shared in the meeting.
      2. Link to presentation: 
    2. Candidate RFC's
      1. Projection Overlays
      2. Removal of BIT attributes from OCA base schema
        1. This approach would allow OCA to leverage existing / multiple BIT based schemas 
    3. Overlays - Extensions 
      1. Projection overlay definition:  "The projection overlay should describe the transformation of external schema / data object representations into an OCA formatted schema instance. The projection overlay would require a source and destination schemas.
        1. (Please see Google doc - WIP)

General Business: 

  • TBD

- FHIR Working Meeting

Attendees:

John Walker

Mukundan Parthasarathy

Burak Serdar 

Albert (SSI/Blockchain startup, Bordeaux, France)

Topics:  Summarize feedback to the larger Working Group 

  1. Following up from the last working meeting on the topic of taking a complex, nested json object and render that into OCA Base + Overlays
    1. Simple demonstration of an example FHIR resources expressed as JSON-LD 
      1. ex: Immunization resource instances
        1. Use these instances to demonstrate the potential variations in valid instance within the same bundle 
        2. Ex: What is the syntax for selecting Immunization/vaccineCode/coding/code?
        3. How does this work with array fields: Immunization/performer is an array of objects, how do you select all of them? How do you select a particular one?
        4. Use this example to explain the use of a "projection overlay" for instance mapping
    2. Overlays - Extensions 
      1. Blinding Identity Overlay - Assume that the BIT attribute assignment in the base schema is a union of all potentially attributes needing 'blinding' 
      2. Demonstrate the use of  'conformance-type' and 'conformance spec'  as the specification mechanism to identify blinded attributes → drive the related RFC discussion
        1. Agreement on handling profiles/extensions via conformance-type and conformance-spec headers v/s separate overlay for handling conformance to profiles such as us-core etc.
        2. [Burak] Overlay selector idea based on use cases (to be explored: tags, fhirpath or some such spec to identify the use cases/context for use of overlays)
      3. Demonstrate the use of the Masking Overlay to apply blinding to an FHIR OCA instance
        1. Projection overlay for flattening. Sub-setting overlay may not meet all the needs. Barak shared ideas around a "mapping" format that can be used in the definition of the Projection overlay, so as to simplify the "flattening" problem, for the purposes of data capture/display in OCA "forms".
      4. Potential uses of the Subset Overlay 
        1. Discussion

General Business: 

  • JW - Propose this standard meeting frequency is changed to bi-weekly frequency occurring at 8:00am PT on Thursdays

- FHIR FG Working Meeting

Attendees:

John Walker

Mukundan Parthasarathy

Burak Serdar 

Topics:  Transform required for FHIR complex resource object into OCA

  1. Following up from the last working meeting on the topic of taking a complex, nested json object and render that into OCA Base + Overlays
    1. Source FHIR EHR → Base 
      1. Burak - "how do we bridge schema to data?"  Solution could be a capture schema to limit the fields, and use a projection overlay to map to the OCA form.
      2. New
    2.  Overlays - Extensions / updates 
      1. Blinding Identity Overlay - Assume that the BIT attribute assignment in the base schema is a union of all potentially attributes needing 'blinding'  - ? from 10/29 meeting notes - the suggestion is to use 'conformance-type' and 'conformance spec'  as the specification mechanism to blind specific attributes ?  Yes, working group proposal is to create or update the existing RFC's to propose the addition of 'conformance-type' and 'conformance-spec' as attributes in both the OCA SB and OCA Overlay specification.
        1. How is this implemented? Application (FHIR) bundle specific contexts for blinding attributes
      2. Need a better way of selecting fields in overlay specifications, especially for nested data structures like JSON/XML
        1. Ex: What is the syntax for selecting Immunization/vaccineCode/coding/code?
          1. How does this work with array fields: Immunization/performer is an array of objects, how do you select all of them? How do you select a particular one?

General Business: 

  • JW - standard meeting time changed to 8:00am PT every Thursday

  - FHIR FG Working Meeting 

Attendees:

John Walker

Mukundan Parthasarathy

Burak Serdar 

Topic:  OCA Overlay Authoring

  1. Review current Overlay authoring processing
    1. THC Editor , CSV file upload
      1. CSV Parsing Tutorial
    2.  Overlay creation discussion
      1. The current tooling is limited to a straightforward hierarchical human entered form based creation
    3. Discussion of extensions / updates to OCA Spec
      1. Create a Blinding Identity Overlay - BIT attribute assignment should be removed from the base schema, as the attributes and their respective values are context specific and the requirement to 'blind' should be applied via overlay(s).
        1. Application (FHIR) bundle specific contexts for blinding attributes
      2. Need a better way of selecting fields in overlay specifications, especially for nested data structures like JSON/XML
        1. What is the syntax for selecting Immunization/vaccineCode/coding/code
          1. How does this work with array fields: Immunization/performer is an array of objects, how do you select all of them? How do you select a particular one?
          2. Something like XPath or JSONPath may work, or might support multiple dialects, like xpath: /Immunization/performer[1]/function/code, or xpath:Immunization/performer[function/code="someCode"]
      3. Overlays need to be contextualized and may likely require a linking structure to preserve resource context
        1. Immunization → Patient → Address vs. Organization → Patient → Address

...

  1. Discussion - Explore evolving how a "base schema" structure used

General Business: 

  • JW - change in the meeting time to 8:00am PT every Thursday

Follow up discussions/clarifications from 29 Oct 2020 meeting notes:

  1. Paul Knowles and Robert Mitwicki mentioned that BIT (Blinding Identity Taxonomy) could be a 'union' of ALL possible attributes in a base schema, regardless of context of use. This would allow overlays, such as Masking overlay to achieve context specific "blinding" of attributes.
  2. We haven't discussed "how" context specific BIT processing can be achieved. FHIRPath or similar expression language for 'selection' along with specification using metadata fields either in the base schema or overlays can help accomplish this. We have already defined 'conformance-type' and 'conformance-spec' as base schema & overlay properties that can be used to define the exact BIT specification. For example, 'conformance-type' set to the value "BIT", and conformance-spec can be set to the value (uri) of a FHIR StructureMap resource that can map the base schema instance to an equivalent instance with BIT applied for the specific use context. If necessary we can add a 'useContext' property, in the tradition of FHIR, to explicitly define context matching for BIT.
  3. Since each overlay definition embeds a reference to its corresponding base schema, it appears there is no need to cross-link overlays, as this may result in unintended consequences E.g. how would software deal with the case where two overlays are linked, but each of them refer to unrelated base schema?
  4. Need for base schema? Burak Serdarraised the issue w.r.t need for base schemas. Paul Knowles to explain this further. Data harmonization use cases (i.e schema to schema semantic mapping across domains for data pooling etc) would definitely benefit anchoring in base schema. Need to walk through other examples Burak Serdar has in mind to clarify this further.


  - FHIR FG Working Meeting

Attendees:

John Walker

Mukundan Parthasarathy

Bserdar 

Adrian Gropper

Topic:  Base FHIR Conversion ; FHIR Privacy Concerns 

  1. Base FHIR Conversion Updates - Overview of current work
    1.  Review of FG Use Case 1: FHIR resource bundle export of a specific resource set targeted for consumption by a non-FHIR supported provider.
      1. Limited scope to begin
  2. General discussion on OCA Implementation Applicability 
    1. Adrian's explanation of HEofOne
    2. General comments on the limitations of the current FHIR based consent mechanism.
    3. Discussion regarding the overly complex consent / contract resource alignment.

General Business: 

  • JW - proposal to change the meeting time to 8:00am PT every Thursday

9/10/2020 - FHIR FG Working Meeting

Attendees:

John Walker

Mukundan Parthasarathy

Topic: Use Cases & Context with ISO Notice and Consent Standards 

Candidate Use Case Review / Including ISO Standards  Context and Preliminary Requirements

  1. Use Case 1: Remotely Accessible Patient EHR - patient expressly requests creation of a FHIR based EHR representation to be used by different Health Care providers in different (same country) locale. (This use case can evolve to support crossing national boundaries thus adding complexity)
    1. Feedback:
      1.  JW - Create a use case document and process template to record the use case. 
  2. ISO Context 
    1. Will reach out to Mark Lizar for content

General Business: 

  • JW - will publish meeting time and link on the FHIR FG confluence page

9/3/2020 - Kick Off FG Working Meeting

Attendees:

John Walker

Mukundan Parthasarathy

Mark Lizar

Steven Milstein

Topic: Review and Prioritize Use Cases 

Candidate Use Cases 

  1. Remotely Accessible Patient EHR - patient expressly requests creation of a FHIR based EHR representation to be used by different Health Care providers in different (same country) locale. (This use case can evolve to support crossing national boundaries thus adding complexity)
    1. Feedback:
      1. ML - add Notice and Consent as they pertain to the actors in the use case 
      2. MP / ML - we need to map the FHIR consent resource to ISO standards implementation of 'Notice'
        1. Notice = vocabulary and semantics of a consent
      3. Agreement to begin work using Use Case 1 
      4. Augment the use case documentation with business process diagram / flowcharts
  2. Consent to participate in Clinical Research (FHIR data)
    1. ML - factor in the requirements for a Careprovider / Patient / Research institute 
    2. ML - leverage existing ISO standards 
  3. Consent to participate in a Clinical Trial. (CDISC:SDTM data (see SDTM Implementation Guide v.3.2 here))
  4. Specify the data and credential requirements for Patient Identity and Matching (e.g. ER visit)
  5.  Demonstrate the usage of OCA persisted EHR data across EHR system boundaries 
    1. ML - mentioned a reference project framework 

...

  1. SM - create narrowly focused, end user centric demos to demonstrate "user" value

General Business: 

  • Weekly meeting start time will be moved to 7:00am PT / standing meetings planned for every Thursday.