Open slagesse-epic opened 10 months ago
I think it is a reasonable requirement.
What was the criteria/reasoning for selecting IPA and not other profile (e.g., IPS)?
IPA was selected as it is an open, international standard designed to profile Resources in a fairly general way for RESTful access.
IPS is intended to profile Resources for inclusion in documents, and so would not be appropriate for a specification like PDQm.
Per discussion at the IHE Face to Face on 2/6, we will remove the dependency on IPA pending the discussion on the scope of IPA. Much of the community working on IPA considers it to be intended only for patient facing applications and not backend applications which do not involve the patient. Thus, the scope of IPA might well be too narrow to be aligned with the needs of IHE profiles on Patient in general.
See the discussion on the HL7 Zulip for more background.
In lieu of basing on IPA, we will evaluate the requirements currently imposed by IPA patient and add the ones we feel are appropriate to PDQm.
Submitted https://jira.hl7.org/browse/FHIR-44707 to request a common profile of Patient from HL7. FYI @JohnMoehrke
Currently the expected actions for ITI-78 and ITI-119 require that all Patient Resources returned by the Patient Demographics Supplier conform to the PDQm Patient Profile.
Are these requirements reasonable? While Patient Demographics Consumers SHOULD be robust in handling non-conformant Resources in the response, the intent of this requirement is to require that any Resources produced by the Patient Demographics Supplier are reasonably interoperable.
Furthermore, we have decided not to derive from IPA Patient at this time. It is unclear if HL7 intends for IPA to generically cover all use cases for Patient data, or if IPA is limited to use cases of Patients accessing their own data. Discussion on this matter can be reviewed on HL7's FHIR Zulip Chat.