Page tree
Skip to end of metadata
Go to start of metadata

References to other DaVinci and FHIR resources for PCDE:

1) Prior Authorizations: Prior Auth

2) Member ID: PDEX

3) Provider ID/Directory: PDEX

4) Care Team: Care Management

5) Active Treatment/Care Plan (includes specific treatment data like dietetics, allied care): Care Management

6) Case Management Services: Care Management

7) Coverage data: HREX

8) Communication Request: PCDE?

9) Communication: PCDE?

Coverage components:

Payer: NAIC code

Plan: optional

Policy Holder/Group: optional

Subscriber: Subscriber/Member ID

Beneficiary: the individual and their demographics who is covered-- Patient Resource (Member ID and or dependent code optional here

ID Schema:


  • First name
  • Last name
  • DOB
  • Either:
    • Primary Subscriber ID OR
    • Primary Member ID
  • Primary Payer NAIC 
  • Coverage Date/Period


  • Dependent Code
  • zip
  • address
  • group ID
  • secondary subscriber or member ID and payer
  • Phone
  • email
  • RxID

Please put your issues requiring ballot comment submission, discussion, follow up or clarification into this spreadsheet.

Issue number Issue DescriptionIG location

Text field doesn't enforce all the content in the section in human readable-- need to consider how different data types are viewable

Need to address new auth profile-- use HREX

Need to apply consistency on title fields

Identifiers-- SSN? which IDs

How long to store coverage info, how far look backs

Reconciliation from transfers

Should coverage info carry over from a prior reconciliation

Need to check that "active treatment" is actually reflected in FHIR 'Plan" and status "active"

Goals-- would that ever be coded field?

CertificationType-- an extension in priorauth-- what value set or responses should be constrained if any? what would this field mean in PCDE context?

Ideally would address what kinds of documents would be attached and what type in IG

Need to post a separate communication to the composition bundle-- then a service unpacks it and applies it to the record

Can we deposit a communication with the coverage transition bundle to automate the process/bundle and write back to the server attached to the patient

Will we use business treatment and operations via HIPAA?

Need to define a value set/code to request a coverage transition request in communication request.

Use LOINC code for the communication request document-- need to request one in a year-- until then use a placeholder custom code 

Need also to select a communication category

Inside the Simplifhir US Core profiles there are some out of date value sets/profiles and these are throwing errors in testing

How will the payer organization be identified? Sender and the recipient?-- could use the FHIR endpoint-- would not specify the individual plan likely

Use the CDEX communication request profile for the IG?

FHIR validation"A resource should have narrative for robust management"

What if the patient has no active treatments? What is sent? Reason code? Need to return a result code and a string "No active treatment"-- need to create new profile for no active treatment?:

status: not done,

status reason: Communication not done,

string: no active treatment,

subject: patient

Communication instead of document should be used when there is a patient found but no active treatment plan

Dont necessarily need a response to comm request but probably should – can point to a communication request in the payload but this makes workflow more difficult-- can send a separate comm request with the document

Patient as the subject, coverage as "about" – when member registers, need to ask the new member what the old coverage is

Payer may have secondary coverage-- PBM, mental health coverage that may or may not be in house-- how does it get populated?

1) CMS allows information not in house to be missing

2) Payer makes FHIR call and gets additional data from the other secondary actors

3) Payer creates internal data connection or makes other requests for data and incorporates in in real time into internal dataset 



POST Request resource to resource end point

Store resource. No action taken (not recommended to act generally)

POST Request resource to resource end point with "actionable" tag set

Resource gets stored AND workflow initiated. Response indicates "successfully stored". No feedback on execution of action.

POST Task resource to Task endpoint (somewhere)

Resource gets stored. Authorized systems can update the task to indicate that they've accepted it and work is underway. Progress can be monitored. Once complete, task is adjusted to point to results.

POST "collection" resource to Bundle endpoint

Collection is stored. No action taken.

POST "transaction" Bundle to root endpoint

All resources created or updated as requested. (or all fail if any do). If any request resources are marked with "actionable" then action is initiated. Response indicates "creation successful". 

Resources can  use the Conditional Reference mechanism to point to resources based on a query rather than a resource

Custom solutions

***POST "collection" Bundle to custom operation

Server does whatever action operation describes and provides whatever response is defined by operation. New operation endpoint is required whenever you want new behavior.

*could be used to provide guidance on allowable matching operation for data that is close to identifying patient/payer but not exactly matching

Con: have to have all parties support custom operation

***POST "message" to "processMessage" operation )or deliver via some other mechanism)

Server does whatever the message event code says. Endpoint is the same for all messages, new event is required when you want new behavior.

Contained resources:

Contained is ONLY used when you're communicating information that does not stand alone and isn't expected to resolve against data in the target system.


Originally was used to send a record of information that was sent – i.e. patient received smoking cessation pamphlet 109

Newer use for how to use as a mechanism for a wrapper for information and operations exchange

CommunicationRequest does not necessarily generate a confirmation or communication (although AuditEvent still exists but not as part of the clinical record)

CommunicationRequest→ Communication inside Bundle

CommunicationRequest→ Communication 

CommunicationRequest→ Bundle (no communication)


1: Found patient, send bundle

2: Did not find patient

3: Found multiple possible matches, 

4: Found patient no active treatment

5: Found patient but couldn't retrieve anything/not

Payer questions:

1) Is it reasonable to differentiate between 4 and 5?

2) What about when the data is covered under another supplemental plan and not available locally? Would you be able to call that out? ie "Pharmacy data is not available" or "mental health data is not available"


ScenarioCDEX Event CodeTextPatient Examples
1 – Patient found, active CarePlans present, bundle created but not sentin-progressPatient found, active treatment present. Bundle in process, not yet sent.Joe Smith
1 -Patient found, active CarePlans present, bundle sentcompletedPatient found, active treatment present, bundle included in message.Joe Smith
2 – Patient not foundnot donePatient not found.Carrie Abubu
3 – Multiple patients found, need more informationon holdPatient not unique, provide additional data.

Jeff Smith 1/12/1980, 74047

Jeff Smith 1/12/1980, 20002

4 – Patient found, treatment data present, no active treatmentstoppedPatient found, no active treatment.Jessica Taylor
5 -- Patient found, treatment status unknownunknownPatient found, treatment status unknown


To do:


  • To create narrative and send to Lloyd-- format: markdown


  • Background section of IG


  • Review existing IG plan/content

Next Steps:

Implementation Guide Content:

  • Background/Context:
    • CMS NPRM: health plan to health plan exchange initiated by member-- MA, qualified plans, Medicaid, Medicaid Managed Care, CHIP
    • Need to provide continuity of care/treatment: goal to prevent patients from having needed therapy terminated due to coverage transition
    • PDEx: Benefit claim to third party application: MemberAuth for health plan exchange per PDEx-- IG to refer to PDEX for method of transport
    • Context is limited to the therapy which is active-- needs to be contextual: includes condition under tx, guidelines used to determine tx, authorizations, evidence, etc
      • Associated goal of limiting additional documentation to justify care, notifying member and providers about non-covered or lower tier therapy
    • Current data is either not entirely structured or is in proprietary or custom systems-- it may need to be sent 
  • US Core Care Plan is minimal to be of limited help for this IG; however, PDEX already provides a guide as to how to reference the resources in US Core 
  • Member Initiated: OAuth – as described in PDEX
    • Consider whether IG should support alternative authorization mechanisms?

  • No labels

1 Comment