PLEASE SIGN IN HERE

Agenda

Minutes

Mon Q1

Plenary

Mon Q2

Plenary

Mon Q3

• Minutes from previous WGM (Montreal) : Emma Jones move to approve, Michael Padula second
• Michelle Miller updates the agenda of this WGM directly in confluence.
• PC V2 topics: Amit Popat has not received any request on HL7 V2.
• Question from Marc de Graauw about maternity care. Michael Padula points out to CIMI. CDA
• IHE PCC templates labor, prenatal templates. QRPH has done topics on hearing problems.
• Look at https://build.fhir.org/ig/HL7 . For example:

• https://build.fhir.org/ig/hl7au/au-fhir-childhealth/profiles.html

  http://build.fhir.org/ig/HL7/cqf-recommendations/examples/anc/anc-guidelines.html

• Resolving general trackers:
• FHIR 22730 Clinical impression: No binding for status reason. A question is if we should have a status reason.
• The value set for status is extended. A value set for status reason is given (example binding).
• Comments are extended to explain about the bindings
• Michael move to accept, Emma second: vote 5 in favor, 0 against, 0 abstentions
• Here is the link:

  https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=22730

Mon Q4a

Mon Q4b

Slide deck from Giorgio Cangioli and Rob Hausam:

IPS overview - 

• Provides a healthcare summary. Not designed for a specific condition for a patient or a specific provider. Is to be used in general for the care of a patione
• Cross boundaries use - cross system boundaries
• Set of standard - 
  • CED - defines the data set
  • Data set is being used to ISO
  • Done in FHIR
• List of sections and other optional information
• FHIR IG (as well as CDA)
• FHIR IPS as designed is a document, composed of reusable data blocks. 

FHIR Ballot

• Two negatives
  • One is from Gary Dickenson - will resolve with him on wed. 
    • Comment: need to better describe how to handle the provenance related to reconciliation. Also need a part 2 that considers workflow of how the document is created, etc. 
• Observation.performer reference need a must support
• Resolution - persuasive
• Rob Hausam move; Simone second - Vote 15 for; 0 against; 0 abstain
• How to harmonize this IG with other IGs such as US core. For example, effective dateTime is must support. Added invariant "dateTime must be at least to day". persuasive
  • Vote: Rob Hausam move; Simone second - Vote 16 for; 0 against; 0 abstain
• Observation.basedOn removed - persuasive
  • Vote: Rob Hausam move; Simone second - Vote 16 for; 0 against; 0 abstain
• Explain difference between R4 patient.generalPractitioner and composition.practitioner extension- Is the extension really needed? Should the existing structures be used rather than the extensions? 
  • Vote captured in gForge 23887

IPS initiative Coalition

• Collaborative initiative for IHE and HL7 - benefit of IHE Testing to accelerate adoption.
• Profile Proposal
• 
• Mike Nusbaum and Stephen Kay as co-editors
• 
• Workflow is not part of the current IHE proposal but will be addressed in the future
• Questions/Discussion
  • Can you elaborate on confirming or enhancing IPS content - for example, work information is not part of IPS. There may be domain specific content that would need to be address at the national level. 
  • IHE - any changes in the based standards - will be brought to HL7 as change proposals. If changing the content, suggestion made to go to ISO. 
  • Need to round out the use cases. Need to look at what is out there already that some jurisdiction are currently using. 
  • Anticipate there will be some level of content vetting. 
  • Is the profile building a FHIR profile. 
    • Leaving the workflow out for now. 
  • Concern is there may be an overlap
    • Focus on the testing part
    • There is not a current template or documentation of what the testing may be to test internationally. 
  • Is this really an international patient summary? If so, will be focused on the data that is needed so it is picked up and placed in a box. 
    • Need to have the terminology 
    • Need to have the parts that are generic enough to be useful. 
  • Several use cases - referrals where the information is sent and the second is where the information is retrieved. 
  • If doing both CDA and FHIR, need to keep the two aligned. 
  • IPS does not have a lot of value sets specified - IHE may open the way for access to more standard code sets. 
    • There is a wide set of data in IPS that is more high level. The use cases will be helpful. 
  • IPS use cases -
    • working abroad 
    • Unscheduled Care 
    • Scheduled Care
    • Cross-border
    • Within borders
  • Timeline reviewed
    • Plan on putting together the testing plan 
    • HL7 will need to start defining FHIR documents. 
  • QOW call - will send out doodle poll. 

Tues Q1

CIMI Projects Overview

Process - Interoperable App Development Process

Domain Analysis →Create Logical Models (CIMI)→Approve Models →Model Repository →Create FHIR Profiles (transform from logical model to FHIR)→Artifact repository (FHIR profiles)→create software

• Skin and Wound Assessment
  • Initiated by Nursing Knowledge Big Data Initiative
  • Scope is to develop model and FHIR profiles
  • Implementers - Podiatry, etc
  • Maps to both SNOMED and LOINC
  • Progress - terminology complete; FHIR profiles complete; FHIR IGs
  • Issues - SNOMED CT version not international; using extensions for qualifying observations on Condition Resource
  • Doing this work in STU2 with Cerner
  • Synchronization of profiles
  • Cost to App developers to send info into the EHRs - EPIC and Cerner charge by instance
• Pain
  • Initiated by Nursing Knowledge Big Data Initiative
  • Includes assertion of pain and all possible qualifying elements
  • Inplementers - Epic
  • Maps to LOINC Pain Assessment Panel (38212-7)
    • Pain quality looks like it's describing the characteristic. Done this way because that's how it's documented in Epic and Cerner
    • CCC - is at a higher level and has been mapped
  • Progress and Status - Next task is to develop the FHIR profile. 
  • Issues - alleviating and Exacerbating Factors - not in SNOMED
    • FHIR conditions can't have qualifying observations
    • Need definitions for both answers and questions
• Vital Signs - objective was to extend the qualifying observations. Looked at open Air for the values and from other source. 
  • Initiated by Intermountain and the FHIM
  • Scope: include qualifying observation
  • Progress: terminology complete; modeling complete
  • Implementers - Intermountain, PenRad
• Walk thru provided by Nathan. 
  • Discussion
    • BP from an arterial line - it's a device
      • Cuff is a means and could be considered a device. the method is automatic or manual. 
      • These types of issues come up so a library is needed to state a standard way
    • Post coordinate methods - is there a way to convert to an iso-semantic method? It's not apples and apples. 
    • What if the patient is on oxygen while doing the O2Sats?  -  that would be a different profiles. 
      • Suggestion to have an extension that points to the observation
      • In practice the O2 that patient is on is recorded. But when the order goes to the lab, the O2 is included
      • In EPIC they capture whether they are on supplemental O2 and how the measurement was taken
      • discussion about the amount of details, level of granularity is needed - could be different across settings, institutions, etc. 
      • Whole set of different profiles for pediatric growth charts - started with the data used for the Pediatric growth chart out of Boston Hospital and enhanced it. 
      • Body Temperature Measurement - suggestions should be sent via ballot comment. This is a preferred value set.
      • Have a web site where these are located. 
      • FHIR core vital signs - how will this get aligned with the FHIR core - meeting with FHIR-I today. FHIR is also doing SNOMED on FHIR and creating reference sets. 
  • Transform from the Logical models - are the extensions going to end up in the logical model? Logical model outlines the base. A map is created. when the tooling compares the logical model and dose not see alignment, it creates an extension. 
  • What is the nature of the patient Care CIMI relationship? Do you need other support from PC? 
    • CIMI is not a clinical working group. Work being done is very clinical. Clinical work will need to continue to be done with PC. 
  • CIMI wound had a project, would vitals have a project? The VS project was shared with CIC. 
  • Next WGM planning - Don't know yet if CIC will be at Australia WGM. CIMI will get back to PC with plans for the next WGM. 
• Update on the ACOG project
  • Don't know where going live is at. Have requested additional work - on syphilis work. 

Tues Q2

Clinical Notes:

• SD Brett Marquard: In Clinical Notes there are 2 key resources in the US core: diagnostic report, document reference. Did SD assign value sets? Loinc has a nice hierarchy in their value set for the type of reports, but according to Brett no system support these codes.
• Lisa seeks guidance for interoperability. For example use a Loinc code to select lab results. The problems is that most systems have their own legacy local codes from the past. Mapping is required to select the correct lab results.

IPS:

• The IPS has been extended to serve more purposes. Not only borders, but also bounderies.
• 2 negative entries that have been resolved.
• Working together with CEN and IHE. IHE is focussing on a content profile, not a workflow profile.

Basic Provenance:

• 91 comments on the ballot on a 16 page document.
• On of the use case is an HIE transformation. During the storage of data, the data could be transformed. There is no assurance that producing the data would deliver the same exact data from registration.
• Patient generated data with the purpose of using the data from a patient ( in another system). The patient is entering data in a patient portal. A clinical review takes place by a reviewer before the data is imported into medical records.
• Discussion about the scope of the use case. There are systems that collect data from different EHR. Patient would then see errors in the data, that they would like to see corrected. Provenance could help to track and request correction of data.
• Should the scenario's be split in seperate topics: one with review, one without review?
• In a CDA the source should always contain an organization. In the case of a patient, what should the organization be?
• Should a device also be considered as an author or is it the source.

Clinical status

• Not discussed

Tues Q3

Close the dental interoperability investigation project:  Todd/Lyndsey:  16 approve-0 negative-2 abstain

GF#23061 Communication needs to explain the boundary between it and messaging

Tues Q4

Negation Project - Jay Slides

Gender Harmonization PSS (Rob McClure)

• Problem: recording Sex and gender and it means a lot of different things. 
• Project: started spring 2019. Initiated by need of public health reporting of gender/sec other than M-F. Added "X"=non-binary to HL7 code system administrative code system.
  • Meetings on mondays at 4pm - Please participate
  • Current project thinking:
    • gender identity=independent of legal gender identity, displayable, disclosed - examples include Male, Female, non-binary
    • Legal Gender=may have more than one entry
      • Examples include legal gender - passport gender, legal gender - driver's license gender, legal gender - birth certificate sex
      • Qualified by a type and specified time frame, may require further qualification by jurisdiction
    • Sex Phenotype = based on observation
      • Examples include Male Pattern, Female Pattern, other, undisclosed, unknown
        • Other - does not fit Male or Female Pattern →Look or clinical observations
        • Unknown - not observable, e.g. trauma case
      • Alternative name: Sex for clinical use
  • Currently Birth Sex is in the social history section - as part of level 1 of the alignment to USCDI promotion process can work on getting guidance that this is patient demographic item. 
  • Quality measures - need stratification with 2 level elements. For risk adjustments, will like to have this broken down. CDS also need to use this. 

CPG-on-FHIR - overview by Bryn Rhodes

• Focus is on what should happen from the guideline perspective
• Workflow is out of scope
• Overview of use cases

New  - AMA - Patient Referral - Seth Blumenthal

Discussion/Questions

Will you make use of the existing document templates like CDA Referral notes?

• CCDA on FHIR IG has profiled Referral Notes - looking at sections that are structured already. 

ServiceRequest and C-CDA-on-FHIR are containers. Patient Care would be interested in collaborating in this work. The clinical content development will inform the containers. The existing work may not be adequate. 

• One way is to look at this work independent of the standards pre-dicate work

Public Health B-SER IG - going to be published in a few weeks. Use case is different. Want to share information about this work with you. 

Don't currently need yet another referral project - HL7 do need clinical input into existing work. Suggestion that what is needed may need a white paper. 

• How dependent would this be on different physician specialty? Something to think through. May make people think you are champion this new thing means you are responsible for creating this new thing. 

Work is to include actual clinical data. Slide 5 has specific clinical content as an example of the type of content. One option is to see what's in FHIR and what has been done. 

Referral content - general content and also clinical specialty referrals which a typically based on specialty guidelines and protocols. Doing this will have certain degree of specificity. If there are specific work that has been published at the human readable level, will appreciate access to it. 

Patient care would like to get a PSS. Seth is made aware of next Patient Care CO-Chair call. 

1. Elective Procedures GF 24064 - elective or non-elective procedure which was performed during the inpatient encounter

                                                   related to a tracker 22786 - Request "priority" element for procedure resource

3. Principle vs Primary Procedures (22786 - Request "priority" element for procedure resource; 24014 - Inconsistent modeling - attributes in Claim and Encounter diagnoses and procedures)

1. These are OO questions. suggestion is to refer to OO because patient care can not change their valueset. 
2. Suggest reviewing the request-priority value set. 
3. FHIR-I owns the value set that OO (service request) is binding to
   1. Patient Care is the incorrect WG on the Committee
4. Encounter resource uses the HL7 V3 Actpriority valueset. This valueset are machine state values. The FHIR-I valuesets are a subset of the HL7 ActPriority values. 

Principle vs Primary Diagnosis

Claim resource relationship to the clinical data

Discussion: 

Is there any guidance to the defintions? 

• CDC has guidelines when to use these definitions.
• AHA Coding authority made up of CDC, CMS
• The definitions are done outside of HL7 - these are billing guidelines. 

Second use of this is quality. Trying to get the two to line up is a problem. 

The problem may be for different context, these are used in the same spot in the resource. 

Another issue may be that QI-core is mapping principal to primary in FHIR. 

List used in Institutional

Used in Professional

ICD Qualifying Codes Used

Encounter’s Relationship to Diagnosis.pptm

Keep this quarter for next WGM. 

Wed Q1 - Q2

Joint with PA

GF#23843 Encounter should support a reference to CareTeam

Update on Patient Merge - Merge Operation

GF#23029 CareTeam.encounter should support cardinality 0..*

GF#20483 Add Encounter.diagnoses elements to Condition 

Wed Q3a

Joint with O&O

• Gforge 19873: Structured Doc: Talking about Document Reference in the resource Composition. SD ( Lisa Nelson)'s remark was brought forward again. Rick Geimer reminds that Category came from IHE requirements where it contained high level information.
• Device.status has a mixed use: expressing status of resource, but also to express active, inactive, with meaning implanted or not implanted. Suggestions from O&O to modify status in general to express the semantics more clearly.
• Option1: Explicit attributes for each element that has a status:
• Option 2: backbone element with 2 attributes: Status and status reason. Examples: Operational status, operational status reason, logic status, logic status reason. This will be possibly extended in feature.
• Option 3: backbone element considering 3 attributes instead of 2 with extra attribute: Value type reason
• Also catching thoughts about Property
• Question about the body reference site in Device. According to Eric Haas this is put in the procedure. But is there always procedure?
• Gforge 20932 about Information recipient. This topic is now solved in an extension.

Wed Q3c

CDex - update - Viet and Bob D. 

DoD/Va had 32 negative votes. Had a total of 317 comments. 97 negatives. 

Many Va Votes requested in-person resolutions

Plan is to do the non-in person resolutions and will bring an update to PCWG. 

Ken Rubin will help coordinate the in-person resolutions on the Community project calls (CDex calls) 

Few comments are on the underline based resource. Please send Michele a message with the ones that impact the base resource. 

Plan is to get through all the comments - will create a group in gForge identifying the base FHIR clinical resource

FHIR QA - recommendations 

1. Condition has severity but not criticality vs AllergyIntolerance has criticality but not severity – no change needed

2. AllergyIntolerance refers to a ‘patient’ (Reference(Patient)) vs Condition refers to a ‘subject’ (Reference(Patient|Group)) – need a use case to better justify adding Group to AllergyIntolerance

3. Condition provides two Event extensions: instantiatesCanonical, instantiatesUri – the extensions make sense if the protocol is about diagnosing the condition (not treating the condition).  Ask FHIR-I to clarify the extension by including an example specific to Condition.
4. GF#24681 Rename AdverseEvent.date to occurrence
5. Recommend renaming ‘detector’ to ‘asserter’ and ‘detected’ to assertedDate – consider logging change request (AdverseEvent has not been aligned with Event pattern yet)
6. Consider renaming ‘outcome’ to ‘status’ or a more descriptive name. Name is confusing – referenced existing change requests related to adding a status.  
   1. GF#22739 QA: AdverseEvent is missing entered-in-error status
   2. GF#22108 AdverseEvent is missing status

Wed Q4 

• GF#22108 AdverseEvent is missing status – resolved Wed Q4
  • GF#22739 QA: AdverseEvent is missing entered-in-error status – duplicate based on resolution of GF#22108 
• GF#24684 Rename AdverseEvent.detector to asserter – resolved Wed Q4

Thurs Q1

Care Plan Report out

Additional Notes for the quarter - thanks Jay

Care Plan DAM 2.0 (update) - Stephen Chu, George Dixon

• Dental Interoperability Project - Provided by Todd Cooper
• 

Pharmacy Care Plan

CDA and FHIR Pharmacy Care Plans passed ballot. 

Pharmacists have adopted the care plan

Information from initial Pilot Site - Community Care of NC. Trained 22 vendors. Currrently using the comment only balloted version of the care plan. 

Trying to put together a survey of the actual adoption is - large chain pharmacies have adopted it. Pharmacists are capturing clinical information. 

North GA work to transmit patient condition to the food bank to be aware of the types of diets the person should be with. 

Have connected with Cerner and Epic for care everywhere. 

Questions

• What versions of the HL7 specifications have been balloted and published
  • For comment only ballot was not published. 
  • Took the for comment version and updated with value sets and went out for STU 1- Pharmacist development group has a Statement of understanding. 
  • Request for this work to be published with HL7 for the community to use. 
  • Discussion about if for comment ballots need to be published. 
  • Pharmacy work group is the sponsor for this work. 

Personal Advanced Care Plan - Lisa Nelson

Balloted in 2007 - published

Have been implemented and also sort an extension and went to ballot during this past cycle. 

SDWG and PC are co sponsors

Have started working in the context of the Gravity work. Still have activities that need to happen. Currently can't publish as an STU- will need another iteration. 

Petitioning the TSC to be able to go to normative. Vote taken

Lisa Nelson: Motion for PC to support the PACP project requesting TSC to address the issue for this project be able publish as an STU 2 following normative process. 

Scott Roberts: Second

Abstain: 3; Against: 0; For: 23

Gravity Project (update) - Lisa Nelson

Ask PCWG to take up sponsorship of their first PSS

Overview provided. 

One goal is to address how to add documentation (coded) around SDOH. 

Looking at collection of data in food insecurity, housing, transportation access

Progress in food insecurity so far

Looking across the cycle of care. 

Project aligns with many other HL7 projects. 

Goal is to leverage work that has already been done. 

Currently have 714 individuals participating in the project. Moving to build FHIR IG against the various domains. 

Timeline up to May 2020 for the first domain

Will do a new PSS if the scope gross across the initial 3 domains

Plan is to have versions of incremental prgress. 

Scope for the PSS is to work on the 3 domains one at a time

PC as primary sponsor or interested party (working with the Vocab work group)

Output is a FHIR IG

PC would like to take a look at the PSS - PSS is under the gravity project page

Will schedule a co-chair meeting on Sept 23 to vote on this PSS. 

C-CDA Care Team

Nutritional template in the C-CDA

Nutrition (update)

Contributing to the Gravity project

C-CDA Care Plan (updates)

Templates haven't changed

Care Team DAM

LHS Care Team DAM - Q4 today

Updates to FHIR careTeam resource - encounter removed

Previously stated in FHIR R4 - careTeam resource description updated in the current build. 

Care Coordination FHIR Track (overview) - Dave Carlson

Nursing Care Plans

Use of Task to support workflow

Integration of CQL in Clinical Reasoning

DaVinci Track

Payer coverage uses multiple care plans in bundles that are sent from payer to payer. 

Dental Interoperability Project (update provided by Stephen Chu)

Thurs Q2

Dental Summary Exchange Project

Plan - Short term - CDA templates extending C-CDA

• Have mapped data elements
• CDA IG

Currently exploring FHIR aspects but not ready to do that work yet. 

DoD project

Have 3 vendors participating

Meetings Wed 2:30 - 3:30 pm

Hoping to ballot next fall. 

What involvement would PC like to have. 

Discussion: 

The intention is a patient transitional perspective - More longitudinal aspect - Dental history over a certain amount of time. 

US realm is the scope. 

Project site - under PIE work group

PSS have been approved by PIE and co-sponsor by SDWG

PC would like to be interested party

• What is the expectation from Patient Care? - May need to make breaking changes to CDA and would like input into that. 

CDA Management Group overlooks the quality of the IG

Vote will be done at the Co-Chair call on the Sept 23, 2019 - 5 pm EST. PSS is here

This project is not related to the dental interoperability project but they are aware of the project. 

CDA DeepDive

Working on three year management project

Working with HL7 Affiliates on where in the world there are most implementations

Currently CDA documents have a bad rap about quality - doing some implementation work on how to deal with this. 

CDA R2.1 - Normative ballot is done and has been approved by HL7 for publication

CDA Management team will be educating folks about 2.1 - both versions will be published. CDA 2.0 will continue to be the based standards to go forward. 2.1 is backwards compatible with 2.0. Anything that currently validates will continue to validate. 

C-CDA on FHIR - Pattern is being used by FHIR documents. 

• Currently undergoing an STU update
• Materials available for review on the confluence site
• Was released under DSTU 2 - update to accommodate R4
• Entry templates are incrementally being added using US Core resources as they are being released. Did not make new profiles for templates that are not part of US Core. 
• Where there is guidance in C-CDA for non-US core templates points to the base resource. US Core currently doing an STU update. Commitment is to track against USCDI.
  • In the future ONC wants to track USCDI based on what has been provided by the implementer community
  • What happens when templates are not included in US Core? Have to get in line and see if it can get prioritized
  • Matt Lord mapping work (SOA Group) has granular entry level mapping for every entry in CCD documents and the elements in the header. Stopped at concept to concept (value sets that does not line up with US Core value sets). It's HL7 intent to have approved mappings. 

Collaborative Template review Project

PC - Problems and Allergy

FM

Medications

PC is the only group that have made progress. Changes have been made to align with FHIR work. 

Haven't made progress with transfer of stewardship of some of these value sets. Will need to continue to work together for now. 

After the companion guide work on open question around persistent IDs. What are the expectations on keeping persistent IDs so systems can know elements with same IDs may be the same. 

Problem concern and what it means to FHIR. FHIR does not have the notion of concern on the FHIR side. Need to continue to work with PC on carrying this over to the FHIR side. 

Discussion:

Disconnect between PC perception of health concern and SDWG notion of concern. 

Another area for progress may be with the transition to UTG. VSAC value sets have been moved to UTG. May provide the opportunity for patient care to review these value sets and provide updates/feedback. 

VSAC publication is updated June annually. HL7 remains the stewards but the authorship roles can be changed. 

Process for deprecating or adding values - OID is bound in the templates. If changes are in the scope of what is defined can erased and change the values. 

Big issue: UTG need to be able to document the need and rational for changing values in value set - need to require where value sets are being used so that changes to value sets doesn't break other IGs that uses the same value set. 

Care Team 

Care Team Member Function value set. Meant to describe roles on care teams. 

Suggestion to add examples to the VSAC description. 

In CDA this is the function code - usually on participation elements. Based CDA already binds values there. It can be extended. It's expressed in HL7 codes. Our function codes were expressed in SNOMED codes. Did a grouping value set but discovered overlap. There were 5 codes that overlapped. PCP is one one of the code. PCP - primary care physician. The problem now is in two spots

1. Primary care provider has old and new code
2. Primary care practitioner is an new code but there is no old code for it

Recommendation - back away from putting primary care physician to eliminate gap. Keep the SNOMED code for primary care provider. 

Harmonization group will not change the description to because it's bound to the notion and can not change notion because that changes meaning. Will need to a new code. 

Will remove SNOMED Primary Care Physician - prevent duplicate

Keep SNOMED Primary Care Provider

Suggestion is to take this discussion to SDWG Example Task force to get implementers input. 

Clinical Status

FHIR has clinical status (relates to condition of the patient) and Verification status (clinical workflow status)

Other resources has status that are not consistent across the FHIR resources. 

PC has been trying to get FHIR to sort out the differences between a workflow status and clinical status. This relates to outcome as well - outcome is a type of clinical status. 

This is a giant design flaw. So far the alignment seem to be with condition and allergy. Have not dealt with this across other resources. 

Claude Nanjo CIMI quality work can include this topic and gForge items will be created. Stephen will follow-up with Claude. 

Thurs Lunch 

Michelle drafted Sydney agenda and will send room requests & invitations.

We agreed with her draft.

SD question about PC stewardship of clinical content. We are getting the PSSs anyway; maintenance is an open question.

Thurs Q3

PACIO

Support use of CMS Data Element Library

• Want to add FHIR API to be able to populate apps used for assessments
• DEL FHIR API at FHIR Connecthathon

PACIO goes beyond the DEL. 

• Interoperable data exchange across care settings
• Data meeds to follow the person
• Think of PACIO as the DaVinci Project for Long Term Care
• Functional Status and Cognitive Status as the first two data classes
• Current development effort
  • FHIR IG
  • Reference Implementation
  • Test Scripts
• Number of different participants participating 
• Leadership driven by CMS, ONC, MITRE
• Creating a clinical advisory group as a resource and creating a technical development group

Discussion

• How does this fit into the HL7 Paradigm of projects? This is not 
• No pilot sites yet. Trying to get the IGs up and running. 
• Have a few users of the DEL - most still learning about the DEL
• Exposure to 360X - have been talking to Holly Miller about it. 
• Planning a for comment ballot for the DEL
• Planning Functional status and cognitive status IGs with goal to proceed to STU 1 in May 2020 
• Please let them know if patient care is interested in participating - see here
• DEL PSS - Suggestion for vocab WG to sponsor
• Would like for Patient Care WG to sponsor the Functional and Cognitive Status FHIR IG. Will forward PSS and participate in the PC Co-chair call on Sept 23 for vote. 

Thurs Q4

See LHS meeting notes.