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:

Required/Minimum:

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

Optional: 

  • 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 













































Communication/Request:

Pure FHIR REST:

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.


Communication/CommunicationRequest

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)

Options:
CommunicationRequest→ Communication inside Bundle

CommunicationRequest→ Communication 

CommunicationRequest→ Bundle (no communication)


Scenarios:

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"

3) 


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







7/2/2019

To do:

Mark:

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

Julia

  • Background section of IG

Lloyd 

  • 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